Process overview

User and product

User

Product thinking evolves around the user. A product or service must bring value to its users. It must be usable and therefore, deliver use value. Without users no product and without value delivery no users. Simple as that.

In a B2B context we speak of customers and differentiate choosers and users. A chooser is someone who chooses to use a certain product or service on company level, while users are the persons who are actually using the service or product.

In essence it comes down to:

• what users do,
• what users say and hear,
• what users think and feel

about a specific product or service and if they keep using it.

Product

A product or service allows a user to do and / or experience something.

Each product provides specific capabilities to its users. With the spreadsheet application Microsoft Excel you can perform calculations, analyse data in form of Pivot Tables or visualize data among many other features.

Each feature enables the user to achieve a specific job. Features provide specific product capabilities for its users.

While Microsoft Word or Microsoft Excel can be used (and bought) independently, they are also bundled together as Microsoft Office. Such a software bundle can be refered as product portfolio. Depending on your business you might also have a portfolio of product bundles. (This is usually the case when the bundles itself have a value proposition.)

In the early days software was shipped on a physical medium such as magnetic tapes, rom cartridges, floppy discs, compact discs, etc. There where fixed dates when a complete product was released. With digital networks and cloud computing everything changed fundamentally: digital products are never finished and can be continuously tested, improved and released.

Usability

Usability happens at the intersection of user and product:

• Learnability: how easy is it to learn to use a product and complete a task if you see it for the first time
• Efficiency: how quickly can a user perform his task
• Effectiveness: how accurate can users complete their tasks
• Memorability: how easy can a user perform his task when he returns to the product after some time
• Culture: how logic is the product organized to meet a cultural context / customs
• Error tolerance: how often do errors occur and how do they impact the user journey

Satisfaction can be measured in terms of user engagement – the amount of time spent on your website, the number of users who keep using your product, referals of your product to others, etc.

What is a product team?

Delivering value requires people who create this value and there are different concepts how value creating teams can be organized and structured.

In this article the focus is on product teams.

But there is no black and white. To illustrate quickly the different team setups, I will use the terminology and concepts as introduced by Marty Cagan.

Delivery team

A delivery team (dev team, scrum team, engineering team) is composed of engineers, testers and DevOps and focuses on output only. The role of the product owner (or analyst) is to simply manage the backlog (administrator role). In a team of teams structure the analysts manage the backlog and the product owner takes care that the backlog is executed due to roadmap priorities.

The roadmap is a projection based on past experiences and estimations of a list of features received from key business stakeholders. The roadmap predetermines the priorities. The team executes those roadmap items in sprints based on this plan and the product owner shepherds releases in accordance with key stakeholders.

They key stakeholder role is sometimes referred as Business (Topic) Owner or Product Manager and is responsible for the outcome. Depending on the organizational structure there might be many levels of hierarchy as well as multiple topic owners involved. In that cases clear responsibilities and accountability might get blurred (think of RACI roles). As for delivery (and feature) teams the product ownership is outside the team.

Outcome is created via delivery team but managed and monitored solely on the side of business owners. The delivery team is self-organized and serves the product owner and the product owner serves key stakeholders.

Feature team

A feature team is composed of engineers, testers, DevOps and additionally designers and DevOps.

Same as a delivery team the team gets prioritized features and is more or less executing those features for key stakeholders via roadmap. The main difference to a pure delivery team is

• team composition and
• execution of these features.

While delivery teams focus only on delivery, a feature team additionally includes discovery work (user centered and not only requirement-based elaboration) in their workflow.

Same as described for delivery teams the key stakeholders provide the product owner with a list of features and the overall backlog is managed by the product owner via roadmap. Still, lots of owners outside the team.

Product team

A product team on the contrary is fully empowered. Empowered means the team is fully responsible for output and outcome. A product team is dedicated to a specific product or product area and its goal is solving problems for users and thus having an impact on business.

If you are unsure about your teams’ setup, just think about what is celebrated at the end of a sprint: is it delivery (storypoints) or outcome (created and measured values)? Do you continue to monitor usage after a feature is delivered to continuously improve the product or do you jump right into the next big feature and keep only basic maintenance operations for the just released feature?

