How to Create a Product Roadmap Without Any Fancy Tools (With Examples)

Roadmaps. The word alone is enough to give a first-time product manager a few sleepless nights. The moment someone senior asks you to create a product roadmap, it suddenly feels like you’ve been handed a giant, important, slightly terrifying blank canvas — with no idea where to start. If that’s you, take a breath: learning how to create a product roadmap is far simpler than it looks.

So let’s take the fear out of it. In this piece I’ll walk you through how to actually create a product roadmap — and I’ll do it without any fancy roadmapping tools. No Aha, no Productboard, no expensive subscription. Just your thinking and a plain spreadsheet.

What a product roadmap actually is (and why it’s not scary)

Here’s the reframe that makes the whole thing click. A roadmap is simply a list of the things you’ve planned to work on over a defined period of time. That’s it. If I’m being honest — and slightly cheeky — a roadmap is just a fancy name for a to-do list. A to-do list with a deadline and a bit of strategy behind it.

It also helps to know when this lands on your plate. As a junior PM, you probably won’t be asked to build a roadmap at all — at that stage your world is execution, sprints, and shipping. But as you grow, the strategic responsibilities grow with you, and owning the roadmap is one of the biggest of them. So if this feels intimidating, that’s usually a sign you’re levelling up, not that you’re out of your depth.

The catch is that your backlog is a never-ending list of tasks, ideas and requests. The product roadmap is the curated, time-bound version of that list. Turning one into the other is where the real work happens — and it has nothing to do with which tool you use.

The hard part isn’t the tool — it’s prioritisation

To pull a roadmap out of a messy backlog, you weigh each item against a handful of factors. These are the questions I run every candidate item through.

Is the problem even worth solving?

Before anything else: does this problem align with your business strategy, and does it genuinely add value for your users? Say someone at Amazon pitches, “let’s start selling cars on Amazon.” The PM has to judge whether that’s a problem worth solving. Intuitively you might think — probably not. But good practice is to back the call with a bit of logic: do people actually want to buy cars online? Are those buyers part of Amazon’s existing base, or a brand-new segment? The answer may still be “no,” but now it’s a reasoned no, supported by a quick survey, a few interviews, or some data.

Now, you can’t run a full analysis on every oddball request — that would eat your entire week, and you’d be right to push back. But in my experience, the requests that reach you are rarely so bizarre that you can dismiss them on gut alone. Take the cars example: someone can fairly counter with “why not?” — eBay and Taobao already sell cars, and eBay has even sold aeroplanes; one of the priciest things ever sold on it was a private jet worth around $5M. Rejecting ideas purely on intuition quietly risks missing the next big thing. History is littered with it — HP passing on the Apple 1, Intel sitting out the early AI wave. Validate, don’t just react.

How big is the prize? (TAM)

Total Addressable Market is the size of the opportunity — either in users or in rupees/dollars. If you owned 100% of the market, how many people could this product reach, or how much revenue could it unlock? As a rule, the bigger the TAM, the higher the priority.

What will it actually move? (Impact estimation)

This is the expected effect on the specific business metric you’re trying to shift — “increase revenue by 10%,” or “lift D1 retention by 5%.” Tie every item to a number you care about; it forces honesty about whether something is worth the slot.

Important vs urgent

These two get muddled constantly, and they’re not the same thing. Launching a new business vertical or entering a new geography is important but usually not urgent — if being thorough means taking an extra few weeks of research, take them. On the other hand, if your company changes its registered business address, you urgently need to update it across your website and app for compliance — but it won’t touch your DAU or sales at all. That’s urgent but not important. A good roadmap makes room for both without letting the urgent crowd out the important.

Complexity

Sometimes a simple, quick-to-build feature earns a spot even if its impact is modest, purely because it’s cheap to ship. Effort is a real input, not an afterthought — a small win you can land this month can be worth more than a giant bet that slips for two quarters.

No duration, no product roadmap

