New Product Development Roadmap: Stages, Gates and a 12-Month Example
8 min read ยท 2026-10-25
A new product development roadmap is a plan that takes a product from an idea to a launch in a set of stages, each with a goal, an owner and a decision at the end: continue, change course or stop. Most teams cover discovery, validation, design, build, launch preparation and launch, over six to eighteen months depending on the product.
What sets it apart from a roadmap for an existing product is uncertainty. You do not yet know if anyone will buy it, so the early stages are about proving demand before you spend real money on building. The template below spans 12 months in six stages. Each one ends with a gate, a short meeting where a sponsor decides if the evidence is strong enough to keep going. You also get a filled-in example, a gate checklist, owners for each stage and a one-slide format for leadership.
The roadmap at a glance
Goal: Launch a new product to a defined first market within 12 months, with demand proven before the main build and launch metrics agreed in advance. Duration: 12 months
Opportunity and business case (Weeks 1-4)
Define the problem, the target customer and why this product is worth exploring now.
- Write a one-page opportunity brief: target customer, problem, current alternatives and why now.
- Size the opportunity with a simple bottom-up estimate based on reachable customers, not a top-down market figure.
- List the riskiest assumptions, such as customers will switch from spreadsheets or we can hit the target unit cost.
- Name an executive sponsor and a product lead who owns the roadmap.
Milestone: Gate 1: sponsor approves the brief and a budget for discovery only.
Customer discovery (Weeks 5-10)
Confirm that the problem is real, frequent and painful enough for the target customer.
- Interview 15 to 20 people in the target segment about how they handle the problem today.
- Map their current workflow and note what they already pay for or spend time on.
- Group findings into three to five problem statements ranked by frequency and pain.
- Update the assumption list: mark each one as confirmed, rejected or still unknown.
Milestone: Gate 2: a discovery readout with ranked problem statements, and a go decision to test solutions.
Concept and validation (Weeks 11-18)
Test whether customers want your proposed solution before you build it.
- Turn the top problem into two or three solution concepts with rough sketches or an interactive prototype.
- Run concept tests with target customers and ask for a commitment, such as a pilot slot or a letter of intent.
- Test pricing direction with simple willingness-to-pay questions.
- Check technical feasibility and rough cost with engineering or manufacturing leads.
Milestone: Gate 3: one concept chosen, with signed pilot commitments and a feasibility review, and a go decision to fund the build.
Design and build the first release (Weeks 19-34)
Build the smallest version that solves the main problem well for pilot customers.
- Write requirements for the first release and cut everything not needed by the pilot customers.
- Plan the build in two-week sprints with a demo to the sponsor every month.
- Set up quality checks: test plan, security review and, for physical products, prototype testing.
- Keep a risk log with an owner and a fallback for each risk.
- Prepare pilot agreements and onboarding material with customer success.
Milestone: Gate 4: first release passes its test plan and is ready for pilot customers.
Pilot and launch readiness (Weeks 35-44)
Prove the product works for real customers and get every team ready to sell and support it.
- Run the pilot with the committed customers and hold a check-in with each one every two weeks.
- Fix the issues that block daily use and log the rest for after launch.
- Finalize positioning, pricing, sales collateral and the support playbook.
- Train sales, support and operations, and agree on the launch date with every team lead.
Milestone: Gate 5: pilot success criteria met and a launch readiness checklist signed off by every function.
Launch and early growth (Weeks 45-52)
Release the product to the first market and confirm it performs against the targets set before launch.
- Launch to the first market with a single owner for launch day and a war room for the first week.
- Track the launch metrics weekly in one dashboard shared with the sponsor.
- Collect feedback from the first customers and turn it into the next quarter's roadmap.
- Hold a launch retrospective with every team that took part.
Milestone: Post-launch review at week 52 comparing results with targets, and a decision to scale, adjust or stop.
New product development roadmap vs product roadmap
A product roadmap for an existing product plans improvements to something customers already use. You have data, a team and a running release process. A new product development roadmap starts with none of that. Its main job is to reduce uncertainty in the right order, so the expensive work happens only after the cheap tests say yes.
That changes what goes on the roadmap. Instead of features by quarter, you show stages, the evidence each stage must produce and the decision at the end. Once the product launches, switch to a normal product roadmap organized by outcomes or themes.
What a gate review looks like
A gate is a short decision meeting at the end of each stage. The product lead presents the evidence, the sponsor decides, and the decision is written down. The options are go, go with conditions, rework the stage, or stop. Stopping a product at Gate 2 is a good outcome: you learned cheaply that the idea does not work.
Write the gate criteria at the start of each stage, not at the end. If you set the bar after you see the results, the bar tends to move. Keep each gate deck to five slides or fewer.
- Evidence: what you learned and how many customers it came from.
- Assumptions: which ones are now confirmed, rejected or still open.
- Next stage plan: scope, duration, team and budget request.
- Risks: the top three, each with an owner and a fallback.
- Decision: go, go with conditions, rework or stop, with the reason.
Who owns what
New products cross every department, so unclear ownership is one of the main reasons they slip. Agree on owners in the first month and put them on the roadmap itself, next to each stage.
Use a simple RACI for the gate decisions: the product lead is responsible, the sponsor is accountable, and function leads are consulted. Everyone else is informed through a short monthly update.
- Executive sponsor: chairs gate reviews, approves budget, removes blockers between departments.
- Product lead: owns the roadmap, the assumption list and the gate decks.
- User researcher or designer: runs interviews and concept tests.
- Engineering or R&D lead: feasibility, cost estimates, build plan and quality.
- Product marketing manager: positioning, pricing work and launch plan.
- Sales, support and operations leads: pilot customers, training and launch readiness.
Example: a filled-in roadmap for a B2B software product
Picture an accounting software company that wants to build a new expense approval tool for mid-sized finance teams. Here is how the 12 months could look, quarter by quarter.
The same layout works for a physical product. Replace the pilot with a small production run and add a stage for supplier selection and tooling before the build.
- Q1, Opportunity and discovery: brief approved, 18 interviews with finance managers, top problem confirmed as chasing approvals by email. Owner: product lead. Milestone: Gate 2 passed.
- Q2, Validation and early build: interactive prototype tested with 10 teams, four sign pilot letters, build starts in week 19. Owners: designer and engineering lead. Milestone: Gate 3 passed, first sprint demo to the sponsor.
- Q3, Build and pilot: first release with approval rules and email alerts, pilot starts with the four teams. Owners: engineering lead and customer success. Milestone: Gate 4 passed, pilot running.
- Q4, Readiness and launch: pricing set, sales trained, launch to existing customers of the accounting product first. Owners: product marketing and sales lead. Milestone: launch, then post-launch review.
Metrics to track at each stage
Early stages and late stages need different metrics. Before launch you are measuring learning and commitment. After launch you are measuring use and revenue. Agree on the launch targets at Gate 5, before the launch, so the post-launch review has a clear bar.
Report the metrics on the same slide at every gate so the sponsor can see the trend from one stage to the next.
- Discovery: number of interviews and how many describe the problem without being prompted.
- Validation: pilot commitments or letters of intent signed against the target you set.
- Build: sprint goals met and critical defects open before the pilot.
- Pilot: weekly active pilot users and pilot customers ready to pay.
- Launch: new customers, activation rate and support tickets per customer in the first eight weeks.
How to present it to leadership
Leadership wants three things from a new product roadmap: when they will see a decision, how much they are committing now, and what would make you stop. Put the six stages on one slide as a horizontal timeline with the gates marked as diamonds. Under each gate, write one line on the evidence needed to pass it.
Ask for funding one stage at a time. Requesting the full build budget at the start puts pressure on everyone to keep going even when the evidence says stop. Keep the detailed sprint plan, the interview notes and the assumption list in an appendix, ready for questions.
Common mistakes to avoid
- Starting the build before talking to customers leads to a product nobody asked for, so finish discovery and concept tests before writing the first requirement.
- Treating every gate as a formality turns the roadmap into a schedule, so write pass criteria in advance and be ready to stop.
- Promising a fixed launch date at the start sets you up to miss it, so commit to the next gate date and give a launch range that narrows over time.
- Bringing sales and support in just before launch leaves them unprepared, so involve them from the pilot stage and train them before the launch date.
- Letting the first release grow with every stakeholder request delays the pilot, so cut scope to what pilot customers need and log the rest.
- Measuring success only by launch day hides whether the product works, so hold a post-launch review against targets set before launch.
Frequently asked questions
What are the stages of new product development?
Most teams use six stages: opportunity, discovery, concept and validation, design and build, pilot and launch readiness, and launch. Each stage ends with a decision to continue, change or stop. Names vary by company, but the order is similar.
How long does new product development take?
It depends on the product, the industry and the team. A software product often takes six to twelve months from idea to launch, while physical or regulated products usually take longer. Plan stage by stage and narrow the launch date as evidence comes in.
What is a stage-gate process?
It is a way of running new product development in stages separated by decision points called gates. At each gate, a sponsor reviews the evidence and decides to go, rework or stop. It stops big spending until cheap tests have shown that the idea works.
Who should own a new product development roadmap?
A single product lead should own it, with an executive sponsor who makes the gate decisions. Function leads from engineering, marketing, sales and support own their parts of each stage. Write the owners on the roadmap next to each stage.