New Product Development Process: Stages, Gates, and Handoffs

Most teams do not fail new product development because they skip a stage. They fail because they move between stages without a decision: an idea slides into build before anyone checks the evidence, a prototype is called "validated" with no stated criteria, and launch happens with no named owner for what comes after.

This guide is the end-to-end map. It shows the seven stages of the new product development (NPD) process in order, what enters and exits each stage, the gate criteria that justify moving forward, where validation and MVP belong, and how discovery hands off to delivery and then to launch without losing what was learned.

Quick answer

• NPD runs through seven stages: idea generation, idea screening, concept and business case, design and development, testing and validation, launch, and post-launch learning.
• Each stage ends at a gate: a go, kill, hold, or recycle decision against explicit exit criteria, not a status meeting.
• Validation and MVP work sits mainly in stages 3 to 5, where each test must answer a named risk before the team commits more budget.
• Handoffs carry context, not just documents: the outcome, the evidence, the rejected alternatives, the open risks, and the conditions that would reopen the decision.
• Launch is a milestone inside the process. Post-launch evidence decides whether the team continues, iterates, or stops.

Table of contents

• The direct answer: the NPD map in 60 seconds
• The seven NPD stages and what each produces
• Gates and exit criteria: when you may move forward
• Where validation and MVP sit inside NPD
• The handoff flow: discovery to delivery to launch
• Handoff checklist and artifact flow
• Worked mini-pass: a hypothetical example
• After launch: iteration, kill, and continue signals
• Common failure points
• Frequently asked questions
• References and further reading
• Why CraftUp helps

The direct answer: the NPD map in 60 seconds

The new product development process turns a raw idea into a product that earns its place in the market. The classic formulation comes from Stage-Gate, the model developed by Robert Cooper: work is organized into stages, and stages are separated by gates where leaders decide whether the project still deserves funding. Atlassian and Asana publish the same shape in practitioner form — six to seven sequential stages from idea to launch — and both stress that in product teams the flow is iterative rather than strictly linear.

The version on this page keeps the standard seven stages and adds what generic stage lists leave out:

1. Inputs and outputs per stage — what must exist before the stage starts and what the stage must produce.
2. Exit criteria per gate — the evidence bar that justifies spending the next, larger budget.
3. Validation and MVP placement — which tests belong where, and what each test must prove.
4. Handoff mechanics — what travels with the work when it moves from discovery to delivery to launch.

If you need depth on one phase rather than the full map, this page points you there and stops: full discovery method lives in the Product Discovery course and the discovery and delivery guide, validation method in problem validation, and launch execution in the launch checklist.

The seven NPD stages and what each produces

Stage 1: Idea generation

Every product starts with a problem worth solving. Ideas can come from customer interviews, support tickets, sales conversations, product analytics, market research, and internal observation. The goal here is volume with provenance: capture each idea alongside the observation that triggered it, not as a bare feature request.

A useful idea record has three fields: the observed problem, who experiences it, and where the observation came from. Anything missing all three is a guess wearing an idea costume — it can stay in the pool, but it may not skip screening.

Stage 2: Idea screening

Screening separates opportunities worth paid investigation from ideas that are too costly, poorly timed, misaligned with strategy, or built on nothing. Score each idea against the same small set of lenses:

• Customer need: is there evidence a real problem exists for a reachable segment?
• Business value: would solving it move an outcome the company cares about?
• Strategic fit: does it point where the product is actually headed?
• Feasibility: can the team plausibly build and operate it?
• Effort and reversibility: how expensive is it to try, and how hard is it to undo?

Kill ideas in writing, with the reason. A shortlist without recorded rejections invites every killed idea back in the next planning argument. For method depth on comparing opportunities, see prioritization frameworks.

Stage 3: Concept and business case

The surviving idea becomes a concept: a plain-language narrative of what you would build, who it serves, which problem it solves, why now, and how the business benefits. This is where the PR FAQ review process earns its keep — writing the launch story before building forces the team to state the customer value first and surface the assumptions that must hold.

A complete business case names the target user, the value proposition against alternatives, rough economics, success signals to be tracked after launch, and the three to five assumptions that could sink the project. If the team cannot name what would prove the concept wrong, the concept is not ready for design spend.

Stage 4: Design and development

Design turns the concept into progressively more concrete representations: sketches, clickable prototypes, technical spikes, then production-quality scope. Development turns approved scope into something the business can run: engineered, tested, instrumented, documented, and operable.

