A Smarter Way to Plan Product Discovery
#007: A practical framework for scoping product discovery based on confidence, risk, and real-world constraints.
For years, I’ve watched teams struggle with one of the most overlooked (yet critical) parts of building good products: scoping the right amount of product discovery.
Sometimes we do too much: researching, framing, and aligning for weeks before even trying a rough prototype. Other times, we skip discovery entirely and hope delivery will surface the answers. I’ve been on both sides of that pendulum swing.
After 20+ years leading digital product discovery and delivery efforts, I’ve made all the discovery planning mistakes so you don’t have to. That’s why I built the Product Discovery Architect, a lightweight tool designed to help teams quickly align on the right level of discovery effort, based on real-world factors like confidence understanding the problem at hand and the risk of designing and building the wrong thing.
It’s based on a simple but powerful model I’ve used for years.
The Framework: Confidence × Risk
When teams struggle to scope discovery, it’s often because they don’t stop to ask two basic questions:
How confident are we in our understanding of the problem?
What’s the risk to customers or the business if our solution is wrong?
These two factors—Confidence and Risk—can be combined into a simple matrix that drives discovery planning.
High Confidence, Low Risk? Keep it light. Jump into design or ship an A/B test.
Low Confidence, High Risk? Slow down. You’ll need time to understand the problem, test multiple solutions, and de-risk the path forward.
Most work falls somewhere in between—and that’s where this model shines.
By plotting your opportunity on the Confidence × Risk matrix, you can quickly determine a right-sized discovery effort:
Small (1–2 weeks): Validate, prototype, test, move on
Medium (2–4 weeks): Moderate ambiguity or risk
Large (4–6 weeks): Big unknowns or potential impact
Extra Large (6–8 weeks): High-stakes, strategic bets
Each size maps to a recommended set of Double Diamond phases and suggested research and design activities (more on those below).
Making Discovery Visible in Real-World Processes
One of the biggest challenges in product organizations is that discovery work is often invisible—or worse, entirely absent—from delivery plans, project frameworks, and stakeholder expectations.
Whether your team runs on dual-track agile, Shape Up, or classic milestone-based planning, this framework adapts to your reality:
In dual-track agile, discovery often runs ahead of delivery. The Confidence × Risk model helps you determine how far ahead you need to be and what activities to focus on.
In Shape Up, the business sets an “appetite” for how much time and effort it’s willing to spend on a problem. That appetite must be informed by the level of unknowns and risk. Using this model, teams can shape bets more responsibly—and validate or pivot before committing to a build cycle.
In financially driven orgs, quarterly forecasts and budgets often pre-determine delivery timeboxes (e.g., "$12M of value must land by Q3"). Discovery work must inform a "go/no-go" decision early enough to re-forecast if needed. A small, focused discovery sprint in Q1 could save millions in misaligned delivery downstream.
In all of these cases, early alignment on the size and scope of discovery gives you better planning inputs, more grounded timelines, and clearer stakeholder communication.
When and Why Discovery Gets Skipped
Here’s what I’ve seen in org after org:
Discovery work isn’t part of the standard project template
There’s no shared language for what discovery is or how much is needed
Research feels like a blocker rather than a value unlock
Designers are hesitant to ask for time upfront
The result? Shallow problem understanding. Poor design decisions. Delivery rework. Missed outcomes.
The Product Discovery Architect helps fix that by making discovery effort explicit—something that can be scoped, planned, and communicated just like delivery.
Activities by Discovery Size
Each Discovery Size recommendation in the tool comes with a curated set of research and design activities based on how much effort and alignment is likely needed. Here are some examples:
Small (1–2 weeks)
Stakeholder alignment session
Competitive analysis
Basic user validation (3–5 interviews)
Simple prototype or wireframes
Medium (2–4 weeks)
User research with 5–7 participants
Problem definition workshop
Interactive prototype creation
Usability testing
Technical feasibility assessment
Large (4–6 weeks)
Comprehensive user research (8–12 participants)
Journey mapping and persona development
Multiple concept exploration
A/B testing preparation
Technical architecture planning
Risk assessment and mitigation
Extra Large (6–8 weeks)
Extensive field research and ethnography
Multi-stakeholder alignment workshops
Complex prototype development
Comprehensive testing (usability, accessibility, performance)
Market analysis and competitive benchmarking
Full technical specification
Risk management framework
Try It Yourself
Product Discovery Architect is in active development—but it’s already usable today. It asks a few simple questions and gives you:
A discovery size recommendation
Relevant Double Diamond phases
A clear activity plan to match
More features are on the way including team dashboards, data export, and integration with project management tools such as Jira and Asana.
Try it out for free today and let me know what you think!