How to create a product roadmap: step-by-step guide and free template for founders

Written by

Laura Bosco

The featured image for this blog post.

So you have an idea.

You think it’s a good one and you’ve stockpiled 100 features that will make it the most valuable app on the market. #genius. The team builds everything: “no killer feature left behind!”

You launch with a beautiful marketing site, pithy message, and all those killer features tuned and ready for your hundreds of devotees.

Except the devotees don’t show up. The features don’t get used. And the pithy message doesn’t look so pithy anymore.

Trust me, I’m cringing too. And partly because we’ve made this mistake ourselves. But along the way we learned one very important lesson: there’s a better way. And it centers on defining your Minimum Loveable Product (MLP) and utilizing a powerful tool called a product roadmap. 👇

What we cover in this post:

What is a product roadmap anyhow?

A product roadmap organizes important product information in one place for key people. Atlassian describes it as “a shared source of truth” for project members and that’s a pretty good summary. But if you’ve never seen or created one, it’s also hard to visualize.

Since creating a product is a massive adventure, let’s define a product roadmap in terms of a smaller adventure. I live in Chattanooga, TN, and one of my bucket-list items is to drive up the West coast with my husband. That’s my adventure goal—see the West Coast.            

what is a goal


My vision is us in a jeep wrangler, 70-degree weather, the ocean on our left, and a salty, sunny breeze in our faces. If you pictured this at sunset you’re tracking with me.

Now to get from TN to my sunset drive, I need a strategy and a roadmap. For strategy, let’s say I want a cost-effective route that maximizes our opportunities for good hikes and stellar campsites.

what is strategy


Alternate strategies could be visiting as many vineyards as possible or an extravagant pre-kid vacation touring all the nicest hotels. But I dig the hikes and campsites trajectory; it fits our values.

So we have a goal, vision, and strategy. Now here’s where a roadmap is essential and a lot of fun—especially if you have organizational tendencies like me. The roadmap illustrates what concrete steps we need to take to get from Chattanooga to sunny and 70. What driving route will we take? Will we fly or drive out there?                        

what is a roadmap
 Illustrations inspired by Hackernoon’s WTF is Strategy?


The roadmap outlines these specifics so my husband and I are on the same page about what we’re doing and how we’re doing it. It helps us identify and follow a clear path to our goal.

A product roadmap does the exact same things for your startup; it outlines how to meet your goal, carry out your strategy, and actually achieve your vision.

Why a roadmap? (Winging it is a lousy option)

For a startup of any size, a good roadmap will do the following:

You could wing it instead, but that’s a pretty lousy option. Take my West Coast example. Here’s what would probably happen without a roadmap:

Meaning we never get to the West Coast at all. Or if we do, we have a PB&Js, a rental van that smells like mold, and enough tension to cloud the views—not at all the vision I imagined.

In startups, the parallel scenario looks like chasing every shiny idea or feature (unfocused), spreading budget out in confusing or frivolous directions (mismatched priorities), and working on whatever seems fun at the moment (unclear steps). All of which will lead you someplace you don’t want to be.

Roadmaps pave the way to a better outcome.

What should a product roadmap include?

Your roadmap won’t look much like my map of the US. Rather, it’ll be in a document or tool, like Airtable, Google Sheets, or Trello. And it’ll have more words than tent icons. (Though there’s no rule against emojis. 😁)

Your product roadmap should include:

It should not include:

Remember, a good product roadmap has just the right amount of detail. A 10 tab spreadsheet with loads of notes and deadlines is something no one wants to open. It’s takes too long to digest. But a roadmap with too little detail is equally useless. Why reference it at all?

We’re going to get into the gritty specifics of building out your roadmap, but first we need to cover some super important context. Otherwise, creating your roadmap is going to be more difficult than getting to California on a motorized scooter.

Krit team member on a Scooter
Austin doesn't recommend this route.


Pre-roadmap essentials: who, why, and what

Before you build out a product roadmap, you need to start with some fundamental questions. Questions like, “who is this for?” and “what value does it deliver?”