The critical discipline in this stage is keeping discovery open while building. Feasibility findings, usability detail, and edge cases appear during implementation — the team should be able to narrow scope or revisit the bet without pretending the plan was perfect. The discovery and delivery guide covers exactly how learning work and production work interact around one bet.

Stage 5: Testing and validation

Testing proves three different things, and confusing them is the most expensive mistake in NPD:

• Does it work? Functional, performance, reliability, and security checks.
• Can people use it? Usability with the actual target user, not with colleagues.
• Is it wanted? Behavioral evidence that the target user chooses and keeps using it.

Each test needs a pre-stated claim and a bar: what would pass, what would fail, and what happens on each outcome. A test that cannot change the plan is theater. See where validation and MVP sit for which method belongs at which point.

Stage 6: Launch

Launch coordinates the release across product, marketing, sales, and support: messaging, rollout sequencing, enablement, documentation, customer communication, and a monitoring plan for the success signals defined back in stage 3. The launch checklist and the product launch plan template carry the execution detail; this page owns only the gate into launch and the handoff that makes it stick.

Nothing launches without a named post-launch owner and a review date. A launch with no owner is where learning goes to die.

Stage 7: Post-launch learning

After release, compare what happened against the mechanism the team expected: did the intended behavior change, for whom, and what explains the gap? The output is a decision — continue, iterate, narrow, expand, or stop — recorded with its evidence. Surprises become the next round of ideas, closing the loop back to stage 1.

Gates and exit criteria: when you may move forward

A gate is a funding decision, not a status update. At each gate, the people who control the next stage's budget decide among four outcomes: go, kill, hold, or recycle (send back with a named question to answer). The Stage-Gate model is explicit that gates are forward-looking resource commitments, and that every go decision must confirm resourcing — budget, people, timeline, and the next gate date — so the team never gets approval without the means to proceed.

Three rules keep gates honest:

1. No gate without criteria written beforehand. Criteria invented at the meeting always fit the work that was done.
2. No go without resources. An approved project with no budget or people is a hold wearing a go costume.
3. Kill is a success. Killing a weak concept at gate 2 is the process working — it is the cheapest possible failure.

Where validation and MVP sit inside NPD

Validation is not one stage; it is a sequence of tests placed where each can still change the plan cheaply. The MVP — the smallest thing that produces real behavioral evidence — is one instrument in that sequence, not a synonym for a rough first release.

Two placement mistakes cover most validation waste. First, testing willingness with a prototype and calling it demand: polite interest in a demo is not evidence anyone will change behavior. Demand evidence requires behavior with a cost — time, money, reputation, or workflow change. Second, building the MVP before the problem is established: an MVP that tests everything at once teaches nothing when it fails. Each test should isolate one named risk so a negative result still tells the team what to change.

For the full validation method — when research beats building, which evidence suits which risk, and how much is enough — use problem validation. For the MVP decision specifically, the Product Discovery course covers assumption testing and experiment design.

The handoff flow: discovery to delivery to launch

NPD breaks most often at the boundaries: discovery learns something delivery never hears, or delivery ships something launch cannot explain. The fix is not heavier documents. It is a rule: context travels with the work, and the same cross-functional team stays accountable across the boundary.

The flow has two handoffs, each with a direction:

Discovery to delivery. Discovery produces evidence about the decision: the problem, the target user, the alternatives considered and rejected, the assumptions tested, and the risks still open. Delivery needs all of it, because scope trade-offs during build are product decisions — an engineer who does not know which assumption is load-bearing cannot judge which shortcut is safe. The handoff moment is the build commitment at gate 3: the team agrees on what is being committed to, what is explicitly out of scope, and what would reopen the decision.

Delivery to launch. Delivery produces a releasable product plus everything launch needs to represent it truthfully: what changed, for whom, what is limited or known-broken, how to tell whether it works, and how to roll back. Launch needs this before messaging is written, not after. The handoff moment is the launch-readiness check at gate 4: support, documentation, instrumentation, communication, and rollback are confirmed ready, each by its owner.

In both handoffs, the failure mode is the same: a document thrown over a wall between groups that never meet. Prefer one accountable team with the relevant specialists in the room — product, design, engineering from discovery onward; marketing, sales, support, and operations joining as the launch boundary approaches.

Handoff checklist and artifact flow

Copy the checklist that fits the boundary you are crossing. Each line needs a name and a date, not just a checkmark.

Discovery-to-delivery handoff (at build commitment)

# Discovery to delivery handoff

