Most products that fail don’t fail because the idea was bad. They fail because somebody skipped a stage, usually validation, and nobody noticed until the launch was quiet.
This is a walkthrough of the product development process: the eight stages, who owns each one, what comes out of it, and what breaks when you skip it. It also covers what almost nothing else online covers properly, what changes when you build with AI tools, and what changes when the product itself runs on one. We’ll get to acceptance criteria that stop meaning much once your output isn’t deterministic anymore. That’s coming, promise.
Quick scope note first: this phrase means slightly different things in software and in physical goods. We’ll lead with the digital process, since that’s what most readers here are actually running, and map the classic manufacturing model onto it further down.
What Is the Product Development Process, Actually?
The product development process is the end-to-end sequence a team follows to take an idea from an identified customer problem through validation, definition, design, build, testing and launch, then keep improving it using evidence from real usage.
That’s the textbook definition, and it undersells what the model is for. Each stage is a decision point, you either commit more resource, or kill the idea. The whole value of having stages is that it forces the kill decision to happen early, when it’s still cheap to be wrong.
Here’s the bit almost every diagram gets wrong: this isn’t a line, it’s a loop. Stage eight feeds back into stage one. Draw it as a line and eventually nobody revisits the finish line.
Worth two sentences on lineage. Robert G. Cooper’s research on industrial new-product projects gave us Stage-Gate; Eric Ries gave us build-measure-learn under Lean Startup; the Silicon Valley Product Group popularised dual-track discovery running alongside delivery. Nobody here was arguing semantics, they were solving for how expensive being wrong is, in their own industry.
Product development vs. product management
Development is the process of building the thing. Management is deciding what to build and why, and it runs across the whole process rather than sitting inside one stage. Development is the verb, management is the judgment. A team can run a flawless process and still ship the wrong product. For a fuller sense of what a product manager actually does across the process, worth reading separately.
Product development process vs. product life cycle
These get mixed up constantly, and the names don’t help. Development is internal, it’s what your team does, and you control it. The product life cycle, introduction, growth, maturity, decline, is external, driven by demand and competition, and you can only influence it. Development ends, for a given release, when the product ships. The life cycle starts once it does. That’s a separate topic with its own article.
The 8 Stages of the Product Development Process
Here’s the map first, before any prose gets in the way. This is the one table worth screenshotting.
| # | Stage | Objective | Owner | Output | Common failure |
| 1 | Discovery & ideation | Find a problem worth solving, not an idea worth building | PM | Prioritised problem statement | Ideation with no evidence behind it |
| 2 | Validation | Prove the problem’s real and the solution fits, before spending engineering time | PM + design | Validated concept + business case | Skipping straight to build |
| 3 | Definition & prioritisation | Turn a validated concept into a scoped, agreed thing | PM | PRD, backlog, success metric | Scope set by whoever argued hardest |
| 4 | Design | Make it usable and feasible before code gets written | Design | Flows, prototype, tech design doc | Usability testing deferred till after build |
| 5 | Build | Turn the spec into a working, instrumented increment | Engineering | Working build behind a flag | Analytics left as a “later” task |
| 6 | Test | Confirm it works, is usable, hasn’t broken anything else | QA | Defect log, sign-off, beta feedback | Testing squeezed to absorb build delays |
| 7 | Launch | Get it into users’ hands safely, tell whoever needs to know | PM + PMM | GTM plan, live release, rollback plan | Support finds out on launch day |
| 8 | Measure & iterate | Find out if it worked, decide what’s next | PM + data | Post-launch review, updated backlog | No pre-agreed metric, so success is negotiable |
Eight is a model, not a law. You’ll see this sliced into five, six, seven or ten stages elsewhere, all describing the same underlying work. What matters is each block happens and produces something real, not the count.
1. Discovery and ideation
Discovery is evidence-gathering. Ideation is option-generating. Do the second without the first and you build things nobody asked for. Interviews, support tickets, app reviews, usage data, competitor changelogs, all count. In most Indian consumer products, the support queue is the single most under-read source of insight, and almost nobody reads it systematically. Exit question: can you say the problem in one sentence and point to evidence someone has it?
2. Validation
The stage everyone skips, and why most failure modes further down exist at all. Climb a cheap ladder before committing anything expensive: a problem interview costs an hour, a concept test a day, a fake-door test a week, a clickable prototype a sprint. Climb only as high as the decision requires.
3. Definition and prioritisation
Where the PRD lives, in short: the written answer to what we’re building, for whom, why, and how we’ll know it worked. The cheapest scope-creep prevention is writing down what you’re deliberately not building. RICE gives you a number to argue with instead of a vibe: reach times impact times confidence, divided by effort. A feature reaching 2,000 users, medium impact (2), high confidence (0.8), two weeks of effort, scores 800. At least now you’re disagreeing about something concrete.
4. Design
Flows, then wireframes, then high-fidelity, then a testable prototype. Usability testing here is the last genuinely cheap moment to be wrong; after code gets written, changes get expensive fast. Most articles skip the technical half entirely, a mistake, since architecture review and feasibility should have started back in stage two.
5. Build
The stage everyone already understands, so, briefly: instrument as you go, an event added later is data you never look at historically. Protect the spec, scope creep here is how a two-sprint feature quietly becomes a two-quarter one. The PM’s real job during build isn’t managing engineers, it’s unblocking fast and saying no often.
6. Test
Four things get called “testing,” and conflating them is how bugs slip through: functional QA, regression, usability, and beta or UAT on real data. On usability, Nielsen Norman Group’s classic finding is that five users typically surface most of a design’s problems. For India specifically: test on a mid-range Android device over patchy data, not flagship phones on office Wi-Fi. Functionally, two different products.
7. Launch
Launch is a plan, not an event. Phased rollout, feature flags, and the internal half everyone forgets, support, sales, docs, pricing. A launch nobody was told about is indistinguishable from one that failed.
8. Measure and iterate
The metric should already have been agreed in stage three, otherwise this stage devolves into an argument about what “good” even meant. Shipping metrics (did we deliver) and outcome metrics (did anything actually change for the user or the business) are not the same thing, and only the second one counts. Schedule the post-launch review before launch, with a date and named attendees, or it quietly never happens. For teams pulling their own numbers instead of waiting on an analyst, being able to query product data directly is a genuinely underrated skill at this stage, and a structured process for turning that usage data into decisions is worth building deliberately rather than improvising every time.
The Classic New Product Development Model, and How It Maps
If you studied marketing, you learned eight stages ending in test marketing and commercialisation. If you work in software, you learned discovery, build and iterate, and probably never heard the word “commercialisation” once. Same process, described by two industries with different constraints. Worth saying plainly, since half the confusion here comes from nobody saying it.
The classic eight, in order
Idea generation, idea screening, concept development and testing, marketing strategy development, business analysis, product development, test marketing, commercialisation. It originated where being wrong meant a factory run rather than a sprint, which is why it front-loads so much screening before anything gets built.
| Classic NPD stage | Modern equivalent | What changed |
| Idea generation | Discovery & ideation | Evidence comes from analytics and support queues now, not focus groups |
| Idea screening | Discovery (prioritisation) | Continuous and cheap, not a quarterly gate committee |
| Concept dev & testing | Validation | Prototypes and fake-door tests replace concept boards |
| Marketing strategy dev | Part of Launch (GTM) | Moved later, demand validated before positioning is final |
| Business analysis | Validation (business case) | Revisited continuously, not decided once at a gate |
| Product development | Definition + Design + Build | One stage split into three, software lets you re-decide mid-build |
| Test marketing | Beta / phased rollout / A-B test | Test on 1% of live users instead of one city |
| Commercialisation | Launch + Measure & iterate | Launch isn’t the finish line; software keeps changing after |
What genuinely differs for physical products: tooling and moulds are capital commitments made before real demand data exists, minimum order quantities set a floor on your first run, and unit economics have to close before launch, not after. The decisive constraint is that you cannot ship a patch to inventory already sitting in a warehouse. Hardware and D2C teams working with contract manufacturers in India feel this acutely.
Who’s Actually Involved
PM owns the why and what. Engineering owns feasibility and how. Design owns the experience. QA owns the quality bar. A data analyst owns the evidence. Product marketing owns positioning and launch. Sales and support own the field feedback loop. Leadership owns the size of the bet.
What’s usually missing isn’t the role list, it’s who decides versus who’s just consulted. Most process failures on real teams are unclear decision rights wearing a disguise. And in most Indian startups below Series B, one person holds the PM, PMM and analyst roles at once, often before their first coffee. Anyone weighing a product path against a business analyst path will recognise this overlap already.
Which Methodology Should You Actually Use?
Four names get thrown around constantly, and most articles list them neutrally and leave you stranded. Not doing that here. These answer different questions: Stage-Gate asks should we keep spending on this, Agile asks how do we deliver reliably in small pieces, Lean Startup asks is this business worth existing, dual-track asks how do we keep learning while we keep shipping.
| Stage-Gate | Agile / Scrum | Lean Startup | Dual-Track Agile | |
| Optimises for | Capital discipline, risk control | Delivery predictability | Speed of learning | Build tied to learning |
| Best for | Hardware, regulated products, tooling cost | Established products, known customer | Pre-PMF, 0→1 bets | Post-PMF teams still discovering |
| Where it fails | Slow; gates turn political | Efficiently ships the wrong thing | “MVP” excuses poor quality | Needs real research capacity |
So, which one. Default for a software team: dual-track. It’s the only one of the four that structurally prevents the most expensive failure mode in this article, building without validating, while still shipping on a predictable rhythm. Plain Agile (per the Scrum Guide) doesn’t protect against that on its own, it assumes someone upstream already validated. Stage-Gate protects against it, but far too slowly for software’s pace.
Before product-market fit, run Lean Startup instead, sprint ceremonies are overhead when you don’t yet know if the product should exist. Switch to dual-track once you’ve got retention worth defending. Reach for Stage-Gate when being wrong is expensive and irreversible, hardware, regulated products, where a wrong call means a written-off tooling run. Most real teams run some hybrid anyway, and the label matters less than whether discovery is actually happening. No framework saves a team that hasn’t talked to a user this month.
The Process in Practice: How Meesho Went From Fashnear to a Reseller Marketplace
Every competing article names Uber or Airbnb in a sentence and moves on. Nobody traces the stages properly, so here’s one done properly, using a company most readers here will already recognise.
Stages 1 and 2, the first attempt. In December 2015, IIT Delhi graduates Vidit Aatrey and Sanjeev Barnwal launched Fashnear, a hyperlocal fashion discovery app: catalogue nearby boutiques, connect them to local buyers, deliver the orders yourself. Reasonable idea on paper. Discovery was thin, which is the point. Fashion buyers weren’t confined to their neighbourhood, and boutique owners wanted customers from across the city, not three streets over. The hyperlocal constraint fought the market on both sides at once.
The kill decision. According to Elevation Capital’s own account, the founders noticed something else while doing user research for Fashnear: several boutique owners were already reselling through WhatsApp and Facebook, no app involved. That’s stage 1 doing its job, an insight found in behaviour, not a brainstorm. The problem they’d validated (people want to discover local fashion) still had an invalidated solution. Recognising that gap is what stage 2 exists for.
Stages 3 through 5, building for a different user. The reseller wasn’t the buyer, which changed everything: catalogue sharing, margin-setting, order tracking on someone else’s behalf, payments, and a product that had to work on modest Android phones over patchy connectivity in tier-2 and tier-3 towns. “It works” got defined by the user’s constraints, not whatever phone sat on the founders’ desks.
Stages 6 through 8, and the double-down. Rather than betting the company on the pivot outright, the team ran the new model, Meesho Supply, alongside the older product for a stretch, watching how each grew before committing fully. WhatsApp wasn’t a bolted-on channel, it was the entire distribution strategy. The pivot followed the evidence, it didn’t precede it.
The transferable lesson is short: the process didn’t stop the first idea from being wrong, it made being wrong survivable, and surfaced the right product from inside the failed one, because someone was still watching usage data after launch. Stage 8, quietly doing its job. For the story straight from a co-founder, Sanjeev Barnwal walks through Meesho’s early days and scaling years in a longer conversation (runs just over an hour, worth knowing going in; the mid-point on early competitive scaling is most relevant here).
What Actually Changes in the AI Era
No hype paragraph here about AI transforming everything. It hasn’t replaced the eight stages. What it’s done is collapse the cost of several of them, and every time a cost collapses somewhere, the bottleneck quietly moves somewhere else. That’s the useful thing to notice.
What got faster
Prototyping. A working, clickable prototype can now get built in hours by a PM or designer with zero engineering time. That changes stage 4 for real, the last cheap chance to be wrong just got cheaper again, so there’s no honest excuse left to skip prototype testing.
Research synthesis. Clustering thirty interview transcripts, or mining months of support tickets for themes, used to eat a week of stage 1. Now it’s an afternoon. Which themes matter is still human judgment. The sorting isn’t.
First drafts. PRD skeletons, user stories, edge-case lists, all draftable in minutes, though the review is still the actual job. Treat every AI-generated artifact as a first pass from a fast junior colleague who’s never once spoken to your users, because that’s roughly what it is. For anyone comparing which generative AI tools are actually worth using for drafting and prototyping, it’s a fast-moving list, worth rechecking every few months.
What got harder
Deciding what deserves to exist at all. When building was expensive, cost was a filter, most bad ideas died of economics before anyone had to judge them. That filter’s gone now, so judgment is the bottleneck. Stage 2 got more important, not less, the most counterintuitive line here.
Validation debt is real too, a prototype that looks finished isn’t a validated product. And review load: drafting got ten times faster, reviewing didn’t, so the reviewer is now the constraint. Worth a look against Scaler’s own India AI Workforce Report 2026 for a grounded read on adoption across Indian teams.
When the product itself is AI-powered, acceptance criteria stop working
This is the part almost nobody writes about. A conventional acceptance criterion is a deterministic contract: given input X, the system returns output Y. QA checks it, pass or fail, done. An LLM-powered feature breaks that at the root, since the same input can produce different outputs on different runs, and both might be fine, or both might be subtly wrong in ways a pass-fail test was never built to catch.
Follow that through the stages and it stops being philosophical fast. In definition, “the summary should be accurate and concise” isn’t a requirement, it’s a wish in requirement’s clothing. Requirements for AI features need to become measurable quality criteria, a rubric, a scored set of dimensions, a target pass rate against representative cases. Shorthand: evals become the spec.
In testing, you can’t pass-fail a probabilistic system off one run. Testing becomes evaluation against a curated golden dataset, scored by deterministic checks, model-based judges and human review, reported as a distribution rather than a green or red light. A regression means the score dropped, not that the test failed.
In launch, the bar shifts from zero critical defects to an acceptable quality rate at an acceptable failure rate, which puts two new things on the checklist: a guardrail layer, and a UX that assumes the system will sometimes be wrong. Confidence signals, easy correction paths, honest failure states, these move from polish to core requirement. Frameworks like the NIST AI Risk Management Framework and ISO/IEC 42001 exist because this shift needed structure, not just good intentions.
And in iteration, the product can change without you touching it. A model update or a small prompt tweak can shift behaviour overnight, so monitoring has to cover output quality, not just uptime. One worked example, since abstract advice is useless: instead of “the assistant should give accurate answers,” write three testable things, a deterministic format check, a factual-coverage check against source documents, a rubric-scored clarity rating with a stated pass rate. That’s the whole shift, in miniature. Two more inputs enter every prioritisation call now: cost per interaction and latency, both product decisions with a direct line to margin. For the operational side, there’s an overview of AI automation tools built for exactly this.
What Actually Goes Wrong, and How to Prevent It
Every competitor has a “common challenges” section, usually about tool sprawl. Not what actually kills products. Here’s what does, tied to the stage that got skipped, with a prevention cheaper than the failure.
• Building without validating. Six months of engineering on an idea nobody tested. Fix: no commitment until stage 2 produces some evidence, however small.
• Starting from the solution, not the problem. The feature exists because a senior stakeholder asked for it. Fix: require a written problem statement with named evidence before anything enters the backlog.
• Scope creep. The two-sprint feature that quietly becomes a two-quarter one. Fix: write the non-scope into the spec; anything added mid-build displaces something equal.
• Launching with no agreed success metric. Nobody decided what “good” looked like. Fix: agree the metric and target in stage 3, in writing, review date set before launch.
• No instrumentation. Launch happened, the analytics didn’t, “did it work” is unanswerable forever. Fix: treat events as part of the definition of done.
• Treating launch as the finish line. Everyone moves on and nobody looks back. Fix: schedule the post-launch review before launch, with named attendees.
The AI demo trap, new for 2026. A prototype built in a day looks finished, gets demoed to leadership, gets greenlit before anyone validates demand or quality. Fix: keep “we built it” and “we evaluated it” as two separate claims.
How Long Does This Actually Take?
A small software feature runs weeks. A substantial new product usually runs months. A physical product with tooling, sourcing and certification runs quarters, sometimes years. Variables: how much is genuinely new, regulatory load, hardware versus software, decision speed, and discovery done before the clock started.
One pattern worth remembering: teams almost always underestimate stages 2 and 6, and overestimate stage 5. Compressing testing to absorb a build overrun is the most common, and most expensive, scheduling call on real teams.
Frequently Asked Questions
What is the product development process?
The end-to-end sequence a team follows to take an idea from an identified problem through validation, design, build, testing and launch, then improve it using evidence from real usage. It loops back rather than ending.
What are the stages of the product development process?
Eight, most commonly: discovery, validation, definition and prioritisation, design, build, test, launch, and measure and iterate. You’ll see this sliced into six, seven or ten stages elsewhere; labels change, the work doesn’t.
What are the 7 stages of new product development?
Idea generation, idea screening, concept development and testing, business analysis, product development, test marketing and commercialisation, often shown as eight when marketing strategy development gets its own line.
What’s the difference between the development process and the product life cycle?
Development is what your team does to build and improve a product, and you control it. The life cycle is what happens to it in the market, introduction to decline, and you can only influence that.
What’s the difference between product development and product management?
Development is building the thing. Management is deciding what to build and why, and it runs across every stage rather than living inside one of them.
Which methodology should you actually use?
For most software teams past product-market fit: dual-track agile. Before PMF, Lean Startup. For hardware or anything regulated where mistakes are expensive and irreversible, Stage-Gate.
How long does the process take?
A small software feature: weeks. A substantial new product: usually months. A physical product with tooling and certification: quarters or longer. Regulatory load and decision speed move the range more than headcount.
How is AI changing the product development process?
It’s made prototyping and first drafts far cheaper, shifting the bottleneck to judgment. When the product itself runs on AI, non-deterministic outputs mean acceptance criteria have to become measurable evaluations, not fixed pass-fail rules.
The Short Version
Eight stages, not a bureaucracy. Each exists to make being wrong cheap, a less glamorous goal than most process diagrams pretend. AI has collapsed the cost of several stages, which makes the ones built on judgment, validation especially, more important than before, not less.
Pick the stage your team is worst at, and fix that one first. Not all eight, just the one costing you products right now. Usually validation, if you’re honest, and most teams aren’t.