For clarity, I’ll use an example app throughout the rest of the post. I’ve always wanted a robust gardening app, so we’ll run with that idea and call it Juniper. If you don’t have your own idea yet, steal this one. 😉I’d love to keep my outdoor plants alive (there’s no hope for Andrew, app or not).

👉Already done this stuff? Great! Skip down to our step-by-step process. Otherwise, dig in here first.

Who is this for? Defining a target audience

This is the most important question. Unfortunately, a lot of founders answer it with “everyone.” That’s lazy thinking, and you’re better than lazy thinking.

Your target audience is always a specific group of people with a particular set of needs. “Everyone” is not a target audience. Not even Apple or Netflix are for everyone.

Of course, that’s easy to say and much harder to define. Especially since identifying who you are for means defining who you’re not for, and that feels like leaving opportunity on the table. But from experience, we know positioning yourself to serve a specific market can:

My target audience for Juniper is 25-40 year olds who own or rent land in the continental US, are new to gardening, and need help growing outdoor plants. (Note I’m not serving the house plant devotees, pro gardeners, or the retirement community aspiring to landscapes worthy of a Southern Living cover.)

👉Stuck here? Justin Wilcox from Customer Dev Labs has stellar advice and a great process you can work through.

Once you know (or think you know) who your target audience is, you need to get out there and talk with them. Remember, your goal is to build what customers want to pay for, not what you want them to pay for. To do that, you need a really clear picture of who your customers are and what they want.

If you’re not already talking with customers, here are a few helpful resources that will get you started:

Whatever you do, don’t skip figuring out who your target audience is and talking with them. Remember, no market need is the #1 reason most startups fail! So talk with the people you want to serve and figure out their needs.

Why does this need to exist? Creating a value proposition

Defining your audience and talking with customers will help you craft another important piece: your unique value proposition.

This is the way that you, and only you, deliver a specific value to your specific audience. If you have competitors, a value proposition helps customers understand why you’re the best choice for them. If you’re in a new market, it helps customers understand why you exist and are worth paying attention to.

In the context of a product roadmap, a value proposition helps clarify what you’re building and why it should exist.

Juniper’s unique value proposition is: Finally find your green thumb. Juniper is everything you need to keep your outdoor plants alive and thriving.

