Product Growth Roadmap: 6-Month Template With Metrics and Example
9 min read ยท 2026-10-25
A product growth roadmap is a plan that shows which parts of the user journey you will improve, in what order and with which bets, to move one growth metric. Instead of listing features, it lists themes like activation, retention or expansion, each with a target metric, a set of experiments and a date to review the results.
The template below covers six months in six phases: choose the metric, map the growth model, build the experiment backlog, then run cycles on activation, retention and expansion before scaling what worked. It also covers what most growth guides skip: who owns each lever, how to keep growth work from fighting the core roadmap for engineers, and how to show leadership progress when many of your experiments fail.
The roadmap at a glance
Goal: By month six, the team has a shared north star metric, a working growth model, a scored experiment backlog and at least two shipped changes that moved activation or retention against a clear baseline. Duration: 6 months (26 weeks)
Pick the north star and baseline (Weeks 1-2)
Agree on the one metric growth work must move and measure where it stands today.
- Propose a north star metric that reflects value delivered, such as weekly active teams or invoices sent per week, not raw signups.
- Break it into three to five input metrics the team can act on, such as activation rate, week-4 retention and seats per account.
- Check that each metric is tracked correctly in your analytics tool, and fix missing events before you set targets.
- Get the north star and inputs signed off by the head of product and the CEO or general manager.
Milestone: A one-page metric tree with the north star, its input metrics, their current values and a named owner for each.
Map the growth model (Weeks 3-4)
See where users drop off and which loop drives most new usage.
- Draw the funnel from first visit to repeat use and add conversion between each step.
- Identify your main growth loop, such as invites from active users, content that brings search traffic or sales-assisted expansion.
- Run cohort analysis to see when retention flattens and which early actions predict users who stay.
- Interview recent signups who activated and some who did not, using the same short script.
Milestone: A growth model diagram with the biggest drop-off step and the strongest predictor of retention named, reviewed with product and engineering leads.
Build and score the experiment backlog (Weeks 5-6)
Turn the model into a ranked list of bets with a hypothesis for each.
- Collect ideas from product, design, engineering, marketing, sales and support in one shared board.
- Write each idea as a hypothesis: if we change X for users in Y, input metric Z will rise, because of evidence W.
- Score each idea with ICE (impact, confidence, ease) or a similar method, and agree on the scale beforehand.
- Group the top ideas into themes that map to the roadmap phases: activation, retention, expansion.
Milestone: A scored backlog of at least 20 hypotheses, with the top 8 to 10 assigned to a theme and an owner.
Activation cycle (Weeks 7-12)
Get more new users to the moment where they first see value.
- Define the activation event in one sentence, using the predictor found in the cohort analysis.
- Run two or three experiments on onboarding, such as a shorter setup flow, a checklist or a pre-filled sample project.
- Decide sample size and run length before each test starts, and do not stop a test early because it looks good.
- Hold a weekly growth review to read results and decide to ship, iterate or kill each test.
Milestone: At least one activation change shipped to all users after a test, with its effect on activation rate documented.
Retention and engagement cycle (Weeks 13-19)
Keep activated users coming back and build the habit that drives the north star.
- Pick the retention window that matches how often users need the product (weekly for a team tool, monthly for billing).
- Test lifecycle messages tied to user behavior, such as a reminder when a project stalls.
- Improve or surface the feature that retained users rely on most, based on the cohort analysis.
- Talk to churned accounts and tag reasons so the next backlog round has real evidence.
Milestone: Retention curve for new cohorts measured against the baseline, with at least one shipped change and a documented result.
Expansion and scale (Weeks 20-26)
Grow usage inside existing accounts and make the winning changes permanent.
- Test invite flows, shared workspaces or usage prompts that bring more people from the same account.
- Turn winning experiments into maintained features and remove the losing variants from the code.
- Write a growth playbook: the metric tree, how tests are run, the review rhythm and what was learned.
- Rescore the backlog with what you learned and draft the next six months.
Milestone: Six-month growth review presented to leadership, with each input metric against its baseline and the next roadmap approved.
Product growth roadmap vs product roadmap
A product roadmap shows what the team will build and why: new features, platform work and fixes, usually by quarter. A growth roadmap shows which metric you will move and which bets you will test to move it. It is organized around stages of the user journey, and items can be removed when the data says they do not work.
Many teams keep both on one view with two lanes: core product and growth. That makes trade-offs visible. If the growth lane needs two engineers in Q3 for an onboarding redesign, the core lane shows what moves out. Without that shared view, growth work turns into side projects that never get engineering time.
Example: a filled-in roadmap for a B2B SaaS tool
Picture a project management tool for small agencies. Signups are steady, but many new workspaces never invite a second person, and single-user workspaces rarely stay. The team picks weekly active workspaces with two or more members as the north star.
Each month in the example has an owner, a theme and a result you can check. Experiments that fail are still reported, because they tell the team where not to spend the next cycle.
- Month 1, metric and model (owner: growth PM with the data analyst): metric tree signed off, funnel and cohort analysis done. Finding: workspaces that invite a teammate in the first three days retain far better. Milestone: growth model reviewed with leadership.
- Month 2, backlog (owner: growth PM): 24 hypotheses scored with ICE, top 9 assigned. Milestone: backlog reviewed in the first weekly growth meeting.
- Months 2-3, activation (owners: growth PM, product designer, two engineers): test an invite step inside onboarding and a template project. Milestone: invite step shipped after the test showed a higher invite rate.
- Months 4-5, retention (owners: lifecycle marketer and growth PM): behavior-based emails when a project stalls, weekly digest for managers. Milestone: digest kept, stall emails dropped after no measurable effect.
- Month 6, expansion (owners: growth PM and sales lead): prompt to add clients as guests, playbook written. Milestone: six-month review with next roadmap approved.
Who owns what
Growth work crosses team lines, which is why it often has no owner. Name one person per input metric, even if many teams contribute to it. The owner does not do all the work, but they decide what gets tested next and report the number.
Keep the weekly growth review short and fixed: 30 to 45 minutes, same attendees, same order. Results of finished tests first, then tests in flight, then the next tests to launch.
- Head of product or VP growth: owns the north star, approves the roadmap and protects engineering capacity for growth work.
- Growth product manager: owns the backlog, the experiment calendar and the weekly review.
- Data analyst: owns metric definitions, test design and result reads, and flags tests that are too small to trust.
- Engineers and designer on the growth team: build experiments and turn winners into maintained features.
- Lifecycle or product marketing: owns messages, in-app prompts and launch notes for shipped changes.
- Sales or customer success: owns expansion plays in larger accounts and feeds churn reasons into the backlog.
How to run experiments without fooling yourself
A growth roadmap is only as good as the tests behind it. Before a test starts, write the hypothesis, the main metric, the guardrail metrics that must not get worse (such as support tickets or unsubscribes), the sample size and the run length. Your analyst should sign off on that plan. Tools such as Optimizely, Statsig, Amplitude Experiment or a feature flag service can split traffic and report results.
If you have little traffic, A/B tests on small changes may take months to reach a clear answer. In that case, test bigger changes, use qualitative evidence such as user interviews and session recordings, or run before and after comparisons on clearly defined cohorts and say plainly that the evidence is weaker. Do not dress up a weak result as a win in front of leadership.
How to present growth work to leadership
Leaders want to know three things: is the north star moving, which input metric is the current focus and why, and what you need from them. Put those on one slide. Show the metric tree with current values and the change since the last review, the theme for the next cycle, and a short list of shipped wins and killed tests.
Report your win rate honestly. A healthy growth program kills many ideas, and leaders who expect every test to work will lose patience. Frame failed tests as money and time saved, and show how each one changed the next bet. Leave out test-level statistics unless someone asks, but have them ready.
How to adapt it to your stage
An early-stage startup with a few hundred users should spend less time on A/B tests and more on customer conversations, manual onboarding and fixing the one step where most people get stuck. Keep the metric tree, but shorten each cycle to two or three weeks and expect bigger, rougher changes.
A larger company with steady traffic can run several tests in parallel and split the roadmap into lanes per journey stage, each with its own small team. In that setup, add a shared test calendar so two teams do not run conflicting tests on the same users, and review the metric tree every quarter as the product changes.
Common mistakes to avoid
- Choosing signups as the north star rewards traffic that never sticks, so pick a metric that reflects value delivered, such as active teams or completed jobs.
- Filling the roadmap with feature ideas instead of hypotheses makes results hard to judge, so write every item as a change, an expected effect on one metric and the evidence behind it.
- Stopping tests as soon as they look good produces false wins, so set sample size and run length before launch and stick to them.
- Leaving winning experiments as hacked variants creates code debt, so plan time in each cycle to rebuild winners as maintained features.
- Running growth work with no protected engineering time turns it into side projects, so agree on a fixed share of capacity with the head of engineering each quarter.
- Reporting only wins erodes trust when the north star stalls, so show killed tests and what you learned from each in every review.
Frequently asked questions
What is a product growth roadmap?
It is a plan that ties growth work to one north star metric and the input metrics that drive it. It groups bets by stage of the user journey, such as activation, retention and expansion. Each item is a hypothesis with an owner and a date to review results.
How is a growth roadmap different from a marketing plan?
A marketing plan focuses on bringing people to the product through campaigns and channels. A product growth roadmap focuses on changes inside the product and its lifecycle messages that help people activate, return and expand. The two should share the same metric tree.
Which metrics should a product growth roadmap track?
Start with one north star metric, then three to five inputs such as activation rate, retention by cohort, accounts that expand and referral or invite rate. Add guardrail metrics like support tickets or unsubscribes so a win in one place does not cause harm elsewhere.
How long should a growth roadmap cover?
Most teams plan three to six months, with detailed experiments for the next few weeks and themes after that. Review the backlog weekly and the whole roadmap every month or quarter. Results change the order of bets quickly, so a long, fixed plan rarely holds.
How do you prioritize growth experiments?
Score each hypothesis on expected impact, your confidence in the evidence and the effort to run it, using a method such as ICE. Agree on what each score means before scoring. Then check the top items against the growth model so you work on the biggest drop-off first.