How to build a product roadmap based on real data

Most product roadmaps are fiction.

Not because the team is dishonest — because they're built on the wrong inputs. They're built on what stakeholders want, what competitors have, what sounded good in the last all-hands, and what the founding team believes users need.

These are opinions. Valuable ones, sometimes. But opinions nonetheless.

A roadmap built on opinions is a political document: whoever argues most effectively controls the direction.

A roadmap built on data is a decision tool: the direction is determined by evidence, and disagreements get resolved by finding more evidence.

Here's how to build the second kind.

The four data sources that feed a real roadmap

Source 1: Retention and activation data

Your product analytics tell you where users succeed and where they fail.

The most important number: what percentage of users who complete the core action in week 1 are still active in month 3?

If that number is high (above 40% for a B2B SaaS): your core value is real. Focus the roadmap on acquisition and expansion — making more users reach the core action.

If that number is low (below 20%): the core experience is failing users after the first touch. Focus the roadmap on depth — making the product more valuable for the users who stay.

This single data point changes what your roadmap should look like.

Source 2: Feature usage data

Every feature in your product has a usage rate. Most teams don't track this.

Set up event tracking for every significant action in your product. Monthly, run a report: what percentage of monthly active users triggered each feature?

You'll find:

• Features used by 60%+ of users: core features — protect, improve, invest
• Features used by 15-40% of users: secondary features — monitor, don't cut
• Features used by under 5% of users: candidates for removal or redesign

Don't build on top of features in the third tier. Fix or remove them first.

Source 3: Support ticket analysis

Pull every support ticket from the last 90 days. Tag each one by topic (onboarding, feature X, billing, performance, etc.)

The topic with the most tickets is your highest-friction area. Fix that before adding new features. Every new user who hits the same friction is a support ticket in your queue — and a potential churn.

Source 4: Churn interview themes

Every month, talk to 3 users who cancelled. Ask one question: "What would have needed to be different for you to stay?"

After 3 months, you have 9 conversations. After 6 months, 18. By this point you'll hear the same themes repeatedly. Those themes go on the roadmap as explicit problems to solve — because solving them directly reduces churn. For a full system on collecting and making sense of this kind of signal, see how to use customer feedback to make product decisions.

How to structure the roadmap

A data-driven roadmap has three layers:

Layer 1: Now (this sprint/month) Features directly backed by high-frequency data signals. Either: fix a high-volume support issue, improve a low-activation step, or complete a feature that churned users said was the reason they left.

Layer 2: Next (next 1-3 months) Hypotheses validated by qualitative research. You have interview data, prototype tests, or fake door results that suggest these features have high demand. They're not yet proven by usage data because they don't exist yet.

Layer 3: Later (3+ months) Strategic bets and longer-term direction. Less data, more judgment. These are directional, not committed. They change as Layer 1 and 2 produce new signals.

This structure keeps the roadmap honest: the closer to "now," the higher the evidence bar. Far-future items are allowed to be based on reasoning. Near-term items need data.

The roadmap review process

Once a month, run a 60-minute roadmap review:

1. Pull the four data sources (retention, feature usage, support, churn).
2. Check: are the items in "Now" still the highest-priority items based on data?
3. Check: have any items in "Next" been validated or invalidated since last month?
4. Prune: remove anything that has been waiting for 3 months without gaining evidence — applying the same logic as how to know when to kill a feature to roadmap items before they even get built.
5. Replenish: add any new items that emerged from the month's data.

The output isn't a perfect document. It's a shared understanding of what the team is trying to accomplish and why, grounded in current evidence.

The conversation you need to stop having

"We should build X because the CEO mentioned it in the last meeting." "Y is on the roadmap because a big customer asked for it at their QBR." "Z has been on the backlog for 6 months, maybe it's time."

These are opinions. Respond to each with the same question: "What data do we have that this is the highest-impact use of the team's time right now?"

If there's no data: the item goes to "Later" until it has data. This doesn't mean the CEO, the customer, or the backlog are wrong. It means they need to produce evidence before getting roadmap space.

Over time, this conversation changes the team's culture. People learn to come to roadmap discussions with evidence — because opinions alone don't move items forward.

The tools that make this manageable

Linear — the roadmap view makes it easy to organize work into now/next/later without building a complex system. The connection to actual issues means roadmap items are always linked to real work.

Mixpanel — the analytics platform you'll need for retention cohorts, feature usage events, and funnel analysis. Set it up once, and your monthly roadmap reviews become a 20-minute data pull instead of a multi-day research sprint.

What a data-driven roadmap feels like

It feels less exciting.

You're not building the visionary feature everyone's been excited about. You're fixing the 3rd step of onboarding where 40% of users drop off. You're improving the search feature that 70% of users rely on but half of them find slow.

It's unglamorous work. And it compounds.

The teams that consistently ship the right things are the ones who've learned to be more interested in the data than in the vision. The vision is the direction. The data is the path. And if the data starts pointing toward a fundamental change, how to decide between pivoting and persisting gives you the framework for making that bigger call.

Build a product direction backed by real signals →