Product development process flowchart (stage-gate template)

What the product development process flowchart (stage-gate template) process is

A product development process turns a stream of ideas into a small number of launched products, and the work it does is mostly subtraction. Any organisation can generate concepts; the discipline is deciding which ones stop, and stopping them early enough that the money has not already been spent. That is what a stage-gate structure is for. Work is grouped into stages, each stage ends at a gate, and a gate is only a gate if it can say no. Without a kill branch you do not have a gate, you have a status meeting: projects arrive with momentum, nobody wants to be the person who ends one, and the portfolio silently fills with half-alive programmes that consume engineering capacity without ever reaching a launch decision.

This page maps the whole cycle, idea to post-launch review, for a cross-functional product team. It is deliberately wider in scope than three neighbouring templates. It is not the software release process at /templates/software-release-process, which picks up at a code-complete build and ends at production monitoring, and it is not the go/no-go decision tree at /templates/go-no-go-decision-process, which zooms all the way into the launch readiness gate and expands it into a dozen evidence questions. If your product is already launched and you are handling modifications to it, the process you want is change control at /templates/change-control-process. Here, the launch gate is one node with three branches; everything before it, from idea screening to a limited production pilot, is the substance of the chart.

The template runs twenty steps across five swimlanes (Product management, Engineering and R&D, Design, Quality, and Commercial) laid out over five stages: idea and screening, business case, design and development, validation, and launch and review. It includes the loops most drawn versions leave out: a recycle branch that sends a weak business case back for rework rather than killing it, a failed design review that returns to detailed design, a "Meets requirements?" decision that routes failed validation back into design rather than forward into a pilot, and an extend-the-pilot branch at gate 2 for a product that is nearly ready but not yet.

What this flowchart covers

In this template

• Five functional lanes (Product management, Engineering and R&D, Design, Quality and Commercial) laid out over five stages: Idea and screening, Business case, Design and development, Validation, and Launch and review.
• A screening step before any spend: an idea is captured in the pipeline and screened against strategy in the Product management lane, so weak concepts are filtered out before four functions are asked for effort.
• Four separate inputs to the business case, one per function: technical feasibility from Engineering and R&D, the product concept from Design, regulatory requirements from Quality, and market sizing from Commercial, all pulled into "Build the business case".
• Gate 1 with three named outcomes: "Gate 1: develop or kill?" branches Go to requirements and specification, Recycle back to the business case for rework, and Kill to "Idea shelved with rationale" as a terminating reject.
• Two distinct rework loops into "Develop the detailed design": "Design review passed?" returns on Rework before validation is attempted, and "Meets requirements?" returns on No after validation testing, so a failed test never leaks into the pilot.
• Gate 2 as the launch decision: "Gate 2: approve launch?" branches Launch to market in the Commercial lane, Extend pilot back to the limited production pilot, and Kill to "Launch stopped at gate 2", with a post-launch review and closure ending the flow.

When to use this template

• You are introducing a stage-gate process for the first time and need one agreed picture of the stages, the gates and who owns each, before it becomes a template pack and a set of meeting invitations.
• Projects in your portfolio never seem to stop: nothing is formally killed, capacity is spread across too many live programmes, and no one can point to the decision that authorised each of them.
• Development work is being started before the business case exists, or the specification is being written after the design, and you need to show the intended order to the people doing the work.
• You are aligning the process with a quality management system (ISO 9001 clause 8.3 covers design and development, and expects planning, reviews, verification and validation to be carried out and recorded) and need the flow before you write the procedure.
• Handoffs between product, engineering, design, quality and commercial are the real bottleneck, and you want to see which function is holding the work at each stage rather than argue about it after a missed launch date.

How it works

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.