Cover - Product Thinking

Andreas Soller

Product Thinking

Product Thinking is the way how product teams build outcome oriented and user centered services and products in an agile setup.

This article provides an overview of the process, focuses on product teams and the differences between output, outcome and impact. The goal is to minimize the output and at the same time to increase the outcome.

14 min read (3136 words)

Nov 26, 2022 – Updated Dec 4, 2022, 7:31 PM

PRODUCT THINKINGUSE VALUEOUTCOME

Overview

Product Thinking Process - full flow

Illustrations are based on Jeff Patton's drawings of the Product Thinking process.

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
  • what users 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.

User - Product - Product Team

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, Feature Team or Product Team

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 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.

“(…) in most companies, the stakeholders still provide the teams with roadmaps of what features and projects the stakeholders think best. Even though the teams use Agile methods, the teams are not empowered and accountable (…) They are there to implement.”– Marty Cagan (2018)

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.

“These feature teams will often think they are doing product discovery, but really it’s just design and maybe a little usability testing.”– Marty Cagan (2019a)

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.

“Product teams are cross-functional, focused and measured by outcome, and empowered to come up with solutions that work.”– Marty Cagan (2019b)

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:

Takeaway

Together with business the product team discovers opportunities for value creation. The product owner leads but the whole team has the ownership of the product.

Output, Outcome and Impact

Output

We have ideas (opportunities) that are transformed into concrete working software. As time and costs are fixed, scope becomes the zone of influence.

Output is the very concrete working software. Output is great, because we can predict it, we can measure the effort that was needed. We know everything about time and cost spent. There is nothing magical about it – it's simple math.

In an agile setup effort is measured in story points. If there is a team of team’s structure story points can be normalized. In some companies those normalized story points are transformed to concrete monetary equivalents. (Obviously there is a risk that this practice combines apples with pears as story points are a relative measure that materializes as a concrete means of measurement only within a specific social context. Even reference stories across teams cannot fully solve this dilemma.)

Output

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.

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. (There are many other biases that impact decision making: confirmation bias, conformity bias, authority bias, overconfidence bias, etc.)

Output - Outcome - Impact

Minimize output and maximise outcome.

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.

Takeaway

The goal of the whole process is to minimize the output and to maximize the outcome.

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:

  1. Discover: respond with a test
  2. Deliver: respond with scale
Product Thinking Process - Overview

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
  • (…)

Sense is about everything that helps us to gather information about our customers and their users to understand how they use our product and what value it creates for them.

Product Thinking Process - Sense

Opportunity Backlog

All this data can be consolidated as Story Map. A Story Map consists of the following building blocks:

User Journey

  • On the top you can see the User Journey which is the narrative of a specific job from specific personas who use the product. The focus is not only the product but all the activities a user needs to perform to get her job done.
  • The mapped journey is also called the 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?
  • It is also highlighted what parts of the journey are potentially or already connected to your product.

User steps

  • 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.
  • Mapping user steps also helps to understand deviating flows for different personas

Scenarios

  • One common problem with User Journeys is the question of conditionals: how to deal with activities that might or might not occur? It can become quite overwhelming to map out each condition. Therefore, it helps to including scenarios in the User Journey. A scenario simply is an activity or a set of activities that might or might not occur during the product’s lifecycle. For example, there will always be some differences between new and existing users.

Opportunities

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

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
  • (…)

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.

Focus means that the opportunities from the opportunity backlog are enriched with organizational strategy and that clear metrics are defined to measure success. What change in user behavior will have an impact on business results and can be measured? Nowadays, OKR's are widely used as metrics.

The result of this process is a problem hypothesis.

Product Thinking Process - Focus

Problem hypothesis

Examples how to write a hypothesis:


We believe user
has problem.
If we release this solution,
she will get benefit,
resulting in measurable outcome/impact.


We believe
outcome will be achieved
if user attain benefit
with solution.


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.

Product Thinking Process - Discover

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.

Product Thinking Process - Deliver

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.

Takeaway

Sense and Focus are the omnipresent layers that are always there. They represent the ongoing flow of collecting insights, understanding usage and identifying opportunities that are prioritized based on the assumed value they create for business.

Product Thinking Process - Umbrella

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.

Takeaway

Dual-track development is one possibility how product teams can collaborate in an agile setup. As the workflow is organized in sprints, the team works in parallel on discovery and delivery tasks. Sense and Focus are the umbrella, the foundation or the center around which everything is organized. The evidence board is where findings are documented but the insights and learnings are generated in disovery and delivery.

Dual-Track Development

References and recommended readings

  • Blank, Steve / Dorf, Bob (2012): The Startup Owner's Manual. The Step-by-Step Guide for Building a Great Company. Pescadero: K&S Ranch Press
  • Cagan, Marty (2018): Inspired. How to Create Tech Products Customers Love (Silicon Valley Product Group), New Jersey: John Wiley & Sons, Inc.
  • Cagan, Marty (2018): Revenge of the PO. URL: https://www.svpg.com/revenge-of-the-pmo/ (26 Nov 2022)
  • Cagan, Marty (2019a): Product vs Feature teams. URL: https://www.svpg.com/product-vs-feature-teams/ (26 Nov 2022)
  • Cagan, Marty (2019b): Product team FAQ. URL: https://www.svpg.com/product-team-faq/ (26 Nov 2022)
  • Cagan, Marty (2021a): Product vs Project teams. URL: https://www.svpg.com/product-vs-project-teams/ (26 Nov 2022)
  • Cagan, Marty (2021b): Empowered. Ordinary People, Extraordinary Products (Silicon Valley Product Group), New Jersey: John Wiley & Sons, Inc.
  • Downe, Lou (2020): Good Services. How to design services that work. Amsterdam: BIS Publishers
  • Gothelf, Jeff / Seiden, Josh (2016): Lean UX. Designing Great Products with Agile Teams. Sebastopol: O'Reilly Media
  • Gothelf, Jeff (2019): The hypothesis prioritization canvas. URL: https://jeffgothelf.com/blog/the-hypothesis-prioritization-canvas/ (26 Nov 2022)
  • Kalbach, Jim (2020): The Jobs to be Done Playbook. Align your Markets, Organizations, and Strategy around Customer Needs. New York: Two Waves Books
  • Patton, Jeff (2014): User Story Mapping. Discover the whole story, build the right product. Sebastopol: O'Reilly Media
  • Patton, Jeff (2022): Passionate Product Leadership. Certified Scrum Product Owner course. URL (training promotion): https://www.jpattonassociates.com/services/ppl-online-course/ (26 Nov 2022)
  • Ries, Eric (2011): The Lean Startup. How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. New York: Crown Publishing Group
  • Seiden, Joshua (2019): Outcomes over Output. Why customer behavior is the key metric for business success. United States (On demand): Sense & Respond Press

You can change your cookie preferences anytime in the Privacy Policy.