In a nutshell, a feature team serves business while a product team solves user problems and measures outcomes that have an impact on business.

With em-power-ment comes also risk and accountability:

• Value risk: will users use / buy this product?
• Usability risk: will users be able to use this product?
• Feasibility risk: will we be able to build this product with our given resources (time, skills, technology…)?
• Business viability risk: will we have a return of investment?
• Product specific risks: regulatory risks, ethical risks, etc.

To mitigate risk, it is crucial to understand and measure outcome and impact:

Output, Outcome and Impact

Output

We have ideas (opportunities) that are transformed into concrete working software.

In an agile team, costs (human ressources, infrastructure, etc.) and time (sprint duration) are fixed. Hence, the scope (deliverables) becomes the zone of influence.

Output is the very concrete working software. Output is great, because we can predict it and after each sprint we can re-check the effort that was needed. We know everything about time and cost spent. There is nothing magical about it – it’s simple math.

Additionally we know how we build the software. Therefore, the activities – the way how we created the working software – is also known to us. In an agile setup we have a scrum master role that helps the team to improve on the activities. Retrospectives are meetings where process optimizations, etc. are discussed and concrete actions are agreed.

Outcome and Impact

While we know everything about output, initially we don’t know anything about outcome. Because the impact of outcome happens outside our organization (unless we build working software for internal users).

Additionally, there is a time difference: we estimate output in sprint refinements and adjust the estimation after each sprint. Therefore, a team knows precisely the effort spent. Compared to output it takes as a long – a very long – time to fully understand outcome.

When we think about idea bias – the simple fact that we overvalue our own ideas or the ideas of the social group (team, project…) we belong to creates a real problem: If we do not validate the outcome, we might continue to deliver working software that is actually not used as imagined or – worse – will result in sunk costs.

To avoid outcomes becoming our blind spot we need to

• understand what customer or user behaviors drive business results.
• understand how we can increase or decrease those behaviors.
• measure the outcomes to make necessary course corrections.

The good news: as soon as we start measuring outcomes and understand what really drives usage and business results it is not biased gut feelings and inspiration that drive delivery but observable and measurable results.

Product Thinking process

Four dimensions

Let’s focus on the four dimensions of the product development process.

Continuous Learning and understanding:

1. Sense: understand customers, users and use value; opportunities
2. Focus: understand what opportunities drive what business results; priorities

Responding to our learnings:

3. Discover: respond with a test
4. Deliver: respond with scale

Sense (Listen & Learn)

Sense refers to an open-ended process of understanding customers and their users. This is a continuous process where we obtain an outside-in perspective.

How do we get this information?

• From a tactical perspective we observe and interview customers or we monitor their behavior. For new products or services, we must understand who the potential customers might be. For existing products, we need to create our information channels (example: Voice-of-Customer feedback)
• From a strategic perspective we analyse competitors or users who stopped using our product, etc.
• From a technical and usability perspective we analyzse for example what went wrong when they used our product
• (…)

Opportunity Backlog

The opportunity backlog is an overview of all opportunities you have discovered for your product. Sometimes this is also called an evidence board.

A good way of structuring such an overview is a Story Map. A Story Map is build on top of a User Journey.

User Journey

• A User Journey is the narrative of a specific job from specific personas who use your product. The focus is not only the product but all the activities a user needs to perform to get her job done, regardless if this involves your product or not.
• The mapped journey is also called narrative or backbone. It is important to understand how long the whole journey takes and to also collect passive actions such as waiting times. Why do they occur and how long might it take until the user can continue with his activities?
• Once the high-level flow is done you get more granular and start mapping out the individual steps necessary for each activity to be concluded. When you create the Story Map for the first time you will see that steps and activities will be mixed and the process will help you to understand what belongs where. The value of this differentiation lies in the ability to zoom in and out and see the bigger picture at the same time as the necessary details.

Opportunities

• Based on the insights you gathered, you additionally map pains (issues, problems, work-arounds) on the board
• You add as well gains, because you also need to understand what activities or steps in the journey already create benefits for your users. What should be increased to make the journey a pleasing one? What values does it bring and can even be improved?

