Everything You Need To Know About Product Roadmaps (Roadmapping Exercise Included)

Although the inspiration for a great product can come at random, seeing it to completion and delivering something people will pay for is almost always the result of careful planning and execution. 

For this reason, a product roadmap is essential.

The Biggest Impact of Having a Product Roadmap

Clarity.

It’s one of those things we only notice when it’s missing, especially in cases of non-tech founders working with developers.  

Most products involve many moving parts and thus require multiple team members and experts to work together in a certain order. A product roadmap leaves none of this to chance - everybody knows what they’re supposed to do and when to do it. 

Lack of clarity can absolutely cripple projects.

We hope we’ve convinced you, so let's take a look at the specifics of a typical product roadmap and how readers can practice coming up with one of their own.

What a Product Roadmap Looks Like 

Here’s a sample product roadmap.

• it’s concise, but…

• it’s detailed enough to cover the next 4-6 months

• no hard dates, only ranges

A roadmap is meant to be detailed without being long-winded.  Software development is also never 100% predictable, so some wiggle room must be provided.

Finally, while it's possible to plan beyond six months, developments and discoveries along the way tend to make planning that far ahead result in wasted effort. It’s often best to plan for smaller intervals and review continuously.

How Long Does it Take & How Much Does it Cost?

The cost of coming up with a product roadmap varies from developer to developer. Some offer it as a free service, provided the founder hires them for the actual development. Others charge for it separately, citing the significant time investment from their team. 

That last part isn’t just empty talk; the initial product roadmap should ideally be given a full day’s worth of discussion and planning between the founder and the development team. This is a huge time investment for developers. Without making, it sounds too money-driven, they are foregoing revenue for the day in hopes of securing additional income from a new project.

That said, be ready to pay a few thousand dollars and dedicate at least a whole day to this. Some developers will also ask you to submit a simple app brief template beforehand, so they can do some preliminary research. 

One thing is certain: the monetary and time cost of creating a roadmap pales in comparison to the cost of not having one. 

Practice Time: Product Roadmapping Workshop Exercise

This is meant to simulate the experience of a Product Roadmapping Workshop. 

The specific steps and terminology will vary between developers, but the general flow and goal is the same: to put together a roadmap filled with goals and action items for the next few months.  

Of course, nothing can replace the real deal, but just as flight simulators train pilots to take charge of their aircraft, this exercise can prepare you to have a more productive session with your developers when the time comes.

This is what a typical Product Roadmapping Workshop looks like at Upstack Studio:

1. Product Overview & Team Introduction (5 minutes)

2. Target Audience (45 minutes)

3. Problem Statements (15 minutes)

4. Value Proposition (30 minutes)

5. Type of App (5 minutes)

6. QUICK BREAK (PHEW)

7. Brain Dump 1 (60 minutes)

8. Lunch Break 

9. Brain Dump 2 (60 minutes)

10. Prioritization (60 minutes)

11. Collapse in exhaustion (the rest of the day)

To fully benefit from this exercise, you’ll need:

• A pen or pencil

• A notebook or several pieces of paper

• A quiet place (no Meshuggah playing in the background)

Let’s begin!

Product Overview & Team Introduction

While some developers prefer meeting physically, others find virtual calls just as productive. If you’re hiring overseas, expect to have the workshop conducted over a Google Meet or Zoom call. 

While the Team Introduction is mostly an icebreaker, the Product Overview is where the founder properly shares their idea with the developers for the first time. 

Developers will want to understand:

• the founder’s vision for the final product

• who it serves 

• how it helps them

• how the founder got the idea, and

• any ideas for catchy names?

As it’s only the beginning, don’t feel pressured to provide details. After all, the following sections are meant to address precisely that.

If the meeting is held virtually, the developer must use a tool for visual brainstorming. There are many great options, and workshops at Upstack Studio specifically are run with FigJam.

Target Audience

We will now have a no-holes-barred discussion about who you want to help. 

Who is the persona you’re trying to reach here?

• What are their circumstances? 

• What are their personality traits? 

• What would compel them to use a particular solution?

Now give them a name - that way it’s easier to remember and refer to them later on in the workshop (and the development process as a whole). If you’re targeting audiences from different countries, it might be useful to give them country-specific names too.

By understanding the circumstances and motivations of your various target users, we can determine whether the product you have in mind has business potential. 

Here’s an example of a sufficiently completed user persona for someone called Chad.

Onto the next step!

Problem Statement

Here, we describe problems faced by our persona(s) that we want to solve. 

List down as many problems as you can think of, then vote on the top three most painful.

Value Proposition

Here, we answer what value we provide to solve those pain points. It could be a standalone service or a bundle, preferably highlighting gaps in the market.

Again, try to list down as many as possible (explains all the boxes, eh).

Once done, we group the propositions into distinct categories and vote on the three most compelling options.

Type of App

Based on everything we know so far about the persona(s) and problem we want to solve, would it be best to go with a mobile app or mobile site?

In general, most solutions can be delivered through a mobile-responsive web app.

These are far cheaper to build and maintain compared to native mobile apps.

This topic deserves its own piece and is really something you should let your developer advise you on based on your specific use case.

The Brain Dump

Think up as many features as possible.  

Don’t stop to worry about things like practicality or cost-effectiveness. If you think your app will need it, list it down.

Of course, this can and probably will lead to a very long list of features, which we mercilessly cull in the following section.

Prioritize

Here’s where the product roadmap starts to take shape.

Filter every feature with these five questions:

1. Can we hold this feature off for a week or more?

2. If we remove this, does the product still solve the main customer problem?

3. If we remove this, does the product still function?

4. Did I add this because it’s sexy and shiny?

5. Is the founder on the fence about this feature?

The goal here is to determine the least amount of features your app needs to qualify as a minimum lovable product (same as MVP, but evoking a positive emotional response from users).

We also sort through these features to see what can initially be done manually to save costs.

For example, users may want to make purchases on your platform from day one. 

Instead of a payment gateway, we might recommend leaving bank account details, a phone number, and instructions to send screenshots of transfers.

Past a certain point in time or revenue target, we roll out the payment gateway integration and the founder can stop having to answer random messages at midnight!

Wrapping Up

Armed with this clarity, the developers will take some time to draft a roadmap for the founder to review. Once approval is given and the initial payment is made, all that’s left is to execute and review at regular intervals.

Of course, no product roadmap is set in stone. Software development comes with a host of unpredictable factors. For example, breaking changes in the technology stack or the discovery of better alternatives may require reworking and rewriting to update the app for the best results.

However, with a product roadmap to firmly align the team to a founder’s vision, minor changes like these no longer risk derailing the project - quite the opposite, they ensure the quickest and most efficient way forward.