How to create a product roadmap as a PM (with examples)

A great product roadmap is less of a strategy tool and more of a means of communication; and yet, good communication signals good strategy.

You want to build something people want. And if you're listening, your users are telling you exactly want they want. As a PM, roadmapping has been a way to journal out my thoughts on what the next stint of development should focus on. I look at the stats, consider user requests and opinions and check out what competitors are doing to rough-draft what makes sense to build now, next and never. I then fold out the paper and store it out of sight then go work it out with my team.

Roadmapping is not a solo activity. It's as cross-functional as it gets; encompassing getting data from the sales team, user complaints from customer success, metrics from our analytics tool and pulling up reviews from socials and PlayStore.

This is what the product discovery process is about.

A great product roadmap is based on:

• Qualitative and quantitative data on user needs and feedback

• Analysis of usage data to inform areas of high and low customer focus

• Data around points of friction and affected customers to help prioritise roadmap plans.

• Research into market opportunities and competitor content

You'll also need to balance larger complex dev projects with smaller iterative user needs. Focus too much on the big, exciting stuff and you grow your tech debt and unhappy customer list. Focus too much on the little improvements, you may lose your customers to companies that are more nimble and that ship new stuff on a frequent basis.

This process is perfected when you anchor your decisions in the right kind of data.

Here’s a sample of how to map out what you need in order to prioritize feature requests:

A sample scenario borrowed from Product School

Take a pen and paper and visualise how you would prioritise the above requests and ask yourself why.

Expand to see how I would approach it:

Normally, I would use the usual RICE/MoSCoW frameworks, but for simplicity, I’ll use three primary product prioritization levers here:

1. Business impact (retention, revenue, growth)

2. User impact (pain it solves, % of users affected)

3. Effort vs. ROI (how much effort for how much value)

   
   

#1: Templates to ‘schedule a meeting’

Requested by: Dev team

Why:

• Highest usage area: Scheduling is the most common feature.

• Painful friction: Users are duplicating meetings 8/10 times = strong evidence of a productivity issue.

• Strong user demand: 67% want this. This is very high.

• Likely low/medium lift: Adding templates is usually UI/backend logic, not infrastructure-heavy.

Outcome: High reach, clear user need, high ROI ----> Quick win with major value.

#2: Enhance ‘record a meeting’ UI

Requested by: Post-sales team

Why:

• Strategic value: Though <20% use it, those who do renew 95% of the time (vs 70% average).

• Drives retention, which is critical for long-term health.

• Value realization = improved onboarding & stickiness.

Tradeoff: Used by fewer users, but impact on revenue via retention is disproportionately high.

Priority #3: Meeting reminders via email

Requested by: Competitive research

Why:

• 20% of meetings are missed= clear impact on user productivity.

• Likely a low-effort implementation (simple notification system).

• Boosts product reliability and user trust.

  
  

Good example of a housekeeping feature; not super exciting, but necessary to reduce churn.

Priority #4: Dashboard view of meetings & call stats

Requested by: Research

Why:

• 45% want it = moderate interest.

• Parity feature: Competitors have it (table stakes for analytics).

• Could help with adoption and usage insights, but not core to current product pain points.

  
  

Hold until more pressing UX issues are solved.

Priority #5: Blurred backgrounds in video calls

Requested by: Leadership

Why:

• Only 2% of users requested this = very low demand.

• Cosmetic, not core to user outcomes or business metrics.

• Possible tech lift (if you don’t already use video masking libraries).

Nice to have, not a strategic differentiator.

Priority #6: Expand webinars to 300 participants

Requested by: Leadership

Why:

• Data shows only 1% of meetings have 100+ participants.

• Average is just 15 participants.

• High lift (infra/scaling), low impact.

Clear example of over-building for edge cases ----> not worth it.

Reality Check!!! Balancing Data with Stakeholder Influence

In a perfect world, you have perfect data and a perfect and supportive leadership who trust your decision-making perfectly. But we don't live in utopia and product decisions are frequently NOT data-driven.

