Overview
Validating Product Assumptions is the fourth CSPO learning objective category and contains only two objectives. The first asks how Scrum itself supports validating assumptions: Sprints are short, each produces a usable Increment, and the Sprint Review invites real feedback, so every Sprint is a chance to learn. The second asks you to compare at least three ways of validating assumptions, such as interviews, paper or clickable prototypes, landing page or fake door tests, concierge or Wizard of Oz services, and A/B tests, by their cost and by the quality of learning they produce.
Although the list is short, trainers often spend real time here with hands-on experiments. CSPO has no exam, so the goal is practical judgment about which test to run next, not recall of definitions.
How it's tested
There is no CSPO exam to prepare for, but practice items on this category help you check your judgment. They usually present an untested belief and a set of possible experiments, and ask which approach gives enough reliable learning at the lowest reasonable cost given the stage of the product.
-
Riskiest assumption first
Several assumptions are listed, and you pick the one that would most damage the product if it were false.
-
Cost versus confidence
Methods with different costs are offered, and you weigh what each would really prove.
-
Scrum as a learning loop
A team treats Sprints as delivery only, and you identify how Scrum events support validation.
A team assumes small cafes will pay monthly for an inventory app. Building the full app would take four Sprints. Interviews are cheap but only reveal stated intent. A landing page with a pre-order button costs a few days and measures real sign-up behavior. A thoughtful Product Owner runs the landing page test first, because it gives stronger evidence of willingness to pay at modest cost.
Learning objectives 2
Official learning objectives from the Scrum Alliance outline, in outline order.
4.1 Describe how Scrum supports validating product assumptionsScrum as a learning cycle.
- What it means
- Scrum is founded on empiricism: decisions are made from what is observed. Short Sprints, a usable Increment each Sprint and the Sprint Review with stakeholders give regular points to test whether assumptions about value hold true.
- What to understand
- Each Sprint can be framed as an experiment: state the assumption, build the smallest increment or test that checks it, inspect the result at the Sprint Review, and adapt the Product Backlog. Transparency, inspection and adaptation apply to product ideas as much as to process. Short cycles limit the cost of being wrong.
- How it shows up
- Prompts ask which Scrum element provides evidence about a product idea, often pointing to the Sprint Review or Increment.
- Common confusion
- Seeing the Sprint Review only as a demo of finished work rather than a chance to gather evidence.
4.2 Compare at least three approaches to validate product assumptions by their cost and quality of learningChoosing the right experiment.
- What it means
- Validation approaches range from cheap and fast to expensive and rigorous. Examples include customer interviews, surveys, paper prototypes, clickable prototypes, fake door or landing page tests, concierge or Wizard of Oz services, pilot releases and A/B tests on a live product.
- What to understand
- Quality of learning depends on whether the test measures real behavior or stated opinion, how close it is to real conditions and how large the sample is. Interviews are cheap but measure what people say. A/B tests measure behavior precisely but need a working product and traffic. Choose the cheapest method that gives enough confidence for the decision at hand.
- How it shows up
- Scenarios list experiments and ask which gives the best evidence for the cost at this stage of the product.
- Common confusion
- Assuming the cheapest method is always best, or that only a full build can prove anything.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Assumption
A belief the product depends on that is not yet proven.
- Remember
- Name it before testing it.
- Tested as
- Starting point of objective 4.1.
- Trap
- Treating assumptions as facts.
-
Riskiest assumption
The belief that would cause most harm if false.
- Remember
- Test it first.
- Tested as
- Guides experiment order.
- Trap
- Testing the easiest assumption instead.
-
Empiricism
Deciding from observation and experience.
- Remember
- Transparency, inspection, adaptation.
- Tested as
- Why Scrum supports validation.
- Trap
- Limiting it to process improvement.
-
Quality of learning
How trustworthy and relevant the evidence is.
- Remember
- Behavior beats opinion.
- Tested as
- Core of objective 4.2.
- Trap
- Trusting what people say they would do.
-
Fake door test
Offering a feature that does not exist yet to measure interest.
- Remember
- Measures real clicks or sign-ups.
- Tested as
- Low-cost behavioral test.
- Trap
- Leaving users without explanation.
-
Wizard of Oz
Manual service presented as automated.
- Remember
- Tests value before building automation.
- Tested as
- Validation approach.
- Trap
- Mistaking it for a final solution.
-
A/B test
Comparing two live versions with real users.
- Remember
- Strong evidence, needs traffic.
- Tested as
- High-quality but costly option.
- Trap
- Using it before a product exists.
-
Prototype
Low or high fidelity model of a solution.
- Remember
- Good for usability and concept feedback.
- Tested as
- Low-cost option.
- Trap
- Treating positive comments as proof of demand.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Validation approaches by cost and learning
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Interviews | Conversations with target users | Cheap; measures stated opinion | Treating intent as proof |
| Prototype test | Users try a model of the solution | Moderate cost; shows usability | Confusing liking with buying |
| Fake door or landing page | Measure interest in an unbuilt offer | Low cost; measures behavior | Small or biased samples |
| A/B test | Two live variants compared | Higher cost; strong behavioral evidence | Running it without enough users |
Assumption vs. validated learning
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Assumption | Untested belief | Drives risk | Building on it unchecked |
| Validated learning | Belief tested with evidence | Supports confident decisions | Treating one small test as final |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Build it to find out
- What candidates pick
- Build the full feature and see if it is used.
- Why it looks right
- Real usage feels like the best evidence.
- Why it's wrong
- A full build is the most expensive test; cheaper experiments can often answer the question first.
Clue to watch for The idea is untested and costly to build.
-
Opinion as evidence
- What candidates pick
- Rely on survey responses saying users would buy.
- Why it looks right
- Positive answers are encouraging.
- Why it's wrong
- Stated intent often differs from behavior; tests that measure action give higher quality learning.
Clue to watch for The evidence is what people said, not what they did.
-
Cheapest is best
- What candidates pick
- Always choose the lowest-cost method.
- Why it looks right
- It saves time and money.
- Why it's wrong
- A cheap test that cannot answer the question wastes effort; balance cost with the confidence the decision needs.
Clue to watch for A high-stakes decision rests on a quick test.
-
Validation outside Scrum
- What candidates pick
- Run validation as a separate project before Scrum starts.
- Why it looks right
- It seems tidy to finish research first.
- Why it's wrong
- Scrum's Sprints, Increments and Sprint Reviews are designed for ongoing inspection and adaptation of product ideas.
Clue to watch for The team thinks Scrum is only for delivery.
-
A/B test too early
- What candidates pick
- Plan an A/B test for a product with no users.
- Why it looks right
- It sounds rigorous.
- Why it's wrong
- A/B tests need a live product and enough traffic; early stages call for interviews, prototypes or fake door tests.
Clue to watch for The product has not launched yet.
Answer framework
Use these steps to choose how to validate a product assumption.
- Write down the assumptions behind the idea, covering desirability, usability, feasibility and business viability, in plain language.
- Rank them by how harmful each would be if false and how little evidence exists, then focus on the riskiest one.
- List at least three ways to test it, from interviews and prototypes to fake door tests and live experiments.
- Compare the options by cost, speed and quality of learning, favoring methods that measure behavior over stated opinion.
- Run the chosen test within a Sprint where possible, inspect the result with stakeholders at the Sprint Review, and adapt the Product Backlog, dropping or reshaping items the evidence does not support.
Practice question
Want more like this? The CSPO practice test has questions for every domain.
Checklist
0 of 10
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
This category has only two objectives, so plan around three to five hours. Begin by choosing one feature currently in your backlog and writing every assumption it depends on. Mark which assumptions concern users wanting it, being able to use it, the team being able to build it and the business benefiting. Circle the one that would hurt most if it turned out false, and note what evidence you already have for it, if any. Keep this page for the course.
Next, design three different tests for that assumption and estimate the cost and what each would really prove. This mirrors the comparison exercise many trainers run in class. During the course, ask how other participants have used Sprint Reviews to gather evidence rather than applause. Finish with the practice knowledge check here to confirm you can choose an appropriate experiment; remember that CSPO is awarded for course completion, so the check is for your own confidence.
FAQ
How much of the CSPO does Validating Product Assumptions cover?
Validating Product Assumptions is the smallest category, with 2 of the 28 learning objectives. Scrum Alliance publishes no weights, and CSPO has no exam to apply them to.
How does Scrum help validate assumptions?
Short Sprints, a usable Increment each Sprint and the Sprint Review give frequent chances to put ideas in front of users and stakeholders, inspect the result and adapt the backlog.
What does quality of learning mean?
It describes how trustworthy and relevant the evidence from a test is. Measuring what people do is usually stronger than asking what they would do.
Is a minimum viable product the same as a prototype?
Not quite. A prototype models a solution for feedback, while an MVP is the smallest working product used to test a key hypothesis with real users.
Should every assumption be tested?
No. Focus on the assumptions that carry the most risk and have the least evidence, and accept low-risk ones without heavy testing.
Do trainers run experiments in class?
Many do, often by having groups design and compare validation approaches for a sample product. Exact activities vary by trainer.
Other Agile & Scrum certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 4 knowledge
You have covered how Scrum supports validation and how to compare experiments by cost and learning. Try a short knowledge check to see whether you can pick a fitting test.