Concept 2 of 2

Product discovery and validating assumptions

9 questions test this

Every item in a product backlog carries at least one assumption. That someone has this problem, that they will change their behaviour to solve it, that the solution proposed actually solves it, and that solving it is worth what it costs. Discovery is the work of finding those assumptions. Validation is the work of buying evidence about the risky ones.

How this fits a product owner's week

Discovery is not a separate project. It runs alongside delivery, and the product owner's share of it is continuous rather than scheduled. Conversations with users happen every week, not every quarter. Refinement is where what those conversations produced turns into items with enough detail to be selected. The sprint review is where the increment gets inspected by the people it was built for, and where the product backlog is adapted from what they say.

The signal that discovery has stopped is a backlog whose top items have not changed in months.

How scrum supports validation

Scrum is founded on empiricism, and every part of the framework that seems procedural is there to make validation possible.

The increment must be usable. An increment nobody can react to produces no evidence in either direction, which is why the Definition of Done matters more than it first appears.

The sprint is a container of a month or less, which caps how much can be built on an unchecked assumption before it is checked.

The sprint review is a working session with stakeholders rather than a demonstration for sign-off, and it exists precisely to feed observation back into the backlog.

The Product Goal gives the evidence something to be evidence about. Without a goal, feedback is a stream of opinions with nothing to update.

Comparing techniques by cost and quality of learning

The objectives ask you to compare at least three approaches on two axes, what they cost and how good the learning is. These are the ones worth holding.

Customer interviews. Low cost, quick to arrange. Good for finding problems and understanding context. Weak evidence about future behaviour, because what people say they will do and what they do are different things.

Prototype or wireframe testing. Moderate cost. Good quality evidence about whether a solution is understandable and whether it fits the workflow. Still not evidence that anyone will pay.

Concierge or manual delivery. You deliver the outcome by hand before building anything. Cost is high in human time, low in build time. Learning is strong, because the customer experiences the real value rather than a picture of it.

A working increment released to a subset of users. Highest build cost and the highest quality of learning available, because the behaviour observed is real behaviour with real consequences. This is what the framework is arranged to produce.

A/B testing. Cheap per additional test once the plumbing exists, expensive to set up, and requires enough traffic for the result to mean anything. Excellent for comparing two versions of something. Useless for discovering the thing you did not think to test.

The rule that holds across all of them is to spend the least you can to move the riskiest assumption. Cheap evidence about a decision you were never going to change is the most common waste in discovery.

Common misconceptions

Discovery is a phase that happens before delivery starts.

Discovery and delivery run together. The sprint that ships something is also the sprint that produces evidence about the next thing, which is what makes the increment more than a deliverable.

Scrum has no place for validation because it is not in the Scrum Guide.

Scrum is built on empiricism, which is validation by another name. The increment gives you something inspectable, the sprint review gives you the scheduled point to inspect it with stakeholders, and the product backlog is adapted from what that reveals.

A validated assumption stays validated.

Evidence has a shelf life. Markets, competitors and users all move, which is why the loop repeats rather than closing.

9 questions test this concept

A product owner says discovery will run for three months before the Scrum Team starts delivering. How does this compare with the material on including discovery in a product owner's work?

  • AIt is correct, since building before understanding wastes effort.
  • BDiscovery is not part of Scrum, so it should be handled by a separate team.
  • CThree months is too long, but a one month discovery phase would be correct.
  • DDiscovery and delivery run together. The Sprint that ships something is also the Sprint that produces evidence about the next thing, which is what makes a usable Increment more than a deliverable.
Check whether it stuck.

One per page, with a worked explanation.

Start the set
Related material
Book
Continuous Discovery Habits, On running discovery as a weekly habit rather than a phase.
Book
Testing Business Ideas, On choosing an experiment by cost and by strength of evidence.
Book
The Lean Startup, On the build, measure, learn loop and what counts as validated learning.
Book
Escaping the Build Trap, On the difference between shipping and learning.