Product Roadmaps: Slashing Costs, Smashing Deadlines

Building custom software without a Product Roadmap is like trying to build a house without a blueprint. You'll end up with something in the end but it won't be what you wanted.

Unlike a house blueprint, a Product Roadmap needs to take into consideration more than instructions on how to build the end product. Its role is to make it clear to everyone involved why the project is happening and what needs to be built.

One of the most challenging parts of building a new application is figuring out what to build. Every feature can be designed and developed an infinite number of ways. There needs to be a way to effectively communicate the product owner's strategic vision so the finished product ticks all the boxes.

At Clean Commit, we always work with new clients to build a Product Roadmap before any website or application project. They make the project move quicker, reduce costs and result in better applications.

We've spent a lot of time building Roadmaps and worked out our own step-by-step process (illustrated above) for creating a watertight roadmap. This comprehensive guide will unpack everything you need to know about Product Roadmaps.

What is a Product Roadmap

A Product Roadmap is a clear plan to get you from idea to v1.0 of your new product. It's a clear set of expectations about what the initial version of your product should contain and what comes next.

The Clean Commit version of a Product Roadmap also defines what the minimum features required for the first release of your new product. This is important because it's easy to try and build too much straight off the bat, wasting thousands of dollars and weeks (or months) of development time.

Every Product Management Roadmap is a little different, but they typically contain this structure:

• Answering the big questions about why the product is being built
• User workflows and processes
• list of intended features
• Features organised into development phases or sprints
• An overview of the technology that will be used to build the product
• Product roadmap estimation & timelines

We'll usually hold a series of 2-hour meetings with our clients to extract all the information we need for creating road maps. Learning a business well enough to understand how to fix their problems through software is tricky.

The only thing that can make Roadmapping more difficult is when the business isn't bought in. If we're ever working with a business where it seems one of the executives isn't invested in the process, we're quick to point out the reason we've mandated Product Roadmaps.

What happens without a Product Roadmap

This is a precautionary tale of what a software development project looks like without a Product Roadmap.

James, the owner of a fast-growing online training company has accumulated too much technical debt and hit a ceiling with his software. He's been using Thinkific and it's done a decent job getting him to this point. However, without migrating to a custom service he'll never grow beyond where he is.

He's validated that his customers want the new platform he has in mind and he's ready to get started!

His first move is to write a request for proposal and shop around for developers. Honestly, it’s a nerve-wracking process for James but he finds someone to work with.

They seem clued on and provide a quote. It seems reasonable but he's not 100% sure if it’s accurate or even how they got to their number.

Despite this, James is so excited about moving the project forward that he decides to roll the dice to avoid wasting any more time.

A few months pass, and the project doesn’t seem to be moving as quickly as he hoped. The developer is falling behind and tells James they’ll need more money to finish.

By the time the project wraps up its way over budget, the timelines have blown out and he's not even that happy with the product.

It's a made-up story, but one we hear all the time.

So how do you avoid ending up in this situation? You need a product roadmap.

What's the point of creating a Product Roadmap?

Before we pivoted our business to an agile roadmap focus, we struggled to guess exactly what the client wanted in particular circumstances. The obvious way to fix this is to ask questions, but this gets tedious when there are unknowns popping up every day.

Since we were charging a fixed price for the project, our team would make assumptions to avoid wasting time, which effectively reduces the project's profitability.

This approach would always come back to bite us. Project timelines blew out, the product's UI and UX was confused and our clients lost confidence in our ability to deliver what they wanted.

These problems immediately disappeared when we committed to Product Roadmapping. The process isn't just something to do for the sake of creating a planning document. It proactively solves a lot of the problems that come up during software development projects.

Here are the main benefits of creating project road maps.

Clarifying the business goals

At the start of a project, I usually have very little understanding of how my client's business operates. When they approach me asking for help to build a new application, what they're really asking is help fixing a business problem.

For example, a manufacturing client approached us a while back asking to build a clone of another application with a few different features.

On the surface, this sounds okay, but as I started digging into their business objectives, I realised that 90% of the features in the target app wouldn't be used. The 10% of features they wanted to clone didn't fully fix the communication and quality assurance problems their warehouse team was struggling with.

Clarifying the business's goals saved tens of thousands of dollars and ended up pushing us in a strategic direction that permanently solved the core problem the business was wrestling with.

Reading between the lines and understanding what will make the project a wild success is one of the biggest benefits of building a Product Roadmap. This information helps the engineering team make better technical decisions.

Defined success metrics

A Product Roadmap needs to answer the question "what will make this project wildly successful?".