(It's a work in progress. 😬)

What type of app will it be?

Imagine calling a pest control service and hearing this response: "So tell me. Are you sure you need our services?" You'd never hear that from restaurants, hotels, or retail, either. But in app development this is a CRUCIAL question. If you’re going to succeed with an app, then your startup has to actually need one.

Keep in mind there are native apps, web apps, and hybrid apps. Native apps are the kind you download on your phone. Web apps can be desktop or mobile, and they run inside a web browser (like Chrome or Safari). Hybrid apps are both native and web-based, but they only have one codebase.

Which one you need depends on who your users are, what kind of data you want to manage, your budget, and other factors. Check out the flowchart below for extra guidance.

what type of app do you need? flowchart


Juniper’s customer’s will pull up the app several times a week in the yard, at Lowe’s, in the carpool lane, and other not-at-your-desk situations. And since I’ve raised a friends and family round (the photos of my dying plants were very compelling), I have the budget I need to pursue a native app.

👉Still iffy on on what kind of app you need? These questions will give you more guidance.

What are your parameters?

There’s only so much time and money you can spend building your app. Those are parameters and they establish boundaries around what you can and can’t do. Write them down, so you keep your product roadmap realistic. For example, if you only have 3 months to launch your product, don’t create a 6 month roadmap.

For Juniper, I have $100k in budget and 6 months before the next Spring season.

Our step-by-step process for creating a Minimum Loveable Product roadmap

Once you’ve sorted through the who, what, and why above, you’re ready to tackle our step-by-step process for defining your Minimum Loveable Product, or MLP.

A Minimum Loveable Product is a complete story; it has a clear purpose and just the right set of features. It's not minimum releasable crap or a barely functional piece of a bigger idea. Rather, it's an insanely valuable package of one or two core functionalities that let you start small, gather feedback, and build up to exactly what customers want.

Step 1: Find a whiteboard, a box of markers, and a few hours

If you don’t have or love whiteboards, you could also create a Trello board or Kanban board in Airtable. Whichever method you use, create three columns: MLP, v2, and manual.                            

defining your MVP
My board for Juniper in Airtable.


Here's what each column means:

If you have a team, make sure you get a few key folks in the room. Definitely your co-founder, if you have one.

I’m the only one leading Juniper, so it’s just me, my soy latte, and a Kanban board in Airtable.

Step 2: List every feature you can think of

Once you’re all set up, dump all those features bouncing around your brain into the MLP column.

Need a recap on features? Your product delivers benefits to customers. Features are the tangible, technical way you deliver those benefits. Google docs, for example, provides collaboration. That’s a benefit. Commenting and revision history are both features; they deliver the collaboration benefit.

So in this step, you want to list every feature you can think of. This is your opportunity to go big and crazy. Try not to ask “does this make sense?” or “is it feasible?” Those questions aren’t helpful right now. Rather, you want to get everything out of your head and into this column.

create an MVP feature list


Features most folks forget:

We also include some items that aren’t technically app features but are still essential to launching your MLP. For example, branding and a marketing site.

Step 3: Move as many features as possible to v2

Once you’ve gotten everything down—and preferably taken a lunch break—you want to come back and start moving those features around.

At this stage, one of the best questions you can ask is, “How long can we hold off on this feature?” If you can hold off, even for a week, the feature goes into the v2 list.                          

moving features to v2

With Juniper, a lot of the features I originally listed are nice-to-haves. They add some value, but they aren’t high-impact for the customer (based on what I know so far) and the MLP is functional if I remove them. So all those nice-to-haves get scooted over to v2.

4. Move as many features as possible to manual

Go through your MLP list again and look at every single feature. This time, ask yourself, “Can we do this by hand in the beginning?”

If you answer yes to anything, move that card to the list called “manual.”

Remember, it’s okay to do things that don’t scale. Consider Stripe. One of the reasons Stripe was so much better than competitors was because they made setting up a merchant account easy. And guess what? They did merchant signups manually when they first launched. If one of the most successful companies of the past decade can launch with manual processes, why can’t you?

Our client Case Status launched with manual signups and manual payments; the founder would send an invoice to each customer at the beginning of the month. Later, when Case Status wanted to automate things, they built a typical self-serve purchasing flow. Guess what? Sales went down. They’re now back to implementing customers manually (although invoices are automated).

Maybe you can use Zapier to connect some processes. Or maybe you can process some data manually, but make it look like it’s happening automatically. Doing something manual for now doesn’t mean you’ll do it this way forever.                        

moving features to manual solution


It’d be tedious, but I could manually create and categorize a robust plant database for Juniper. Sound crazy? It’s not too far off what the founders of Pandora did. They categorized 450 attributes for thousands of songs in a massive spreadsheet when they started out. I think I could handle some plants.

Note: If you have the budget, a secret second way to automate a feature is hiring someone. If I really didn’t want to categorize those plants I could pay someone on UpWork to do it for me. But personally, I’d rather my money go towards compelling features.

5. Repeat, using these guides

Once you’ve gone through steps 1-4, take a break or sleep on it. Then come back to it the board and repeat steps 3-4. If it feels difficult, you’re probably on the right track. Simple takes a lot more work than complicated.

When you get stuck, the questions below will help you move through the sorting process. If you answer "yes" to any of these, move the feature in question to the v2 list.

Remember, the beautiful thing about software is you can deploy an update in a matter of days or weeks. If you’re on the fence about a feature, move it to the v2 list. If your customers complain, build it and launch it one week in. This works in your favor. You’re showing customers you’re listening and you validated that feature.

Our client GreyNoise used this strategy to wow early adopters of his product and generate word of mouth buzz. Sometimes he would build a feature and turn it around in a matter of hours. How’s that for customer support?

Another useful tool is this framework by Gusto’s co-founder. If a feature isn’t high-impact, it shouldn’t be on the MLP list.

deciding what features to include in your roadmap


Image via Gusto’s Comparing Apples and Oranges

You want to repeat the process of moving items from MLP to v2 or manual until you feel like you can’t take anything else from the MLP list.

Then you want to do it one more time. 😁

6. Sketch out all the screens in your app

To make sure you get everything down, the last thing you want to do is draw sketches of screens you’ll need in your MLP. Don’t worry about making these pretty, and don’t spend a ton of time on each image.


sketching screens in your app
I used pen, paper, and an afternoon break to get these down.


You do want to use this as an opportunity to catch any feature you forgot. You don’t want to add a whole new list of ideas to your board.

Essential screens that are easy to forget:

👉Ready to give this a shot? Here’s the free airtable template. Look for the Copy Base button to make a copy of our Airtable setup and use it on your own account.

What to do once you’ve defined your MLP

First, if you’ve made it this far, you need to take a celebratory moment before you do anything else. 🎉 You’ve just put a lot of energy into asking hard questions most founders aren’t willing to tackle. Well done!

Now, here’s what you can do with all your information.

Get an accurate quote from developers

If you’re working with developers or an agency to build your app, you’ll need a quote.

To make this process easier, transfer your MLP list to a format where developers can easily add their estimates. We use an excel spreadsheet for this, but you could also use Airtable or Trello.

getting an MVP quote from developers


Check out our free Google Sheets template. 👀

To estimate projects, we use T-shirt sizes:

We also recommend including some buffer in your final estimate—we've already included one in the template for you. Remember, something will go wrong, and that’s normal.

What if the estimate comes back over-budget?

Have an honest conversation with your developers. Our recommendation is to always compromise on scope, not quality. You want to take a hard look at the things you don’t think you can do manually and decide how much they’re really worth. For instance, is it worth $10k to send invoices automatically...simply so you don't have to? Probably not.

You should also research whether a third-party or no-code tool could accomplish certain features or functionality. For example, many founders go overboard on an expensive marketing site when a nocode landing page, like Carrd, would work just fine.

Create a flexible product roadmap for building your MLP

After estimates, you’re ready to start building your MLP; you’re ready to execute. To manage the build, create a board system like the one we used above to define your MLP.

One simple setup that’s easy to use, reference, and manage is called “Now, Next, Later.” As the name implies, you have three columns.       

Simple product roadmap template


The Now column contains items you’re working on now. The Next column contains items you’ll work on next. And the Later column is everything you’ll do, well, later.

👉Ready to give this a shot? Here’s the free product roadmap template in Airtable. (It's the second tab.) Look for the Copy Base button to make a copy of our Airtable setup and use it on your own account.

Note: We use a setup that’s a bit different because we’re an agency with an entire team (designers, developers, founders) working on each project. If your operation is smaller, try the Now, Next, Later approach first. If you don’t like it, dig into all the Product Roadmap templates FYI gathered.

Roadmaps aren’t a “set it and forget it” kind of thing

Remember how we said roadmaps shouldn’t be a bajillion pages?

Besides the fact no one will read any document that long, you’re going to need to update your roadmap frequently and a bajillion pages is something you’ll update...never.

Plus, when you start implementing, you’re going to run into all kinds of unexpected things:

All of which means your roadmap will change. That’s a good thing. But it also means you need a tool that’s easy to work with and a roadmap that’s easy to adjust, or your roadmap will be pretty useless about a month into execution.

Our templates are in Google Sheets and Airtable because those are both easy to use and manipulate. Trello is another fantastic option. Use whatever you’re most likely to revisit.

How we can help: roadmapping sessions with Krit

If you don’t want to navigate all this yourself, we can help. We start every project with a Roadmapping Session.

A Roadmapping Session is a paid consulting session where we learn your business inside and out and craft a super detailed product roadmap.

You get:

You'll also get a chance to work with us without investing tens of thousands of dollars to make sure we're a good fit. Roadmaps cost just $3,500.

If you’re ready to get your Minimum Loveable Product out there, schedule a free call with Andrew to learn more about Roadmapping.

Laura Bosco is a writer and people person. She helps tech startups do tricky things, like explain who they are and what they're doing. Ping her on Twitter to say hi.