When product initiatives fail, it’s rarely because we couldn’t build the thing. It’s usually because we built the wrong thing — a product customers didn’t need, couldn’t use, or didn’t value.
This is where Product Discovery comes in. It’s not just a front-loaded phase or research activity. It’s an ongoing process designed to help teams learn fast, test early, and reduce the risk of building the wrong product.
🔍 The 3 Pillars of Product Discovery
1. Learn Fast – Get closer to the truth, quicker
Discovery starts with a clear understanding of real user needs, behaviours, and goals.
In one global bank I worked with, the team assumed customers wanted a mobile trading dashboard. After just five user interviews, they discovered most users only checked balances and alerts — not trading features.
➡️ Lesson: A 30-minute conversation saved 6 months of misdirected development effort.
Research by Teresa Torres in Continuous Discovery Habits shows that teams practising weekly customer touchpoints are more likely to ship successful outcomes, not just outputs.
2. Test Early – Validate before it’s too late
Testing early means trying small, cheap experiments before big, expensive launches.
For example, Spotify famously tested a “Discover Weekly” playlist idea by manually curating it for a few users. Only after validating interest did they invest in the algorithm.
You don’t need fancy tools — a clickable prototype, a concierge MVP, or even a simple fake-door test can reveal whether an idea deserves further investment.
➡️ Tip for Scrum/Product Teams: Incorporate hypothesis testing and assumption mapping into Product Backlog Refinement or Sprint Planning. Make space for validation, not just delivery.
3. De-risk Decisions – Expose assumptions before they expose you
Every product decision carries risk — around value, usability, feasibility, or business viability.
Product Discovery helps us surface and validate these assumptions early.
Take Booking.com: they run thousands of A/B tests per year, embracing discovery as a scientific process. They know that evidence trumps opinions, even when those opinions come from leadership.
➡️ Try this in your next Sprint: Pick one key product backlog item and ask, “What’s the riskiest assumption behind this?” Then, validate that assumption before building.
🚫 Discovery Is Not a Phase
A common anti-pattern is treating discovery as a “pre-Sprint” activity. This can lead to handoffs, delays, and disconnected insights.
Instead, discovery should be woven into every Sprint, alongside delivery. Scrum Teams can explore, test, and learn within the Sprint itself using lightweight approaches like:
- Customer interviews during the Sprint
- Small experiments as Product Backlog Items
- Usability testing before or during Sprint Review
This aligns directly with the Scrum Guide, which says:
“Scrum is founded on empiricism and lean thinking.”
Discovery strengthens empiricism — it helps teams inspect and adapt based on real evidence.
🎯 Final Thought
In a world full of uncertainty, speed is important — but learning is essential
Product Discovery isn’t about slowing down. It’s about de-risking decisions so we build with confidence.
So let’s stop asking, “How fast can we deliver?”
And start asking, “How fast can we learn whether this is worth delivering at all?”
👣 Next Steps for Teams:
- Add a discovery activity to your Definition of Done.
- Include assumption validation in refinement and planning discussions.
- Involve users in Sprint Reviews, not just stakeholders. (better during the Sprint)
- Celebrate learnings, not just launches.