Software development can be a phenomenal investment if the right metrics are kept in mind as the product takes shape. A Product Roadmap should address what kind of measurable goals the project will attempt to achieve.

Most of the time these goals are financially related - saving money or increasing revenue.

It might sound a little obvious from where you're sitting, but put yourself in the position of the product team three months down the track. The MVP is coming together but the budget is halfway spent. The backlog of remaining features is still huge, and it's clear they won't all be built. It's time to make difficult decisions about what gets built and what's left out.

These kinds of decisions need to be guided by the success metrics - which features will move the needle?

Getting the development team & business on the same page

Every business is unique. Some of the little quirks about how a business runs translate directly into the way a new product should be created.

A good example of this is a chiropractic clinic Clean Commit has worked with over the past 18 months.

We were rebuilding their legacy patient management system and had started working on the SMS reminder system. We discovered that they treat a number of patients that work the night shift and who prefer to have reminders sent to their partners.

The value of a Product Roadmap in this situation is getting the development team and business on the same page.

In the example above, the chiropractic clinic is a small operation and has deep, long-lasting relationships with its customers. They don't need a solution that will scale to tens of thousands of customers. They want tools to customise how each patient is treated.

The client would never think to include their detail in any kind of Request For Proposal (RFP) document they used to get quotes from local software agencies. It's only uncovered during the deep dive of a Product Roadmapping session.

Talking through the features

Just about every client that's approached us with an idea starts by listing all the features they want to include in their new application.

There's nothing wrong with this approach, but it's a chaotic way to figure out what the first version of a product should look like.

Think about it from the point of a commercial builder speaking to a client about erecting a new office. If the client started listing things they wanted like "elevators", "motion activated fountains" and "a helipad", the builder's mind would be racing about where to start and all the dependencies of these requests.

Elevators mean more than one story, fountains require special plumbing, and helipads need clearance and unobstructed access.

However, the client may not have thought everything through. For starters, they might not have legal permission to build more than a single-story building.

Product Roadmapping allows a forum to discuss what outcomes the client is trying to achieve with their new or improved functionality. Sometimes they're on the money and describe the best solution. However, most of the time we can recommend better ways of achieving their goals once we understand why they want a particular feature.

The only way to provide an accurate quote

Product Roadmapping is only one way to provide an accurate estimate for building a complex application.

Let that sink in for a second.

If you've ever been in the position of requesting quotes from developers or agencies based on a set of requirements you've written, then the quotes provided have been purely based on guesswork.

Those guesses aren't grounded in the goals of your business either. They're inflated to make sure that the project team can build the most expensive version of the product while still making a profit.

The Clean Commit version of Product Roadmapping builds accurate estimates by starting with the main workflows users will be performing with the application. We then break down the process flows to identify the tools and features they'll need. Finally, we create user stories to describe what the user expects the system to do.

This library of user stories is called the product backlog. Our team get together and agree on the level of effort required to create each feature, taking into consideration the design, frontend and backend effort.

Finally, the effort estimates are translated to per-feature prices.

From the client's perspective, they now have a comprehensive list of everything the new system should do and how much each feature will cost to build.

Squeezing the project into a budget

Roadmap can help with pricing. Once the Product Roadmap has listed all the features and how much they'll cost, they can be arranged to fit a particular budget.

This doesn't mean that the full application can be built at a discount. What it does mean is when the client has a limited budget they can pick and choose the most valuable features to include in their application that also fit within their budget.

Reduces costs and timelines

The planning process behind a good Project Roadmap focuses on the most direct path to creating a v1.0 of your platform.

Often this means saying "no" to features and ideas brought up by the business.

Getting the minimum viable product, or initial version of the application live should be the priority, and any features that are not critical to the product's success, or that can't be done manually for a short period of time, should be excluded.

The benefit of limiting product features of the v1.0 is significantly reduced costs and timelines. For many applications, being live means making money that can fuel the rest of the product's development.

Creating a timeline roadmap for major releases

The last big benefit to creating a Product Roadmap is creating a release timeline roadmap that shows when each big chunk of features will be delivered.

