The Three Streams: Product Discovery, Product Development, Release & Measure
Recently I asked my friend: Can you put your laptop in your pocket? So why are you trying to fit everything into the Sprint?
Yes, I’m a Scrum enthusiast. At the same time, it’s hard to ignore that for every tech product, there are 3 parallel streams:
- Product Discovery
- Product Development
- Release & Measure
Why does it matter? Let’s look at them one by one.
1. Product Discovery
The goal of Product Discovery is to find out WHAT to build.
There are two groups of activities:
- Exploring the problem space (observing, analyzing data, customer interviews, synthesizing knowledge, mapping opportunities).
- Exploring the solution space (ideating and testing your ideas with the help of prototypes).
Prototyping is essential. Before “coding,” we often want to answer the questions:
- Will it create value for the customers?
- Will they know how to use it (usability)?
- Will the technology work as expected (feasibility)?
- Will it be viable for the business?
According to Marty Cagan, Product Discovery results in a “validated product backlog.”
2. Product Development
This is where development work happens. Typically this is done in iterations with a constant rhythm. For Scrum, the most common length of the Sprint is 2 weeks.
In Scrum, every iteration should result in a valuable, useful, potentially releasable Increment. The goal of the Sprint Review is to “inspect the outcome of the Sprint and determine future adaptations.”
Most of my readers know it very well. For those, who don’t, here is the best source of information:
3. Release & Measure
Reviewing the usable Increment is not enough. I’d argue that in order to provide value, the Increment must be released. Also, only then can we reliably measure the outcomes and the business impact.
It’s worth noting that it takes some time to collect and analyze the data. Gradual releases for selected users may further impact the time to learn (TTL) but, at the same time, allow us to tackle risks.
Conclusions
I explained to my friend that those three streams run in parallel and feed each other with their outputs. But each has a different rhythm and dynamics, and it makes no sense to synchronize them in most cases.
For example, product discovery tends to be messy. When interviewing customers, identifying opportunities, prototyping, and testing your ideas, learning cycles may take anything from an hour to a few weeks. Also, the initial product discovery (building an MVP prototype) and continuous product discovery have different characteristics. It doesn't always make sense to put everything into the Sprint.
Helpful resources
Those resources will help you better understand Product Discovery.
1. Teresa Torres on Continuous Product Discovery:
2. Marty Cagan (SVPG) on using prototypes:
3. Initial Product Discovery with a 1-week Design Sprints:
Liked this story?
There is a lot more unique product content I publish only on Substack. Check my product newsletter, with actionable tips and advice for PMs: 👇
You may also like:
