Competitive Analysis for Product Managers: template, structure and example

When to use it

Create it in Discover, before the Persona Document, when you need to understand how users currently solve a problem through competitor products, manual workarounds, internal tools or spreadsheets. Reach for it when a feature, workflow or product area needs a shared, evidence-led view of where you can differentiate and where you are exposed. It is the right document when the decision at stake is a product one: what to build, what to fix, and how to sequence it.

When not to use it

If the question is market sizing, portfolio direction or executive investment rather than workflow-level comparison, the Head of Product's Competitive Analysis fits better. If you already understand the competitive picture and simply need to define who you are building for, move on to the Persona Document. Skip it when the gap is a known bug or a single obvious fix that needs no comparison.

What you need before you start

• The feature, product area or discovery question being assessed, and the decision it supports
• The user jobs, pain points and desired outcomes that make each competitor or substitute relevant
• The set of competitors, substitutes, workflows and segments in scope, plus what you have deliberately excluded
• Hands-on or documented evidence of competitor workflows, screens, pricing signals and interaction patterns
• Customer evidence such as interviews, support tickets, sales feedback, reviews, usability tests and win-loss notes
• Source and observation dates, with the product-version context behind each competitor claim

Recommended structure, section by section

1. Summary of Findings — The key competitor observations, the user implications, the product gaps exposed, the differentiation opportunities, and the recommended next actions.
2. Purpose and Initiative Context — The feature, product area, user problem, or discovery question being assessed, the decision it supports, and the scope it covers.
3. User Problem and JTBD Context — The user jobs, pain points, workflow needs, and desired outcomes that make a competitor or substitute relevant to the comparison.
4. Scope of Comparison — The competitors, substitutes, workflows, use cases, segments, and exclusions covered by the comparison, and the rationale for the chosen set.
5. Competitor and Substitute Workflows — The ways users currently solve the problem through competitor products, manual workarounds, internal tools, spreadsheets, or service processes.
6. Evaluation Criteria — The comparison criteria across workflow fit, usability, capability depth, integrations, permissions, performance, and edge-case handling.
7. Feature, Capability and Workflow Matrix — The side-by-side comparison of the relevant capabilities and how well each option supports the target user workflow end to end.
8. User Journey Comparison — The comparison of steps, friction points, time to complete, information architecture, and interaction patterns across the competing journeys.
9. UX and Interaction Pattern Review — The screens, flows, navigation, empty states, error handling, onboarding, and accessibility patterns observed across the products.
10. Pricing, Packaging and Commercial Signals — The observable packaging, pricing signals, plan boundaries, trial mechanics, procurement friction, and commercial positioning of each competitor.
11. Strengths, Weaknesses and Product Gaps — The competitor strengths, the competitor weaknesses, the product gaps exposed, and the defensible differentiation opportunities they reveal.
12. Customer Evidence — The interviews, support tickets, sales feedback, reviews, usability tests, win-loss notes, and behavioural analytics linked to competitor or substitute usage.
13. Source Dates and Evidence Freshness — The source dates, the observation dates, the product-version context, and the freshness risks behind the competitor claims.
14. Opportunity Areas — The potential improvements, workflow enhancements, differentiated capabilities, and unmet needs the analysis reveals.
15. Prioritisation Implications — The backlog implications, discovery priorities, MVP scope, sequencing options, and the trade-offs across customer value and delivery effort.
16. Risks, Assumptions and Open Questions — The unknowns, technical constraints, dependency risks, evidence gaps, and the assumptions that still need validation.
17. Recommended Next Steps — The immediate decision, the accountable owner, and the validation, delivery, or monitoring action that follows from the analysis.
18. Ownership and Review — Who owns the document, 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

It is strong when another product lead can grasp the issue without a long verbal briefing from you, and can trace the line between the evidence shown and the decision being asked for. Competitor propositions, strengths, weaknesses and gaps are compared against the target user workflow end to end, assumptions are explained, and trade-offs across customer value and delivery effort are visible. A new reader can describe the purpose, name the recommended next step, see who approved it and identify what would make it need updating.

Quality checklist

• A new reader can describe the purpose of the analysis and the user problem it serves without a verbal explanation
• The feature, capability and workflow matrix shows how well each option supports the target workflow end to end
• Product gaps and defensible differentiation opportunities are stated with the evidence that reveals them
• Every competitor claim carries its source date, observation date and product-version context
• The recommended next step names an accountable owner and the validation, delivery or monitoring action that follows
• Input has been coordinated across Product Owner, design, engineering, data, delivery, customer insight, sales and marketing
• Open questions, assumptions and evidence gaps are visible rather than buried

Who creates it, and when

In Gensudo this document is a governed template for:

• Product Manager in the Discover phase (as “Competitive Analysis”)

Where it sits in the flow

Before this document: Market Research Report for Heads of Product

This unblocks: Persona Document for Product Managers · Opportunity Assessment for Product Managers · Product Strategy Document for Heads of Product

Prefer to see one finished? Read a complete, cited Competitive Analysis for Product Managers example for a early-years edtech product.

Writing one from scratch? Read the step-by-step guide: How to Write a Competitive Analysis: Steps, Examples and Checklist.

Frequently asked questions