Core Concepts
Three frameworks. One PM.
Select a framework below.
The Product Development Cycle (PDC) defines how a product is built, from identifying problems to delivering and learning from outcomes.
Discovery
Is this worth solving?
You validate whether a problem is real, who it affects, and whether solving it justifies the investment. No solution discussion. Only problem understanding.
As a PM, this means...
You own the go/no-go decision. If Discovery does not surface a validated, sizeable problem: You Stop. Not Pause. Stop. The hardest PM skill here is the courage to kill an initiative before any code is written.
- → Run 5–8 structured user interviews per user segment
- → Analyse support tickets, NPS verbatims and session recordings
- → Size the problem: frequency × severity × users affected
- → Map existing workarounds and failure modes
- → Write a problem statement, not a solution statement
- → Present a quantified go/no-go recommendation
Discovery is complete when the team can answer three questions with evidence, not opinion: Who has this problem? How frequently and severely? Is it large enough to justify solving?
Skipping Discovery because leadership already decided. Your job is to surface the riskiest assumption before a single engineer is allocated.
Definition
What exactly are we building?
You translate the validated problem into a precise, buildable specification. You decide scope, success metrics, acceptance criteria, and what is explicitly out of scope.
As a PM, this means...
You own the PRD. Not just writing it, but its accuracy and alignment. Every requirement must connect to a specific user problem from Discovery. If an engineer asks "why are we building this?", the PRD must answer that question.
- → Write the PRD: scope, success metrics, and out-of-scope items
- → Define acceptance criteria for every key user story
- → Apply MoSCoW or RICE to scope decisions
- → Align engineering on technical constraints before development
- → Run a design or prototype sprint to validate solution direction
- → Get stakeholder sign-off on both the problem and the solution
Definition is complete when the PRD is signed off by engineering, design, and key stakeholders. Every Must Have item has a written acceptance criterion. Success metrics are defined and instrumented.
Writing a solution document instead of a requirements document. The PRD defines what success looks like, not how to build it.
Development
Are we building it right?
Engineering builds the defined solution across iterative sprints. The PM's role shifts from creating requirements to protecting the team and managing change.
As a PM, this means...
You do not write code, but you own what gets built and why. Your job is to protect the team from scope creep, remove blockers before standups, and ensure each Sprint Goal connects to the product strategy.
- → Own the Sprint Goal for every sprint, not just the task list
- → Run sprint planning, review, and retrospective ceremonies
- → Manage scope changes and assess impact before accepting new requirements
- → Review engineering progress against acceptance criteria, not just feature completion
- → Maintain the Definition of Done as a quality gate
- → Communicate progress and risks to stakeholders proactively
Development is complete when all Must Have acceptance criteria are met, the Definition of Done is passed for every story, no critical or high-severity bugs remain, and the support team has been briefed on known issues.
Declaring done when the feature is built, not when the acceptance criteria are met. The Definition of Done exists for exactly this reason.
Launch
Are we ready to release it?
You coordinate go-to-market activities, rollout sequencing, stakeholder communication, and success measurement. Launch is a PM-owned event, not an engineering milestone.
As a PM, this means...
You own the launch decision. Not engineering, not marketing. You decide whether to ship, delay, or rollback based on pre-defined criteria. "We worked hard on this" is not a launch criterion.
- → Define success metrics before launch, not during or after
- → Write the Launch Plan: staged rollout, go/no-go criteria, and rollback procedure
- → Coordinate with marketing, sales, support, and legal before release
- → Plan the release type: feature flag, canary, beta, or full rollout
- → Set up monitoring dashboards before release, not after you need them
- → Brief the support team on known issues and escalation paths
Launch is complete when the feature is live, monitoring is active, and the support team is briefed. The post-launch review date is already scheduled before the launch happens.
Defining success metrics after launch. By then, the baseline is unknown and the data is already biased by the support team's response to launch issues.
Post-Launch
Did it actually work?
You measure actual outcomes against pre-defined success metrics, collect qualitative feedback, and generate learnings that feed directly into the next Discovery cycle.
As a PM, this means...
Post-Launch is where the cycle loops back. The learnings you generate here become the Discovery inputs for the next initiative. Most PM attention disappears after launch. This is exactly backwards. The most valuable signal often arrives 4–8 weeks after release.
- → Measure actual outcomes against pre-defined success metrics
- → Run cohort analysis on early adopter retention
- → Collect qualitative feedback from interviews, support tickets, and NPS verbatims
- → Write a Post-Launch Review: what worked, what did not, and why
- → Decide whether to iterate, pivot, or move on
- → Feed learnings directly into the next Discovery phase
Post-Launch Review is complete when actual versus expected metrics are documented, the root cause of any gap is identified, and specific recommendations for the next cycle are written and presented to the team.
Skipping the Post-Launch Review because the team is already focused on the next initiative. Schedule the review before launch and put it on the calendar first.
The Product Lifecycle (PLC) describes how your product evolves and positions commercially within the market.
Introduction
Is there a market?
Market Signal
Low penetration. Proving the category exists. Early adopters only.
PM Priority
Validate Product Market Fit (PMF). Build awareness. Prioritise learning over scaling.
Watch Metric
Time to first 1,000 paying users. PMF survey score.
As a PM: Do not scale until PMF is validated. Every rupee spent on acquisition before PMF is a rupee wasted.
Growth
Scale what works?
Market Signal
Rising fast. Growing faster than market average. Expanding TAM.
PM Priority
Scale acquisition. Double down on retention. Maintain product quality under growth pressure.
Watch Metric
CAC vs LTV ratio. Retention cohorts by acquisition channel.
As a PM: The Growth stage has a finite window. Missing it by over-managing is as costly as missing it by moving too slowly.
Maturity
Defend the position?
Market Signal
Growth slowing. Competition intensifying. Market share becoming the metric that matters.
PM Priority
Defend market share. Find adjacencies. Improve unit economics. Retention > acquisition.
Watch Metric
Market share. NPS. Expansion revenue from existing customers.
As a PM: Treating a maturity-stage product like a growth product drives inefficient acquisition spend instead of focusing on higher-ROI retention.
Decline
Invest or sunset?
Market Signal
Falling demand. Losing share even with increased investment. New substitutes dominating.
PM Priority
Assess: reinvest (pivot), harvest (maximise margin), or sunset (graceful exit). Make the call explicitly.
Watch Metric
Churn rate. Cost-to-serve. ROI of reinvestment vs alternatives.
As a PM: The Decline decision is the hardest and most avoided. Explicitly choosing to sunset a product is better strategy than quietly starving it of investment.
Product-Market Fit (PMF) indicates how well your product satisfies a real market need and whether it is ready to scale.
PMF is not a feeling. It is measurable. It sits between Discovery and the Growth stage of the PLC.
What PMF Is
A measurable signal, not a feeling
PMF exists when a meaningful proportion of users would be genuinely disappointed if your product ceased to exist and retention curves flatten.
How to Measure It
The Superhuman PMF Survey
Ask users: “How would you feel if you could no longer use this product?” Options: Very disappointed / Somewhat / Not disappointed.
Benchmark: Over 40% answering "Very disappointed" is a strong PMF signal. Below 25% means you have not found it yet.
As a PM, this means…
Do not scale before PMF
More marketing, features, and sales before PMF only amplify the mismatch between your product and the market.
PMF is a moving target. Re-measure it regularly.