What is the single most costly mistake you can make in any significant product endeavor?
It isn't a bug that crashes the app on launch day. It isn't a missed deadline or a slightly over-budget marketing spend. While those are painful, they are fixable. No, the most expensive mistake, the one that sinks companies and burns through millions … is solving the wrong problem. It is the act of being incredibly efficient at building something that nobody actually needs.
In my recent article on Product and Design Reviews (PRDR), I wrote about the danger of building high-fidelity solutions to the wrong problems. That piece covered the ritual of a weekly core team meeting: a "toll booth" where you review ODs and design concepts to ensure you aren't veering off course. But if the PRDR is the filter, we need to talk about the substance being filtered.
Today, I want to dive deeper into the specific technique I use to prevent these "wrong direction" disasters: Opportunity Definition.
To be clear, this is not a grand new revelation. Much has been written about the transition from "solution-first" to "problem-first" approaches. Yet, here we are in 2026, and I still see teams jumping straight to the "how" before they've even agreed on the "why." If anything, the rise of AI-enabled development and "vibe coding" has only made the problem worse. It's now easier than ever to move fast, generate code, and ship features based on a general feeling. But moving fast in the wrong direction just gets you lost sooner.
On anything beyond a minor feature tweak, we have to stick the starting direction. Every single time.
Shifting from the Solution Space to the Problem Space
Opportunity Definition (OD) is a deliberate pause. It is the time and place to capture high-level thinking about a strategic theme while it is still in its formative stage.
The operative word here is problem.
In life, we are taught to be optimists; to see the glass as half-full. In product development, however, blind optimism is a liability. You cannot "will" your way to a successful outcome if you don't understand the core friction your user is experiencing. You might get lucky and stumble upon a solution to a real problem by accident, but hope is not a strategy.
If you set out without understanding the core problem, no amount of gritty execution can correct the situation. You'll be barking up the wrong tree and won't find out until months after launch, when the lackluster results reveal the wrong path you've been marching down. Here is why high-performing product teams must force themselves into the problem space first:
1. It Forces Customer Obsession
Problem framing is the ultimate anchor for customer centricity. When your process starts with a user's unmet needs, you are virtually guaranteed to be working on something that matters to them. Users are notoriously bad at "solutioning." They struggle to tell you what they want, but they are experts in their own pain. If you start with a solution—especially one cooked up by internal stakeholders who are three steps removed from the daily grind of the user—you are guessing.
2. It Guards Against Natural Biases
Confirmation bias is the silent killer of innovation. It happens when we enter research or design already "knowing" the answer, looking only for data that validates our assumptions. When you lead with a solution, you effectively shut down creative thinking. After all, what is the point of being creative when the answer is already decided? Starting with the problem keeps the aperture wide and invites the team to explore multiple paths to a solution.
3. It Aligns Outcomes over Outputs
Without a clear problem statement, you have no way of knowing if a proposed solution is actually good. You end up measuring outputs (how many features did we ship?) rather than outcomes (did we actually solve the pain?). Defining the opportunity upfront lets you identify the northstar metrics that will tell you whether you've actually moved the needle.
4. It Avoids "Local Maxima"
As Martin Eriksson of Mind the Product once noted, jumping straight to solutions often leads to optimizing for "local maxima." This is when a team spends months fine-tuning a conversion funnel by 2%, only to realize later that the entire workflow was unnecessary. By stepping back to define the opportunity, you realize that there is a far bigger mountain to climb that was just out of view.
The Opportunity Definition Framework
In practice, an Opportunity Definition is a high-level "straw man" document. It isn't meant to be a 50-page PRD; it's a 5-to-10-hour exercise intended to flesh out a hypothesis and identify what we know versus what we are merely guessing.
While you can format this as a visual "Opportunity Canvas," a structured document often works best for deep-thought collaboration. Here are the core components of a strong OD, streamlined to focus on the essentials:
- Vision (The Core Objective): A 1-2 sentence description of what you hope to accomplish.
- Success Metrics (Outcomes): The primary metric this initiative is expected to move (e.g., "Reduce churn in Group X" or "Speed up process Y").
- Target Users (Audience): Who is the specific segment, and why should they care about this change?
- Pain Points (The "Why"): The heart of the OD. A visceral description of the user's struggle. What are their workarounds? Where are they failing?
- Business Requirements (The "What"): Ultra high-level requirements that address the pain points. Note: These are not features. They are functional needs.
- Assumptions (The "Known Unknowns"): A transparent list of what you are assuming to be true but haven't proven yet.
- Strategic Questions (The "Unknown Unknowns"): Outstanding questions regarding tech, design, pricing, or market fit. Some might need to be answered before moving forward. Others are there just to remember they need to be answered in the follow-up design phase.
The most critical part of this framework is the Pain Points section. I prefer the term "Pain Points" over "Problems" because it is more visceral. It nudges the author to empathize with what the customer is actually going through.
Ownership and Forward Momentum
The Product Manager is the ultimate owner of the OD. Since the PM has the final say on what gets worked on and why, the responsibility for framing the problem falls squarely on their shoulders.
However, they shouldn't do this in a vacuum. The PM leads the process, gathering feedback from design, engineering, and stakeholders, and then presenting the OD at a product review. The goal isn't perfection … it's "good enough" to move forward.
When do you need an OD?
A common question is: Do I need to do this for every single bug fix or minor feature? The answer is no. That would be "process for the sake of process" (and would slow things down considerably.) Use the Opportunity Definition for any strategic theme on your roadmap—the big bets that you are tackling over the next 12–18 months. If an item is important enough to be included on your strategic roadmap, it is meaningful enough to require a defined problem statement.
When is the OD "Finished"?
You are ready to move on from the Opportunity Definition when you have:
- A solid understanding of the pain points.
- A rough breakdown of business requirements.
- Enough clarity to prioritize which parts of the problem to tackle first.
The ultimate outcome of an OD isn't always a "Go." Sometimes, the most successful OD is the one that results in a "No-Go." Killing a project in the definition phase saves the company months of wasted effort—and that is a massive win for the organization. That said, if you have a solid product strategy and have done a good job with the strategic roadmap, the OD will rarely result in a no-go decision since the strategy & roadmap are already very problem-centered.
It's also worth noting that starting with an OD increases the odds of maximizing your value velocity measurements.
Final Thoughts: The Mindset Shift
While the primary goal of the Opportunity Definition is to align a specific initiative, the secondary benefit is cultural.
When you institutionalize a "problem-first" approach for your largest initiatives, that mindset eventually trickles down to the smallest tasks in your backlog. Engineers start asking "Why?" before they ask "How?" Designers start questioning whether a feature is solving a pain point or just adding clutter.
In an era of vibe coding and automated workflows, the clearest way to succeed is to make sure you aren't running at full speed toward a cliff. Speed is no longer the primary constraint. Direction is.
Define the opportunity first. Your customers (and your bottom line) will thank you.