Product Discovery Without a PM
More and more teams are talking about product discovery. But where does it fit into your current process? Where does it start? Where does it end? Who is involved? What is really happening during product discovery? And how to do it if you don’t have a dedicated product manager, or even a dedicated designer.
Product discovery is all about achieving a desired outcome. It describes the process of finding the problem and corresponding solution that have the biggest impact on the outcome.
Product discovery is a fluent and continuous effort. The end-to-end product discovery process looks at a near-term time horizon addressing one outcome at a time. Avoid spending time on problems or solutions that you are not ready to solve yet, or are not the highest priority.
Product Discovery Doesn't Happen in a Vacuum
The team collectively shares accountability for identifying the right problem and solution. In product teams without a dedicated product manager or designer, engineers have the responsibility to achieve the desired outcome and build solutions customers want to use.
Different roles and people are involved to a different extent throughout the discovery process. Especially, when not having dedicated product managers or designers who often are the ones talking directly to the uses and customers, the engineering team themselves needs to focus on involving your users and customers in close collaboration on identifying the right problem, scoping it down and finding a solutions that they will want to use.
What feeds into product discovery?
Where does product discovery sit in existing processes? The product discovery process sits between your desired outcomes and the user stories that you put on the product backlog. It aims to ensure that whatever you move into delivery has the biggest possible impact on your outcome. Tackling a problem your customers wouldn't spend time or money on can set you up for failure no matter how well your solution works.
Different roles and people are involved to different extents throughout the discovery process. Without dedicated product managers or designers who typically talk directly to users and customers, the engineering team must step up. This means actively involving users and customers throughout the process.
Product Discovery Process
1. Problem Discovery:
Input to problem discovery is a single desired product outcome. This provides the filter to the vast problem space and ensures the right level of focus. This helps with boundaries for the research and prioritization.
Problem discovery consists of 2 phases:
Go wide: Exploring and mapping the problem space. Creating a visual map of problems to solve that might impact the desired outcome. These are needs, pain points, or desires of the customer. The team uncovers these through customer interviews, surveys, and insights from customer feedback and behavioral analytics. These insights can be obtained from your support requests, direct user feedback, or usage metrics and are best mapped out with a digital mind-mapping tool (e.g. Miro, Whimsical, ...). This gives you a visual and complete picture of the different paths you could go down when prioritizing.
Narrow in: Prioritizing a single crisp problem to solve first. The visual map of the problem space allows to compare and contrast the problems to find the biggest opportunity to impact the outcome. Customer and stakeholder feedback might can additionally help identify the right problem.
Who is part of problem discovery?
In teams without a product manager, the tech lead or architect need to guide through this process, with engineers contributing and participating. You want to have all people who will need to make decisions take part so you can build a shared mental model of the customer needs, pain points, and desires. This will make finding the right solution more effective. It also provides the foundation for empowered teams to make outcome-focused decisions. The team collectively is accountable to have a prioritized list of problems at the end of this step.
What to expect as an output?
A single prioritized high-impact problem to move into solution discovery. This can also be a prioritized list of problems, but there should be a single problem to start with. The problem should have additional context on customer segment, constraints, and desired customer outcomes. Without that, it will be difficult for anyone who gets involved to get up to speed quickly and contribute effectively.
2. Solution Discovery:
Identifying the best solution to solve the chosen problem from problem discovery. Best in terms of best for the customer and best for the business.
Solution discovery consists again of 2 phases:
Go wide: Identify potential solutions to solve the problem. Capture assumptions around desirability, usability, feasibility, and viability for these solutions. Exploring many solutions at the same time reduces the risk of confirmation bias. When chasing only a single idea, it is harder to drop it and admit that it is not working.
Narrow in: Mapping and identifying the critical assumption based on confidence and importance. The critical assumptions are the most uncertain and at the same time most important. If these turn out to be false your solution won't work. Test critical assumptions first. With the learnings from the experiments narrow it down to a single solution that will work and solves the problem best.
Who is part of solution discovery?
In teams without a dedicated product manager the tech lead often coordinates the solution discovery process, but the entire team is equally responsible for finding the right solution. This means coming up with potential solutions, identifying assumptions, and running experiments. These experiments will be executed by the engineers as part of the regular development cycle. These can be UX tests, code prototypes, performance tests, etc.
What to expect as an output?
The output of solution discovery is a desirable, usable, feasible, and viable solution. To start with, the solution gets broken down as small as possible (think MVP - Minimal Viable Product/Feature). This can represent itself in form of a requirements document, epic, user stories, etc. ... depending on the development team's process of planning a new feature.
What's after product discovery?
From there regular planning takes over. User stories / tasks will be prioritized on the backlog. Designs and architecture overviews are created. Engineers will plan and break down the work into tasks for execution. And off they go.