## Decision being committed to
[One sentence: what the team is now spending production capacity on]

## Desired outcome and success signals
[Behavior change expected + the signals defined in the business case]

## Evidence behind the bet
- [Strongest customer evidence + source]
- [Strongest behavioral or market evidence + source]
- [Feasibility or spike result, if any]

## Alternatives considered and rejected
- [Option + why it lost]

## Scope and non-goals
- In scope: [...]
- Explicitly out of scope: [...]

## Open risks with owners
- [Risk + owner + how it will be watched during delivery]

## Reopen trigger
[What evidence forces the team to revisit the commitment]

## Decision owner and contributors
[Names + date]

Delivery-to-launch handoff (at launch readiness)

# Delivery to launch handoff

## What is releasing, for whom
[Scope + target audience or cohort]

## Known limitations
[What is limited, rough, or explicitly not covered]

## Support and success readiness
- Support briefed: [name + date]
- Docs and help content live: [link]
- Instrumentation and dashboards: [link]

## Rollout and rollback
- Rollout sequence: [...]
- Rollback path and owner: [...]

## Launch communication
- Message owner: [...]
- Channels and sequencing: [...]

## Post-launch owner and review date
[Name + date when outcome evidence gets inspected]

The artifact flow behind both checklists is small on purpose: concept narrative (the PR FAQ is a strong default), a prototype or spec the team actually builds from, a test log tying each result to its named risk, and the two handoff notes above. Anything beyond that should justify itself against a repeated failure — the product operations rituals guide shows how to add process only where inconsistency keeps costing the team.

Worked mini-pass: a hypothetical example

This example is hypothetical. It exists to show how the stages, gates, and handoffs connect on one pass — not to describe any real company.

A B2B team serving operations managers notices a pattern in support tickets: new accounts stall during workspace setup, and the stall correlates with a permission-approval step owned by someone outside the product's user base.

• Stage 1: The team records the opportunity with provenance — thirty tickets in a quarter, plus three sales-call mentions — tied to workspace administrators at mid-size accounts.
• Gate 1: The idea passes screening because the problem is observed (not requested as a feature), the segment is reachable, and activation is a company-level outcome. Two other ideas are killed in writing: a dashboard redesign with no supporting evidence and an integration for a segment the company is deprioritizing.
• Stage 3: The concept narrative proposes guided setup with explicit trust and approval-state messaging, deliberately scoped away from a full onboarding rebuild. The riskiest assumption is named: that the delay is caused by uncertainty about the approval step rather than by the approval step itself being slow for external reasons.
• Gate 2: The concept passes because the team can state what would prove it wrong — and has a test planned: five task-based prototype sessions plus an inspection of approval timestamps in product data.
• Stage 4: Prototype sessions show admins complete setup when the approval state is visible and explained. The timestamp data confirms approvals take hours, not days — uncertainty, not external process, is the bottleneck. Scope narrows to messaging, checklist, and status states; the full wizard is cut.
• Gate 3: Build is committed with open risks named: highly regulated accounts may stall for genuinely external reasons, owned by the PM to watch in delivery.
• Stage 5: The MVP ships to a bounded cohort with instrumentation. Setup completion rises for standard accounts; regulated accounts stall as predicted.
• Gate 4: Launch readiness passes for general availability with a documented limitation for regulated accounts — and support briefed on exactly that boundary.
• Stage 7: The post-launch review records a continue-with-narrowing decision: expand the improved setup to all standard accounts, and open a new discovery question on the regulated-account approval workflow. That question re-enters stage 1 with evidence attached.

The lesson the example is built to show: gates changed the shape of the bet three times (kill two ideas, cut the wizard, limit the launch), and each handoff carried the reasoning forward instead of restarting it.

After launch: iteration, kill, and continue signals

Post-launch evidence should be read against the success signals from stage 3, not against activity. Useful signal groups:

• Continue: the intended behavior moved for the target segment, guardrails hold (support load, reliability, adjacent metrics), and the next improvement is smaller than the last.
• Iterate: behavior moved partially or for a sub-segment, and the gap points at a named, testable cause — a usability friction, a missing integration, a misunderstood step. Narrow the next bet to that cause.
• Kill or park: the behavior did not move after a fair test, the economics fail at realistic scale, a constraint blocks the segment that needs it, or every iteration teaches less than the last. Record the evidence so the idea does not resurrect without new information.

Set the review before launch, at gate 4, when optimism is highest and the criteria are still honest. A team that schedules its own reckoning in advance is far more likely to hold it.