Timelines are always being adjusted as new features are added to the product backlog (there's no way to capture every single feature up front). Having a rough visual product roadmap without dates helps keep customers informed, external stakeholders looped in and the product team focused as the project moves from the honeymoon phase to repetitive iterations of development.

Keeping the Roadmapping process separated

Product Roadmapping should be separated from the main body of work. In our case, it's a service we charge a flat fee for.

There's an important reason for this - it removes the incentive to rush the process and overquote the project.

Agencies or developers that handle the Roadmapping process once the engagement has begun want to get it out of the way as quickly as possible. Since they're not getting paid for it, the effort is a sunk cost. So they ask enough questions to get started but miss tons of important details.

By taking the time to understand what the business wants and present all the options, a lot of the "gotchas" are bypassed.

How to create a Product Roadmap

Here's the roadmap planning process our internal teams follow when creating a Product Roadmap for a new client

1. Define the business goals
2. Identify the major challenges
3. Capture the primary user workflows
4. Break the workflows into flowcharts
5. Split the flowcharts into user stories
6. List our best implementation suggestions
7. Plan the V1.0 features
8. Prepare the estimates & costs

Define the business goals

The first step is to understand why the business wants to invest money in a new project.

We like to do this through a survey to capture a range of insights into how the business is currently performing, and what role the new product will play.

Our questions focus on three areas:

• Business
• Questions
• Financial

The ideal number of questions is somewhere between 15 - 25. Any less than and the first meeting can drag. Any more and it becomes a chore for the client to get through.

These are the kind of questions we ask:

What problem are you trying to solve?

What does a win look like in this situation?

Where do you want your business to be in 6 months, 1 year, 5 years?

How long do you expect this project to run before you see profitability?

What kind of business or revenue will this product generate?

Why do your customers choose you over your competitors?

What kind of feedback do you get from customers? What do they like about your business? What doesn't they like?

What is the average lifetime value of a customer in dollars?

What's the value of a new lead in dollars?

What are your average customer retention and churn rates?

It's helpful to have a roadmap template prepared beforehand. We maintain a list of about 100 different questions and put together a custom list depending on the kind of application the client wants to build. If it's an internal tool to help efficiency then we scrap all the questions about customer value.

Once we've got the answers to these questions, we'll arrange the first 2-hour Product Roadmapping meeting. We find this length of time is enough to explore the product manager's answers and dive deeper into their answers.

By the end of this session, we should understand clearly how the business makes money, what problems they've been experiencing and how a new product will move the needle.

Identify the major challenges

Talking through potential blockers and challenges to the project early on is super valuable because it can impact the order everything has to happen.

A great example of this is a situation we found ourselves in about 6 months ago. An existing client approached us asking for help creating a lightweight version of Xero (accounting platform) that fits their processes better.

One of the first things we identified during the Roadmapping process was the limited access to banking information. For their idea to get off the ground they needed a two-way sync with their bank account.

This posed a major challenge for the project because bank APIs are heavily legislated. Getting a license to call and post data takes a huge amount of red tape and auditing, not to mention money.

While this wasn't exactly a happy ending for our client, it saved them tens of thousands of dollars and months of wasted effort.

The best way to think through the challenges is to discuss the big features and what will be required to build them. It's not an exact science but helps identify parts of the process that will cause headaches.

Capture the main user workflows

Writing out user workflows is, in my opinion, the most valuable exercise any business can do when preparing a Product Roadmap. It's the best way to communicate what the application should do.

A user workflow is a set of actions taken to achieve an objective.

Using Facebook as an example, a workflow would be updating a profile picture. This goal requires a series of actions:

1. Signing in
2. Navigating to the user's profile page
3. Choosing to edit their existing profile picture
4. Searching through their library for a photo or uploading a new photo
5. Modifying the photo's alignment
6. Confirming

Recording all the goals a user wants to achieve with the application gives the design and engineering team a ton of insights into what the features are supposed to be doing.

The best way to gather these workflows is to get all the project stakeholders on a call and start brainstorming. You can prime the meeting participants by asking them to put themselves in the position of a particular user type (i.e. administrator, student, logged in user, logged out user) and ask what they want to use the app for.

We like using Figjam to make this process collaborative (you can explore their roadmap templates which can be helpful in preparing a board for client meeting). Everyone has the chance to throw sticky notes onto a virtual whiteboard. It's difficult to think of all the possible things a user might want to do with a complex application which is why having three or four people on the call usually works the best.

Break the workflows into flowcharts

The next step is to break the workflows down into flowcharts

This process is essentially what I did with the Facebook profile picture example above. It's listing all the steps needed to accomplish the end goal.

We've found the best way to do this is through process flow diagrams. Visualising the flow makes it easier to understand the thought process a user goes through.

Don't skip this step. It's essential for wireframing.

When we start putting the wireframes together, we marry the wireframe screens up against each of the process flows to make sure the user can do all the things they need to by jumping from one screen to the next.

Split the flowcharts into user stories

Writing user stories is the most time-consuming part of the Roadmapping process, but it's the foundation for the product backlog, time estimates, and an accurate quote.

Each flowchart has a number of specific features required to make it possible.

My approach for extracting user stories from a flowchart or workflow is to write all the features that are required to make it possible and then split those features into user stories.

Using our example of a Facebook user changing profile picture, these are the features I would list out (note: I'm going to exclude login and authentication):

• Image upload and storage - there needs to be somewhere for the images to live once the user has uploaded them
• Media gallery - the user wants to look through pictures they've already uploaded
• Compression and scaling - no one wants to resize or compress an image.
• Image adjustments and editing - if the image isn't centre aligned it might need to be cropped and moved

Each of these features might do several things for the user. For instance, these are the stories I'd list for the Media gallery:

1. Media sort order
   As an authenticated user
   When I'm adding a new profile picture
   And I look through my existing pictures
   Then they're arranged from newest to oldest
   So I can find what I'm looking for easily
2. Enlarge images
   As an authenticated user
   When I'm adding a new profile picture
   And I look through my existing pictures
   And I select a picture
   Then I want to see an enlarged version
   So I can make sure it's the correct image
3. Image categorisation
   As an authenticated user
   When I'm adding a new profile picture
   And I look through my existing pictures
   Then I want my photos to be arranged into "uploaded" and "tagged" s
   So I can find what I'm looking for quickly

The challenge with user stories is being thorough and complete. They're the instructions for building the application. Getting them wrong confuses the development team, and leaving them incomplete causes quality issues and delays.

List our best implementation suggestions

There are plenty of ways to cook an egg and even more ways to build an application.

No one technology is "the best". There are arguments for using every language and framework under the sun, and there are literally thousands of them.

At this point of the Roadmapping process, we understand the goal of the project and the required features well enough to suggest the best combination of technology and architecture. Usually, this boils down to a single implementation, but we'll often list a handful of options for our client to make their own call on.

This is a step where you need help from an experienced developer. Picking the right technology can speed the project up and keep everything running smoothly for years to come.

Plan the V1.0 features in a release roadmap

It's finally time to put together the visual roadmap that most people would think of as the main deliverable of this process. There's two main ways you can handle the roadmap presentation at this point;

Kanban board

GANTT chart

We prefer Kanban because they line up with how we manage the project in Jira.

Every feature that the business wants to include in the first version of the product should be challenged. Keep in mind that the goal is to get the product developed as quickly as possible.

If there's a way to manual handle a feature, then it can be backlogged. If any feature doesn't fall into the product's core value, then it can be backlogged. If there's a way to use a pre-built service instead of writing the code from scratch, then the feature can be backlogged.

When you think you've got all the features sorted, take a step back and figure out if a customer would be willing to pay for what you're planning to build.

In the case of rebuilding an existing application to extend its feature set, the first version of the product can be quite big and might contain most of the features. That's fine too, there are no black-and-white rules beyond getting an acceptable V1.0 of the app working as quickly as possible.

Prepare the estimates & costs

The last thing we do during the Product Roadmapping process is to play a game of Planning Poker to work out accurate estimates.

Planning Poker requires the project team to read through every user story and talk through the level of effort required to build the feature. There needs to be a consensus on the effort, so it's important to have a few different specialists on the call. We hold these sessions with a frontend dev, backend dev, web designer and test analyst.

Everyone suggests the effort in terms of t-shirt sizes;

• XXS
• XS
• S
• M
• L
• XL
• XXL

If any feature is judged to be bigger than XXL, we find a way to break it down into smaller pieces.

Each shirt size relates roughly to an amount of effort. XXS is about 1 hour of effort when the overheads are added like testing and project management. M is 12 hours, L is 20 hours and XXL is 40 hours.

When we've reviewed all the features and agreed on estimates, I'll translate the t-shirt sizes into dollar values and present them to the client.

Since each feature has its own estimate, our clients can pick and choose which set of features they want to combine into their product to meet their budget. They can also see an accurate breakdown of the effort and costs involved in each part of their vision.

Show me an agile Product Roadmap example

We're working on anonymising an agile Product Roadmap so you can download it and see how it all works.

It's not available right now, but will be in less than a week so set a reminder to come back and grab it when it's ready.

The example Product Roadmap is a special case because it's part website and part application. We run a different kind of process to capture the information architecture and ideal layout of a website which will be reflected in the Roadmap.

Wrapping up

A Product Roadmap plays an important role in defining the product vision, aligning the interests of internal stakeholders and the development team, and acting as a communication tool.

The Roadmap creation process is time-consuming but incredibly valuable for setting the project on the right course. Once it's fully written, it becomes a pretty easy ongoing process to keep it up to date.

As an agile team, we're clearly big fans of Product Roadmaps and are always happy to provide advice on how we've made it work for our clients. Check out our services, and if you've still got specific questions about how to make your own internal roadmap work then leave a comment below and we'll get back to you!