Pull up your roadmap right now — or just picture it in your head. How far out does it go? Six months? Twelve? Now here's the real question: how much of what's on that roadmap do you know will work, versus how much are you just hoping will work?
Most teams can't answer that question. And that's exactly the problem we're going to fix today.
Discovery Is Not a Phase — It's a Discipline
There's a version of discovery that a lot of teams are still running: discovery is something you do at the beginning of a project, and then you hand it off to developers. Two separate worlds, two separate teams, sometimes even two separate departments.
That model is broken.
The modern approach treats discovery as something woven into every sprint, every cycle, every conversation with users. It runs alongside delivery — not before it. Product development is fundamentally a process of knowledge acquisition. You build prototypes and experiments not to deliver a finished thing, but to generate learning you can act on.
The goal is to generate necessary knowledge rapidly. And if you're doing Scrum well, you already have the mechanism for this. The Sprint Review isn't just a demo — it's an inspection event. It's your moment to check whether reality actually agrees with your hypothesis. Discovery isn't a phase. It's a rhythm: bet, test, learn, adapt, every single sprint.
The Real Cost of Certainty Theater
Here's a pattern that shows up over and over again in organizations, especially technology product teams. Leadership asks for a roadmap. The product team builds one. It looks confident — dates, features, phases, maybe some color-coding. Everybody nods. Stakeholders feel good. Leadership feels good.
And then reality shows up.
Six months later, half of what was on that roadmap turns out to be wrong. Not because the team was incompetent. Because the roadmap was built on assumptions that nobody actually tested. That's what you might call certainty theater — performing certainty because uncertainty feels uncomfortable, especially in front of executives.
Donald Reinertson laid out the economics of this in Principles of Product Development Flow decades ago. When you run a large batch of work, build a big feature, and wait months to learn whether it worked, you're exponentially increasing the cost of being wrong. One bad assumption can go undetected for 90 days and get baked into hundreds of downstream decisions. That's not just a project risk — it's a structural problem.
The fix is not a better roadmap. It's smaller bets and faster feedback.
The Highest-Performing Teams Validate, Not Just Ship
The teams that consistently outperform aren't just shipping faster. They're validating whether their work actually changes user behavior. They're building feedback loops into the work itself.
In 2026, the teams that win will be the ones who learn the fastest — not the ones with the biggest roadmap.
So let's talk about how to actually do that.
Six Types of Discovery Experiments (and When to Use Each One)
Not all experiments are created equal. Using the wrong type is just as bad as not experimenting at all. Here's a breakdown of six specific experiments you can run right now.
1. Assumption Mapping
Use this when: You've got a new feature, initiative, or product idea and you're not sure where to start.
Get your team in a room — or the virtual equivalent — and surface every assumption embedded in the idea. Then rank them. The ones that are both important and unproven are your riskiest assumptions. Those are what you test first.
A lot of teams skip this and jump straight into building because building feels productive. But a two-hour assumption mapping session is not a meeting — it's a working session. And those two hours can save you three months.
2. Fake Door Testing (Also Called Painted Door Testing)
Use this when: You need to validate demand before investing in building something.
Build just enough to test the interest. A landing page that describes a feature with a "Sign me up" or "Get early access" button works well. The button doesn't go anywhere yet — or it goes to a waiting list — but you measure click-through and signups.
This is how companies like Intuit and Amazon have validated ideas before spending any engineering time on them. Gary Hamel documents in Humanocracy how Intuit's discovery teams did exactly this with products like what eventually became TurboTax Live. They showed a video to 250 prospective customers before building anything. A third of those people expressed interest — enough signal to move forward. The experiment cost almost nothing. The alternative was building a full product for an audience that might not exist.
3. Concierge MVP
Use this when: The job to be done is fuzzy, or you need to understand the actual user workflow before you automate it.
Deliver the value manually. A human being does the things the software would eventually do. You serve a small group of early customers personally — by hand, with no automation — to learn what they actually need.
This surfaces requirements that would never make it onto a spec sheet, because users often don't know what they need until someone is trying to help them. The process doesn't scale, and you'd never put it into production as-is. But it's one of the best ways to discover what you should actually build before you build it.
4. Technical Spike
Use this when: The risk is technical, not behavioral — you don't know if something is architecturally possible, or if your approach is the right one.
A spike is a timebox of focused technical investigation — one sprint, sometimes less. The goal is to answer one question: Can we do this, and how? Spikes produce knowledge, not shippable software. But that knowledge is genuinely valuable.
Reinertson's framing applies here too: delaying technical feedback lets bad assumptions compound. A spike truncates that bad path before it does expensive damage. Every hour spent on a spike is worth it — but reserve them for real technical unknowns, not for situations where someone is just unfamiliar with the codebase.
5. Hypothesis-Driven A/B Testing
Use this when: You have an existing product with real users and you want to validate that a change will improve user behavior.
This starts with a proper hypothesis, not just a design tweak. Something like: We believe that changing the onboarding flow will increase users who complete setup within 10 minutes, because the current flow requires too many steps. Then you run the test.
A useful real-world example here comes from Anna Blalock, a product designer at Netflix, who gave a talk about how design testing actually works in practice. Netflix ran an A/B test on a browsable homepage design — five separate versions tested against the original. All five lost.
What would most organizations do with those results? Declare them a waste of money and move on. But Blalock's takeaway was different: the tests may have failed five times, but they got smarter five times. That framing matters.
Netflix built an entire internal experimentation platform — Netflix XP — specifically to support this kind of testing. That investment wasn't small. But the cost of running those five tests was a fraction of the cost of shipping a degraded homepage design to tens of millions of users. At Netflix's scale, even a small drop in engagement would've dwarfed the total investment in all five experiments.
Your tests don't need to be Netflix-scale. But if you're spending two weeks of engineering time on an A/B test before shipping a checkout flow change to 50,000 users, and that test saves you from a design that would've dropped conversion by 10%, the math works out in your favor. Being wrong at scale is more expensive than running the test.
6. User Interviews
Use this when: You're seeing unexpected behavior in your data, or your team is debating what to build next.
Commit to five user interviews in one week. This is not a research project. It's not a formal study. Just five structured conversations built around three questions: What are you trying to accomplish? Where are you stuck? What have you already tried?
Five interviews with your actual customers will surface patterns that three months of backlog refinement misses — and they cost you maybe five hours of calendar time.
The Underlying Principle: Small Bets Are Smart Bets
Here's the principle underneath all six of these experiments. Reinertson puts it plainly: in product development, the economic cost of delayed feedback increases exponentially, not linearly. That's not a metaphor. It's math.
Every sprint you run without learning something isn't just a sprint of wasted output. It's a sprint that allows bad assumptions to compound into the next ten decisions.
Small bets are not timid bets. They're how smart teams de-risk big goals. The goal doesn't have to shrink. The uncertainty window is what needs to shrink.
Teams often resist this — not because they disagree with the logic, but because they worry about what leadership will think. If we're running experiments, does that mean we don't know what we're doing?
Yes. That's exactly right. You don't know yet. Neither does anyone else. The difference is that you have a system designed to find out.
What to Do This Week
Pick one item on your roadmap — something you're planning to build in the next 60 days. Ask your team this question:
"What is the smallest experiment we could run in the next two weeks that would tell us whether this is the right bet or not?"
That question changes everything. It forces you to name the assumption you're making. It forces you to think about what evidence would actually change your mind. In our email newsletter this week, we also explore a Confidence Ladder technique.
If you can't name the assumption, you don't have a bet. You have a wish.
And if nothing would change your mind? That's worth knowing too.
Ready to build these habits into your team's practice? Explore the courses and workshops at big-agile.com — from Product Owner and Scrum Master training to AI integration and beyond. The fastest-learning teams don't happen by accident.