In many real-life orgs, requests from Leadership can’t be dismissed outright; even if they’re low ROI. As a product manager, your job isn’t just to prioritize features by logic- it’s to influence without alienating. That often means: Including “executive asks” in roadmaps as lower-priority backlog items (or testing them with limited releases).

Frame your trade-offs clearly, e.g, “We can build webinar support for 300 participants, but that will push back the scheduling template; which impacts 67% of users.” Offer an alternative strategy (to buy time or get more data or whatever), e.g., “Instead of expanding webinar capacity to 300 now, we could put an additional price tag on more seats, and create a waitlist for the upgrade so we get commitments before we build."

In this exercise, I placed data-backed, high-impact features first; but in practice, I’d ensure leadership requests are surfaced, even if still deprioritized. This builds trust and ensures they feel heard, while still protecting the roadmap from going off the rails with 'requests from above'.

Revised Prioritization Table (With Leadership Pressure Considered)

Rank	Feature	Impact Rationale	Leadership Pressure	Tactical Approach
1️⃣	Templates for scheduling	Most-used feature, high duplication rate, 67% user demand	Low	Fast-track and deliver to show momentum; clear win with strong user backing.
2️⃣	Enhance 'record meeting' UI	Drives retention (95% renewal vs 70%), strategic for long-term growth	Medium	Emphasize business impact to get full buy-in; frame as critical for post-sales success.
3️⃣	Meeting reminders	20% of meetings missed, lightweight implementation	Low	Ship quickly as a housekeeping feature; low effort, high trust.
4️⃣	Dashboard view of meetings	45% user interest, competitor parity	Low	Send it to backlog with a note on parity needs; validate further with usability interviews.
5️⃣	Blurred backgrounds	Cosmetic, only 2% user demand	High	Offer a phased approach: test with a small group or as part of a wider UX revamp. Show data after pilot to reevaluate.
6️⃣	Expand webinars to 300 participants	Only 1% of meetings >100 people; high infra cost	High	Politely push back with data; suggest alternatives like 3rd-party integrations. Propose a revisit only if large-scale use cases emerge.

Examples of Public Roadmaps:

1. Nala Money

Nala is a money transfer service on a mission to increase economic opportunity for Africans worldwide. In specific, they facilitate Africans in diaspora to send money back into the continent at affordable rates. Their roadmap and feature request tool is hosted on Notion.

Nala lets their users know what's cooking and what's coming up next

2 -GitHub

GitHub has a very detailed roadmap with items that look more like Jira development tickets. What they're working on has been mapped out to several months in advance, with appropriate tags. This way, they're able to communicate to their users what to expect when which has a way of building brand trustworthiness and loyalty.

GitHub lets their community know what to anticipate for the next couple of quarters

3 - Buffer

Buffer hosts their product roadmap on Trello and they're not shy about why they make it public. Apart from wanting users to comment and upvote on features they're eager to use, they claim that they're building it for their competitors as well since they believe that: "There’s plenty of opportunity for everyone to be successful! All in all, we think this could raise the bar for all of us, and challenge Buffer to build the best, most valuable features possible."

Buffer creates their roadmap for their users and competitors to know what they're working on.

As you can see, there are several roadmapping tools that can come in handy when creating a roadmap that works for you. Tools like Notion, Trello, Roadmunk, Click-Up and Jira all work well with varying levels of colour and complexity.

A Product Roadmap is as personal as a journal but can be as public as a newspaper;

There is no universal template on what a perfect roadmap looks like for you and your org. As long as you marry the needs of the user, with that of the business, bearing in mind the dev effort and competitive landscape, you can create a map that works for you, and change it up as frequently as is appropriate.

Should you decide that you want your users to directly influence it, publishing it has it's advantages.

At its core, a roadmap is more than a plan; it's a conversation. A conversation between product and users. Between your vision and the org's reality. Between what’s urgent and what’s important. And often, between what your gut tells you… and what leadership insists.

Being adaptable, collaborative and data-driven will surely get you the roadmap you deserve.

---

Want more PM brain goodies? Check out my other posts here or explore my recent entanglements with emerging AI.

If you’re a fellow PM or founder, you’re in the right place.