You can use tools such as an Opportunity Canvas to analyse the potential of each opportunity.

Focus

Focus refers to your organization. There are always more ideas in the opportunity backlog that can be handled.

Also, not everything that brings value to the user brings also value to your organization. Therefore, those opportunities must be aligned with your organization’s

• Brand
• Brand values / ethics
• Vision
• Mission
• Product portfolio
• Product strategy
• Budget
• Time
• Business value / results
• (…)

It is crucial not to mistake opportunities with sales. The goal is not to transform opportunities into executable output. On the contrary it is essential to understand how a specific opportunity results in a specific business result and brings value to users.

The result of this process is a problem hypothesis.

Problem hypothesis

Building digital products and services is hypothesis driven. We solve a problem for a user that will in turn drive business. As part of focus we want to make the expected outcome measurable.

Therefore, we frame a hypothesis:

Metrics

Focus means that the opportunities from the opportunity backlog are enriched with organizational strategy and that clear metrics are defined to measure success.

You ask: What change in user behavior will have an impact on business results and can be measured?

Nowadays, Objectives and Key Results (OKR) are widely used as metrics. Each opportunity will come with its own objective and two to five specific, time-bound and measurable indicators to monitor if and how this objective is met.

Discover

The hypothesis is the starting point for validation. We want to find out if hypothesis will proof right or wrong.

• What is the assumed risk? (return of investment, usable, ethical, regulatory risk…)
• What do we need to learn to reduce the risk?
• What is the fastest way to learn?

This is what is often referred as minimum viable product (MVP): the smallest experiment we can run to test our hypothesis.

• minimum – next
• viable – best
• product – test

Design Thinking is commonly applied in discovery.

Release backlog

The result is an assumption for the smallest successful release. This is not the end product but it is the next iteration in trying to solve user problems and business needs. Our next best assumption we have confidence in.

Everyone who has practiced Story Mapping knows that each step (an opportunity is always connected to a step) can itself become a map. It’s story maps all the way down and this is why story mapping is such a great tool. You can use story mapping to map out the whole release plan for a single opportunity.

Discovery is understood as responding with a test accompanied with clear success metrics. We want to be able to measure outcomes – to truly understand if an activitiy will be successful or a failure.

Deliver

Delivery is responding at scale:

• Predictability
• Software quality and testing
• Reduced complexity
• Sustain ability to make changes as we learn

Good engineering enables experimentation and incremental improvements. This makes product discovery less risky as it enables us to measure outcomes as fast as possible.

Umbrella

Another way of looking at this process is to see Sense and Focus as the upper half that provides the understanding – the full and rich context –, while the lower half Discovery and Delivery deal with responding to this understanding with tests and scaling.

Imagine Sense and Focus as umbrella that shadows everything under it.

All our learnings are sensing. Every opportunity we discover is enriched with business strategy and feeds as hypothesis into discovery. Discovery is about separating the good ideas from the bad ones and is organized in iterations. Once we are confident with a hypothesis it is transformed into a release backlog for delivery to learn fast.

The product team works in two phases, discovery and delivery. This is also called dual-track-development.

Dual-track development

Dual-track development means that the whole product team works in parallel on discovery and delivery. Discovery is an essential part of product development and the whole team is responsible for output and outcomes.

Dual-track development is not a necessity for product thinking but it is one way how discovery and delivery can be organized in an agile team.

Of course, not all engineers will be doing user research. Not all engineers will align with stakeholders all the time and designers and analysts will not be able to write high quality code. Mixing all of this would result in bad code quality and be highly inefficient. But the whole team is involved in the opportunity backlog.

Sometimes, sense and focus are also combined as evidence board. In that case the evidence board is where all learnings and all business input is collected.

Everyone can see and contribute to the sensing area and the opportunity backlog. On the evidence board all findings are visible and connected with business strategies. Every team member (as well as stakeholders) can see the full user journey including all opportunities at any point in time.

Discovery tasks are managed on the discovery task board. This is usually a separate Kanban board. As it is hard to foresee how long it takes until we are confident about an opportunity, tasks on the discovery board are timeboxed. After each cycle the learnings are concluded and those learnings feed into the next iteration.