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.
Nov 26, 2022 – Updated Aug 3, 2023, 3:11 PM
User and product
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 hear,
- what users say,
- what users think and
- what users feel
about a specific product or service and if they keep using it.
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.
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.
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.
“(…) 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)
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)
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:
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
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.
The goal of the whole process is to minimize the output and to maximize the outcome.
Product Thinking process
Let's focus on the four dimensions of the product development process.
Continuous Learning and understanding:
- Sense: understand customers, users and use value; opportunities
- Focus: understand what opportunities drive what business results; priorities
Responding to our learnings:
- Discover: respond with a test
- 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
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.
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.
- 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.
- 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 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 values / ethics
- Product portfolio
- Product strategy
- 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.
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.
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:
We believe user
If we release this solution,
she will get benefit,
resulting in measurable outcome/impact.
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.
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.
Delivery is responding at scale:
- 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.
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.
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.
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.
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.
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)
- Pichler, Roman (2022): Strategize. Product Strategy and Product Roadmap Practices for the Digital Age. Leipzig: Pichler Consulting (Amazon Distribution)
- 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
Thank you for your feedback.