Opportunity Assessment for Product Managers: template, structure and example
A Product Manager's Opportunity Assessment turns a validated customer problem into a clear read on whether it is worth deeper validation or investment. It sets out the problem, who is affected, strategic fit, value potential, the smallest scope worth building, effort and feasibility, and a recommended next step with an accountable owner.
Reviewed by Gensudo Team · Last reviewed 24 July 2026
When to use it
Create it in Discover, once you have evidence of a real customer problem and need to decide whether to pursue it. Use it when an idea has enough substance to justify a structured look but not yet enough to commit engineering effort. It is the document that carries an opportunity into the Feature Opportunity Matrix with evidence, a recommendation and named ownership intact.
When not to use it
Skip it when the problem is still unvalidated guesswork, where discovery conversations or a discovery brief come first. If the decision is portfolio or funding level rather than a single opportunity, the Head of Product version fits better. And if you are simply ranking already-assessed opportunities against each other, move to a prioritisation framework instead.
What you need before you start
- A validated customer problem, with the trigger and unmet need it addresses
- The affected personas, segments or accounts, and a rough sense of reach and frequency
- How the opportunity relates to current product strategy and roadmap themes
- Early evidence of customer and business value, plus any contradicting signals
- Rough input from design, engineering and data on effort, complexity and dependencies
- The riskiest assumptions and what would need to be true for the opportunity to work
Recommended structure, section by section
- Summary and Recommendation — The opportunity, the recommendation, the strength of the evidence, the priority, and the immediate decision in brief.
- Customer Problem and Need — The underlying problem, the unmet need, the trigger, and the user outcome the opportunity addresses.
- Target Users, Reach and Demand Size — The affected personas, segments, and accounts, the number affected, the rate of occurrence, and the urgency or timing pressure.
- Strategic Fit — The alignment with product strategy, roadmap themes, target market, and business priorities.
- Customer and Business Value Potential — The expected customer value, the revenue impact, the retention and expansion impact, and the operational impact.
- Options to Pursue It — The viable approaches, the scope levels, the experience changes, the partnerships, and the non-product options.
- MVP and Learning Scope — The smallest valuable scope, the learning goals, the riskiest assumptions, and the evidence needed for the next decision.
- Effort and Feasibility — The rough delivery effort, the technical complexity, the data needs, the operational impact, and the dependency landscape.
- Risks and Assumptions — The principal risks to the assessment, the assumptions it depends on, their likelihood and impact, the early-warning signals, and the mitigation or validation each requires.
- Evidence and Confidence — The evidence base behind the assessment, the quality and recency of its sources, the coverage and consistency it provides, the contradicting signals, and the confidence level in the conclusions.
- Decision and Sequencing — The recommended priority, the sequencing logic, the dependency order, and the relationship to other opportunities.
- Recommended Next Steps — The immediate action, the accountable owner, the decision checkpoint, and the conditions for progressing, parking, or stopping.
- Ownership and Review — Who owns the assessment, the accountable owners and contributors, where the source evidence lives, the review rhythm and decision rights, and the events that trigger a revisit.
What good looks like
A strong Opportunity Assessment is practical: it teaches the reader what matters, then helps them act. The recommendation is supported by evidence rather than personal preference, assumptions are stated, agreements are shown, and trade-offs are visible. A new reader who was not in the original conversations can describe the opportunity, see the recommended next step, know who approved it and understand what would make it need updating.
Quality checklist
- The recommendation and the immediate decision are stated up front and backed by evidence
- The riskiest assumptions and the evidence still needed for the next decision are explicit
- Effort, feasibility and dependencies reflect real input from design, engineering and data
- Risks carry likelihood, impact, early-warning signals and a mitigation or validation path
- An accountable owner, decision checkpoint and conditions to progress, park or stop are named
- Contributors across product, design, delivery, data and insight have been coordinated before sign-off
- Open questions are visible and the review trigger is recorded
Who creates it, and when
In Gensudo this document is a governed template for:
- Product Manager in the Discover phase (as “Opportunity Assessment”)
Where it sits in the flow
Before this document: Customer Problem Statement for Product Managers · Market Research Report for Heads of Product
This unblocks: Validation Findings Report for Product Managers · Business Case for Heads of Product
Prefer to see one finished? Read a complete, cited Opportunity Assessment for Product Managers example for a early-years edtech product.
Writing one from scratch? Read the step-by-step guide: How to Write an Opportunity Assessment: Steps, Examples and Checklist.
Frequently asked questions
How is this different from the Head of Product's Opportunity Assessment?
The Product Manager's version focuses on a specific customer problem: the MVP and learning scope, the effort and feasibility, and whether this one opportunity is worth deeper validation. The Head of Product's version is more strategic and portfolio-level, covering commercial model, go-to-market fit, kill criteria and review cadence.
How much effort and feasibility detail do I need?
Enough to make the decision honestly, not a delivery estimate. Capture rough delivery effort, technical complexity, data needs, operational impact and the dependency landscape, drawn from quick input with engineering and data. Precision comes later, once the opportunity is validated.
What is the MVP and learning scope for?
It is the smallest valuable scope that lets you test the riskiest assumptions and gather the evidence the next decision needs. It keeps the assessment honest about what you would actually build first and what you are trying to learn, rather than describing a full solution.
Who signs it off?
Final sign-off normally sits with the Product Manager, with agreement from accountable product, design and delivery leads. Do not request sign-off until evidence, risks, decisions and named owners are clear and open questions are visible.
Create this document in Gensudo
The governed template, role-specific guidance and AI drafting grounded in cited evidence.
Get started