Common failure points

• Skipping screening. Every idea gets concept work, so concept work means nothing and the loudest stakeholder wins.
• Gates without criteria. The meeting reviews what was done instead of deciding whether the next spend is justified.
• "Validated" with no stated bar. A prototype reaction is treated as demand evidence without any behavioral cost.
• MVP that tests everything. A rough release with five simultaneous unknowns fails opaquely — no result points at a cause.
• Handoff as document toss. Delivery receives a spec without the rejected alternatives, open risks, or reopen triggers, and optimizes for the wrong thing.
• Launch with no owner after. Nobody inspects the outcome, so nobody learns, and the next bet starts from zero.
• Zombie projects. A weak concept is never killed, only delayed — consuming attention across every planning cycle. Kill in writing or commit honestly.
• Roadmap before concept. Sequencing and dates are promised before the problem, user, and economics exist. Roadmapping discipline belongs after the business case — see theme-based roadmapping and the roadmapping hub for that phase done well.

Frequently asked questions

What are the stages of the new product development process?

The standard sequence is idea generation, idea screening, concept and business case, design and development, testing and validation, launch, and post-launch learning. Each stage produces specific outputs — an opportunity pool, a shortlist, a concept narrative, prototypes and then production scope, test results, a coordinated release, and a recorded continue-or-stop decision — and each transition is guarded by a gate with explicit exit criteria.

What is a gate in the NPD process, and who decides?

A gate is a funding decision between stages: go, kill, hold, or recycle. The people who control the next stage's budget make it, using criteria written before the work started. A go decision must confirm resourcing — budget, people, timeline, and the next gate date — so the team never receives approval without the means to proceed.

Where do validation and MVP fit in new product development?

Validation runs from the concept stage through pre-launch, with each test isolating one named risk: problem reality first, then value proposition, then usability and feasibility, then real behavior via an MVP with a bounded audience, then market and operational readiness. The MVP belongs where only real usage can answer the question — after the problem is established and before scaled build.

How is NPD different from product discovery or product delivery?

NPD is the full end-to-end journey from idea to post-launch decision. Product discovery (reducing uncertainty before and during commitment) and product delivery (building and releasing production-quality scope) are kinds of work inside that journey. The discovery and delivery guide covers how the two interact around a single bet; this page owns the map they both sit on.

What roles are involved in the NPD process?

Product management typically owns the concept, the gates' evidence, and the decisions; design owns research craft and experience quality; engineering owns feasibility and implementation; marketing, sales, support, operations, legal, and finance join where their constraints or craft apply — especially around launch. One cross-functional team should stay accountable across the handoffs rather than handing documents between silos.

How long does the new product development process take?

It ranges from weeks for a small, reversible improvement to many months for a complex or regulated product. The honest answer depends on product complexity, evidence already in hand, team size, reversibility, and testing requirements. Build the timeline into the roadmap after the business case exists — promising dates before the concept is the failure pattern, not the plan.

References and further reading

Methodology sources first — these define the models this page builds on:

• Stage-Gate model overview — Robert Cooper's official description of stages, gates, gatekeepers, and the go, kill, hold, recycle decisions.
• Atlassian: new product development process — a practitioner seven-stage walkthrough with screening criteria and launch coordination.
• Asana: product development process — six stages plus Agile, Stage-Gate, and Lean framework comparison and success metrics.

Continue inside CraftUp where each phase gets its depth:

• Product discovery vs delivery — how learning work and production work interact around one bet.
• Problem validation: when to research vs build — the full validation method this page summarizes.
• Product launch checklist — launch execution detail.
• Theme-based roadmapping and the roadmapping hub — sequencing after the business case.
• PR FAQ template and review process — the concept narrative artifact.
• Product operations rituals — lightweight process that survives contact with reality.

Why CraftUp helps

Running a full NPD pass requires judgment across every stage — framing problems, testing assumptions, scoping delivery, and reading launch evidence. That judgment compounds with practice.

• Product Management Foundations for the end-to-end system: discovery, validation, strategy, roadmap, and execution.
• Product Discovery for the assumption-testing and experiment muscle stages 3 to 5 demand.
• Master Problem Validation when the riskiest unknowns are about the problem itself.
• PRD Generator, Product Roadmap Template, Product Launch Plan Template, and Release Checklist Builder for the artifacts each handoff needs.
• New to the role itself? The product manager 30-60-90 day plan shows how to ramp into owning a pass like this one.

Start free on CraftUp to build the habit: https://craftuplearn.com