Here’s the factor people skip, and it’s the one that makes a roadmap real: the time period you’re planning for. Without a defined duration, a roadmap is just daydreaming. It’s like saying Tesla has “flying cars” on its roadmap — there’s a decent chance we get there eventually, but the duration is what turns a wish into a plan. One year? Ten? A hundred?

People build everything from one-month to five-year roadmaps, but given how fast the tech landscape moves, anything beyond a certain horizon stops being useful. Honestly, a five-year roadmap is close to useless for most of us today. A few industries — manufacturing, healthcare — can justify it because of the heavy upfront R&D in both time and money. For the rest of us, I prefer a one-year product roadmap for long-term strategic goals and a three-month roadmap for short-term execution. That pairing has served me well across very different teams.

Long-term vs short-term roadmap (a worked example)

The long-term (one-year) product roadmap is about themes, not fine detail. It holds the strategic, business-goal-driven projects, and it’s expected to evolve through the year as things change. What it gives you is a clear sense of what you’re focused on. If this year’s business goal is profitability, your themes might be lifting ARPU (average revenue per user), cutting customer acquisition cost, or reducing returns and refunds. If the goal is growth, you’d lean into increasing DAU/MAU, a referral programme, or building a coupon and discount flow.

The short-term (three-month) roadmap is where the detail lives — TAM, effort estimation, impact estimation, all of it. Let’s take the ARPU theme from above and go one level down. You can raise ARPU by getting users to order more often, or by increasing the average order value. And you can lift average order value in more than one way — nudging users towards a higher-priced item by highlighting its quality and service USPs, or recommending associated products (“if you bought X, you might want Y”).

All three are legitimate paths to the same goal. Deciding which one earns the next quarter is exactly where you pull out TAM, effort and impact estimation. That’s the whole point — the long-term roadmap tells you the direction, the short-term roadmap tells you which specific bet you’re making first, and the prioritisation factors settle the argument.

Breaking it down into sprints

The projects in your three-month roadmap then get broken into sprints. And your ideal sprint length isn’t something you copy from a blog — it’s something you work out for your own situation. A few things shape it:

• Your team size.
• Your user base — a few thousand users or millions? B2B or B2C?
• Your release cycle — one major release a month, or shipping every week?
• The complexity of what you’re building.
• And occasionally, the sheer urgency of a specific product.

In software, there is no single right answer here. I’ve worked in organisations that shipped a release every week, and others that preferred far less frequent ones. Based on my own experience, I like one major release a month, plus smaller bug-fix releases as and when the severity demands it. Find the combination that fits your team — and don’t let anyone tell you there’s a universal “correct” cadence.

Putting it together — no fancy tools required

Zoom out and a clean, sensible structure falls out of all this: a one-year strategic roadmap, split into four three-month roadmaps, each of which breaks into roughly three one-month sprints. Strategy at the top, execution at the bottom, and a clear line connecting them.

Once you have a rich backlog and you run it through the criteria above — is the problem worth solving, how big is the TAM, what’s the impact, is it important or merely urgent, how complex is it, and over what duration — laying those tasks into a roadmap is a genuinely straightforward exercise. And you’ll have noticed you didn’t need a single fancy roadmapping tool to do any of it. Our good old Excel (or Google Sheets) gets the job done perfectly well. The tool was never the hard part. The thinking is.

Frequently Asked Questions

That’s really all a product roadmap is: a well-prioritised, time-bound to-do list. Get the thinking right and the tool becomes an afterthought.

If building the roadmap is the point where your PM role starts feeling genuinely strategic, and you’d like a sounding board as you step up, that’s exactly what I do. I’ve mentored 50+ people into and up through PM roles at Google, Microsoft and Amazon. Book a free 1:1 mentorship session and let’s work through your roadmap — and your career — together.

Want to go deeper on the craft? Have a look at the top 10 product management skills, and once your roadmap picks a project, turn it into a solid product requirements document (PRD).