Opportunity assessment for product managers
An opportunity assessment is the structured review I use to decide whether a customer problem is worth pursuing now. It helps me move from “someone asked for this” to a clearer view of the problem, the people affected, the evidence available, the strategic fit, and the cost of learning more. It is not a business case that proves an idea will work. It is a decision aid for choosing whether and how to investigate an opportunity.
I use an assessment when a problem sounds important but the team does not yet share the same understanding. The process slows down premature solution design without turning discovery into an endless research phase.
Define the opportunity as a problem
I start with a plain-language description of the situation a person is trying to handle. I include who is affected, what they are trying to accomplish, when the problem appears, and what happens when it does. “Customers need automation” is too broad for a useful assessment. “Operations teams spend time reconciling exceptions between two systems before they can approve an order” gives me something I can investigate.
I separate the opportunity from the proposed solution. A request for a dashboard may point to a visibility problem, a coordination problem, or a lack of confidence in the underlying data. I do not reject the requested solution automatically; I keep it as one possible response while I learn what outcome people actually need.
I also state what is outside the scope of the assessment. A narrow question is easier to test than a category such as “improve onboarding” that contains several workflows and audiences.
Identify the people and context
I describe the audience in terms of context rather than demographics alone. I want to know the role, workflow, frequency, stakes, existing tools, and constraints around the problem. A problem that is occasional and easy to recover from may need a different response from one that blocks a time-sensitive or regulated task.
I look for variation across segments. One group may experience the problem often but have a workable workaround; another may encounter it less often but face a much higher cost when it happens. Combining them into one average can hide the reason an opportunity matters.
At this stage I write assumptions explicitly. I might believe that the buyer and daily user feel the same pain, that the current workaround is expensive, or that the problem is growing. I label those statements as assumptions until I have evidence.
Gather evidence without overstating it
I use the lightest credible evidence for the question in front of me. Support conversations can reveal recurring language and failure points. Interviews can help me understand a recent episode. Product data can show behavior patterns. Sales and implementation notes can expose adoption friction. A prototype or technical spike can test whether a proposed direction is understandable or feasible.
I distinguish direct observation from interpretation. “People export the report and compare it with another file” is an observation. “They need a real-time dashboard” is an interpretation that may or may not follow. I record the source, date, and context of important evidence so a later reader can judge how much weight to give it.
I avoid using an impressive-looking number when I cannot explain how it was produced. If evidence is mixed, I say so. A small set of interviews can generate useful questions, but it does not establish prevalence across an entire market. The assessment is stronger when it makes uncertainty visible.
Evaluate value and strategic fit
I ask what improves if the problem is reduced. The value may be customer time, confidence, reliability, revenue potential, retention, risk reduction, or a better ability to complete a core job. I do not assume that every valuable customer problem is automatically the right problem for our product to pursue.
I compare the opportunity with the product strategy and current capabilities. Does it serve a segment we can support well? Does it reinforce a direction we have chosen? Would solving it create a useful platform capability or pull the team into an unrelated market? Strategic fit is not a reason to ignore evidence, but it helps me decide whether this opportunity belongs with this product and this team.
I also consider the cost of leaving the problem alone. Sometimes the cost is visible in lost usage or support effort; sometimes the more honest answer is that we do not yet know. I state that uncertainty instead of manufacturing a precise estimate.
Examine alternatives and constraints
Before recommending a build, I list the ways the problem could be addressed. The options may include a product change, better guidance, a service or process change, an integration, a partnership, or choosing not to act. I consider what customers already do and whether a simpler improvement could remove most of the friction.
I ask engineering, design, legal, security, operations, and go-to-market partners for constraints early enough to matter. A technically possible idea may still be inappropriate because of data access, permissions, maintenance, procurement, or trust. These constraints do not always end the opportunity; they may change the audience, sequence, or experiment.
I make the cost of learning part of the comparison. A reversible test can be sensible even when the final solution would be substantial. A large commitment deserves stronger evidence about the problem and the path to value.
Make a decision and name the next test
At the end, I choose among a small set of outcomes: pursue discovery, run a focused experiment, reshape the opportunity, defer it, or stop. I explain what evidence led me there and what would change the decision. “Do more research” is not enough; I name the question, method, owner, and review point.
I revisit the assessment when new evidence changes the audience, severity, strategic fit, or constraints. An opportunity is not a permanent label. Customer behavior and company priorities move, so a deferred problem may deserve a fresh look later.
A practical starting exercise
I write a one-page assessment with five sections: problem and context, affected people, evidence and assumptions, value and strategic fit, and options with constraints. I ask one teammate who was not part of the original request to read it and highlight every statement that sounds more certain than the evidence allows. Then I choose the smallest next step that could change the decision.
An opportunity assessment works for me when it creates shared understanding before shared commitment. It respects customer problems without treating every request as a roadmap promise, and it makes the reasoning behind a product decision easier to inspect.
Next step
This guide to the lean canvas for PMs helps me turn a broad product opportunity into a focused set of hypotheses and next tests.
Build stronger product strategy, discovery, and prioritization skills in the Product Manager Certification. Subscribe to the Product HQ newsletter for practical frameworks and career-ready product lessons.
