Product development process flowchart (stage-gate template)
A stage-gate product development process flowchart: idea screening, business case, gate 1 go or kill, design, validation, pilot, gate 2 and launch review.
How it works
Rename the lanes to your real functions
Replace Product management, Engineering and R&D, Design, Quality and Commercial with the functions you actually have. Hardware teams usually split Engineering into mechanical, electronics and manufacturing engineering; software teams often have no separate Quality lane and should fold validation into engineering rather than leave an empty band. Merge any lane you cannot attach a named owner to, and keep the lane count at what fits on one screen.
Write the gate criteria before the first review
A gate without written criteria becomes a presentation. For gate 1, state what the business case must contain and the thresholds that make it a Go: the market size you consider worth pursuing, the feasibility questions that must be answered rather than assumed, and the regulatory scope. For gate 2, state what pilot evidence is required. Agree both while nothing is waiting at the gate, because criteria negotiated on the day are criteria written by whoever is most invested in a Go.
Decide what Recycle and Extend pilot actually mean
The two soft branches are where stage-gate processes rot. Recycle at gate 1 should carry a specific list of what must change, an owner and a date to return; otherwise it is a Kill nobody wanted to say. Extend pilot at gate 2 should name what is being learned, how long the extension runs and the criterion that ends it. Record both against the project rather than in meeting notes, and count how often each is used — a gate that only ever recycles is not deciding anything.
Keep design review and validation as separate checks
They answer different questions. The design review asks whether the design and prototype meet the specification agreed at the start of development, and it is a peer and stakeholder check on the design itself. Validation testing asks whether the finished product meets the user need and the regulatory requirements in real conditions. Keeping them apart is what makes the two rework loops in this chart meaningful: one catches a design problem before you spend on test units, the other catches a requirements problem before you spend on a pilot.
Define the pilot and its exit criteria
"Run a limited production pilot" means something different in every organisation: a pre-production batch, a soft launch to one region, an early access cohort. Write down which it is, the volume or customer count, what is being measured — yield, defect rate, support load, activation — and how long it runs before gate 2 is convened. A pilot without a defined end is how launch dates slip without any decision being made.
Name the gate owners and record the decisions
For each gate, name the person who holds the call and the group that must be present. One named owner per gate is better than a committee that decides by absence of objection. Capture the outcome, the date, the criteria applied and the rationale — especially for a Kill, since an unrecorded kill reappears as the same idea in six months. If you work to a quality management system, this record is also the evidence that reviews took place.
Publish it, then revise it after each launch
Share the chart where the work happens, next to the gate templates rather than in a policy folder, and get the lane owners to sign it off. After each launch, walk the flow with the team: which gate was skipped, which loop was taken and why, and whether the post-launch review actually happened or was overtaken by the next project. Keep the previous versions so you can show when the process changed and what prompted it.
Frequently asked questions
What are the stages of a product development process?
Five stages cover most product organisations. First, idea and screening: capture the idea and test it against strategy, before any function commits effort. Second, business case: assess technical feasibility, outline the concept, identify the regulatory requirements and size the market, then pull all four into one case and take it to gate 1. Third, design and development: agree the requirements and specification, develop the detailed design, build a working prototype and hold a design review. Fourth, validation: plan and run validation testing against the specification, then run a limited production pilot once it passes. Fifth, launch and review: take the gate 2 launch decision, launch to market, then hold a post-launch review and close the project.
What is a stage-gate process, and what can a gate decide?
A stage-gate process groups development work into stages and puts a decision point between each one, so that funding and effort are released in increments rather than all at the start. The conventional gate outcomes are go, kill, hold and recycle: proceed to the next stage, stop the project, park it against capacity or priority, or send it back to rework the current stage before deciding. This template shows go, recycle and kill at gate 1, and launch, extend pilot and kill at gate 2. If your gates never produce anything but go, they are not gates, and the portfolio management they are supposed to provide is not happening.
What is the difference between a design review and validation testing?
A design review checks the design against its inputs: does the detailed design and the prototype meet the specification agreed at the start of development, and are the open risks understood. Validation testing checks the product against the need: does it work for the user, in realistic conditions, against the requirements including any regulatory ones. Verification is the first question, validation the second, and quality management standards treat them as separate activities for good reason. In this chart they are two decisions with two separate return paths into detailed design, because a design flaw found at review is far cheaper than the same flaw found after test units have been built.
How is this different from a software release process or a go/no-go decision tree?
Scope. This chart covers the whole development cycle, from an idea entering the pipeline to a post-launch review, and treats each launch decision as a single gated node. The software release process at /templates/software-release-process starts much later, at a code-complete build, and details branch cuts, test gates, staging, deployment, rollback and hotfixes. The go/no-go decision tree at /templates/go-no-go-decision-process goes the other way and expands one gate into a dozen evidence questions with five named outcomes. Use this page to define the cycle, and either of the others for the part of it you need in more detail.
Who should own each gate decision?
One named person per gate, with the contributing functions attending as evidence rather than as votes. Gate 1 usually sits with whoever owns the portfolio and the budget — a product director, a general manager, or the leadership group in a smaller organisation — because it is a decision about where development capacity goes. Gate 2 is a readiness decision as well as a commercial one, so the owner needs the authority to hold a launch when quality or supply is not ready, not just to approve it. Write the decision rights down before the first gate: an unassigned gate defaults to whoever is most senior in the room on the day.
How many gates should a product development process have?
Fewer than you think, and only where a real decision exists. Two are shown here because they mark the two points where committed spend jumps: gate 1 authorises development, gate 2 authorises launch and the production, marketing and support cost that follows. Larger or more regulated programmes commonly add a gate between concept and detailed design, and one before validation begins. The useful test is whether the gate could plausibly return anything other than go. If a review has never once stopped or changed a project, remove it, or move it to where the money actually gets committed.