1.Why Product Discovery & Continuous Validation is worth getting right
The core discipline taught here is assumption mapping: before any epic enters the backlog, the team spends a few minutes asking what has to be true for this to work, and which of those things has no supporting evidence yet. A ranking game forces prioritizing assumptions by risk rather than by however interesting they are to investigate, and a companion lesson on the smallest test that could change your mind pushes teams away from testing what they already know, which is comfortable, and toward testing the assumption that would actually be embarrassing to be wrong about.
2.How it works in practice
The module's central practical contribution is showing discovery living inside the delivery Sprint rather than as a separate research track that gets cut the first time a Quarter gets busy. It covers continuous interviewing without a dedicated research team, a scenario where a stakeholder insists they already know the answer and pressure-tests whether that confidence is backed by evidence, and closing the loop by killing ideas that evidence does not support, which the module treats as equally valuable as validating ones that do, because a killed idea early is far cheaper than a shipped one that fails.
3.Role reality
Discovery sounds like a separate phase in the training material. On a delivery team it has to share the same calendar as build work.
| Textbook theory | Delivery reality |
|---|---|
| Discovery happens before delivery. | Discovery runs continuously, in parallel with delivery, using the same team and roughly a tenth of its capacity. |
| Customer interviews validate the roadmap. | One interview validates nothing. A weekly cadence of small conversations over months is what starts to move decisions. |
| The opportunity solution tree is a diagram for a workshop. | It is a live working document that gets pruned every week. A tree that only grows is a wish list, not a discovery tool. |
| Assumption mapping happens once per feature. | It happens every time the riskiest assumption changes, which for a genuinely new idea is most weeks. |
| A prototype test is optional if the team is confident. | Confidence is the reason to test, not the reason to skip it. The riskiest ideas are the ones nobody questions. |
4.Core delivery pillars
The habits that keep discovery honest and small enough to fit inside a Sprint.
Start the tree from the outcome and the customer problem, not from a feature idea someone already committed to. A tree built backwards from a solution never gets pruned.
For every opportunity under consideration, name the single assumption that, if false, ends the idea. Test that one first, not the easiest one.
A test earns its place only if a specific decision changes depending on the result. If both outcomes lead to the same next step, do not run it.
Book customer conversations on the calendar before the Sprint starts, the same way you protect the Sprint Goal. Discovery that waits for spare time never happens.
5.Discovery health signals
Customer conversations per week per Product Owner. Below one a week, discovery has quietly stopped.
Share of opportunities removed from the tree after testing. Zero kills means the tests are not honest.
Days from naming the risky assumption to having a result. Long lead times mean the test was too big.
Share of tested opportunities that reach the Sprint Backlog with evidence attached, not just an idea.
6.Situations you will be asked to handle
The module puts you inside 4 decisions rather than asking you to recognise the right answer on a list. Each one is a situation practitioners meet, with several defensible options and consequences that follow from the one you pick. The scenarios below are the shape of the judgment the subject demands.
- Lesson 25.4: Game - rank the assumptions by risk
- Lesson 25.6: Game - how strong is that evidence
- Lesson 25.7: Decision lab - the stakeholder already knows the answer
- Lesson 25.10: Decision lab - evidence against delivery pressure
7.Common mistakes and why they fail
Jumping from problem to a single solution with no real alternatives
Building an opportunity tree with exactly one solution under each opportunity, which functions as a roadmap dressed up in discovery language rather than a genuine exploration of options.
Testing the assumption that is comfortable instead of the one that is risky
Spending discovery effort validating what the team already believes, and quietly avoiding the assumption that would be embarrassing to discover is false.
Treating discovery as a separate track that disappears under pressure
Running discovery only when the calendar has slack, rather than budgeting it as a protected part of every Sprint, which guarantees it vanishes the first time delivery pressure increases.
Accepting a stakeholder's certainty as evidence
Skipping a test because a senior stakeholder says they already know the answer, without asking what evidence actually supports that confidence.
8.Questions worth asking before you commit time to this
How do you know if a team is actually doing discovery or just delivering?
Check whether anything in the last few Sprints changed direction because of something the team learned. If every Sprint simply executes a plan set months ago with no adjustments, the team is delivering only, regardless of what any dashboard or backlog label claims.
What is an opportunity solution tree and why do teams get it wrong?
It is a structure connecting a desired outcome to the problems, or opportunities, that could move it, and then to multiple candidate solutions for each. Teams get it wrong by listing exactly one solution per opportunity, which is a roadmap in different formatting rather than a genuine set of options.
How do you prioritize which assumptions to test first?
Rank by risk: which assumption, if wrong, would cause the most damage, combined with how little evidence currently supports it. Test the risky, unproven assumptions first, not the ones that are simply the most interesting or easiest to check.
How does discovery fit inside a normal delivery Sprint without derailing it?
Budget a fixed, protected amount of Sprint capacity for discovery activities explicitly, the same way capacity is protected for support work or technical debt, rather than treating it as leftover time that evaporates whenever delivery pressure rises.
9.What to remember
- How to build and prune an opportunity solution tree that survives contact with stakeholders
- Designing the smallest test that could change a real decision
- A situational matrix for when discovery earns a Sprint slot and when it does not
10.Where this sits in the Scrumling course
Stop shipping confident guesses. Assumption mapping, small tests, continuous interviewing, and discovery that fits inside a delivery Sprint.
About 80 minutes of lessons and decision scenarios.
- Lesson 25.1: Why delivery-only teams stall
- Lesson 25.2: Opportunity solution trees in plain language
- Lesson 25.3: Assumption mapping
- Lesson 25.5: The smallest test that could change your mind
- Lesson 25.8: Running discovery inside a delivery Sprint
- Lesson 25.9: Continuous interviewing without a research team
- Lesson 25.11: Killing your own idea
- Lesson 25.12: Review and Retrospective as validation checkpoints
- Lesson 25.4: Game - rank the assumptions by risk
- Lesson 25.6: Game - how strong is that evidence
- Lesson 25.7: Decision lab - the stakeholder already knows the answer
- Lesson 25.10: Decision lab - evidence against delivery pressure
Assessment: Product Discovery & Continuous Validation quiz