Feature-Driven vs. Outcome-Driven Roadmaps: Which one will drive your business Forward?

In software development, roadmaps give you a detailed outlook of what you’re going to build. They’re a great way to scope out a project, to set goals and to figure out what resources you’ll need.

We’ve identified two major types of roadmaps: feature-driven and outcome-driven. The first plans the project’s technical features in more detail, while the second focuses on the end goals and objectives.

How you make your roadmap depends on your business type, your overall goals, the time you have at hand and the nature of what you’re building.

So in this article, we’re going to tell you what a roadmap really is, and if you should focus on either a feature-driven or outcome-driven roadmap.

What is a roadmap in software development?

Taking aside the technical aspect of things, a road map is supposed to show you which way to go in order to get to a destination. Maybe you’re using Waze, and it’s showing you potential delays, places monitored by the police, construction, or other roads to take.

In software development, roadmaps aren’t that much different. You want to get somewhere. As this is software, oftentimes you’re trying to fix an issue - maybe there’s a group of people needing a place to watch and discuss movies. Or you need to help therapists keep track of appointments and invoices.

The key to starting a roadmap is defining that big objective you’re trying to get to, or a series of goals you want to achieve.

Here are the key steps to creating a roadmap in software development:

• Map out your goals. What are you building and why? Who are you building for and how will your tool help them? How will this help your business?
• Define key deliverables. What do you need to build? In software, it’s most likely an app, which will always include: product discovery (figuring out exactly what the app will do, key user flows and desired look & feel), UI/UX design, frontend & backend code, testing & refining.
• Set a timeline for your work (phases). How long will it take to complete each deliverable? Gather your team and give estimates based on previous experience, similar projects and availability. You can also divide work into phases if you wish to deliver features gradually.
• Map out required financial, human and technical resources. How many people will you need to work on this project and what are their roles? What’s the cost estimate for each phase of the project? Are there any major technical requirements such as APIs, tools or plugins? This is a good point to assign work to specific employees, such as project management, design and development.
• Evaluate & refine. You won’t be working on your project alone, and thus you need to leave space for your team’s input for the roadmap as well. Involve all key roles and ensure the project timeline is doable (especially the code work), that the financial estimates are accurate and that your required team members are available and equipped.

Once you’re done creating your project roadmap, you’re successfully outlined all project components & requirements and thus can start making Kanban boards and assigning specific tasks.

Feature-driven software project roadmaps

When creating a feature-driven roadmap, you’re focusing on what needs to get done and not as much on business goals & general objectives. Just like the name implies, you’ll spend more time looking at the features you’re implementing and creating detailed plans on when & how they’d get made.

In a feature-driven roadmap, you’re outlining what’s going into your software more than you’d outline objectives. What are the key features? What goals will users be able to achieve in your app and how? What technical implications will these features have and what requirements do they imply? Do you need certain APIs or technologies?

In this part of a project planning session, you’re going into detail about features and thus doing product discovery. This involves more discussions and user research, but it’s beneficial in the long run.

Feature-driven software development roadmaps can be beneficial because:

• You’re creating a clear base for development tasks. When focusing on features, your roadmaps will contain more details about what your desired features require. So if you’re building a complex onboarding feature, you’ll map out the creation of a multi-step process, what goes into each of them, what’s stored in the database, and so on.
• You’ve got a clearer outline for the UI/UX part. If you’re doing rigorous planning in terms of app features, you might be outlining user flows well enough for your UI/UX team to start working faster. They’ll also have a clearer picture of the kind of flows your app requires.
• You’ll start building faster. With a detailed feature-driven roadmap, you’ll have a clear outline of tasks and will spend less time writing them for Kanban boards. In other words, your devs will be able to get right down to it.
• You’re doing all the tough discussions at the beginning. All the long meetings and complex brainstorming sessions will happen during the roadmapping stage. This means that when you start working, all you have to focus on is actually building the software. As you go, you can of course iterate and adapt if you realize a part of a feature isn’t actually suitable or is a waste of time.
• You can easily evaluate how the software was implemented. When setting up a detailed feature roadmap, you’re creating guidelines for how those features will work. Once you’re done implementing, you can test said features against your original roadmap and ensure you stick to the concept you settled on at the beginning.

Thus, through a feature-driven software development project roadmap, you’re creating a better base for the work ahead, and more accurately scoping technical requirements & functionality.

Outcome-driven software project roadmaps

When focusing on outcomes, your roadmaps are more about the destination. You’re creating a bird’s eye view, a more general description, a lower fidelity project plan. It doesn’t mean it’s not as useful, but you’ll be doing extra work scoping out the technical tasks.

An outcome-driven roadmap focuses on clear objectives: specifically what do you want to achieve, who’s your audience and when do you want this to be completed. The SMART standard for creating objectives is useful here. For instance, you might want to: raise conversion rates by 15% for free users 6 months after launching the project. You’ve set a specific goal, named a target audience, and set a timeline.

Your outcomes can also be customer-focused: instead of business goals, you can set goals you want customers to be able to achieve within your app, and thus you’ll center the rest of the roadmap around what you need to implement so that your customers can achieve said goals.

Outcome-driven software project roadmaps are beneficial because:

• They’re faster & easier to create. Compared to feature-driven roadmaps, here you’re focusing on goals and results. No time spent brainstorming features & figuring out technologies.
• You can present your concept easier to investors. Investors might listen more to outcomes rather than technology and functionality. When you’re focusing on objectives, you’re showing what your software can achieve. It’s easier & faster to present your ideas to investors and thus get enough funding to spend that extra time mapping out the features.
• You can evaluate, in more detail, how well your project went. When setting specific goals to follow, at some point you’ll have to go back and see if you did achieve them. If you’ve set very specific goals using percentages and timelines, it’s easier to see if you did, in fact, achieve what you set out to do. 
• They give you structure. Having a clear set of goals at the beginning gives you structure and helps you stay on track. You’re not just randomly building an app, but you’re trying to achieve something.

And so, outcome-driven roadmaps are a great way to decide what you want to achieve and when. You’re working towards a goal and mapping out features set to achieve that goal.

Which type of roadmap is better for you? 

Whichever type of roadmap you choose to create depends on your business type, goals, available timeline, financial & human resources, and how fast you want to start working & then launching your software project.

Here’s how to decide which roadmap type to choose:

• Will you start building your project right after creating the roadmap? If your answer is yes, you’ll benefit more from a feature-driven roadmap. You’ll need to know exactly what you’re building before you start.
• Do you need funding for your project? If you need funding and haven’t started building or mapping out features, an outcome-driven roadmap might be more suitable for you. It’s quicker to make and might be more appealing to investors compared to technical jibber jabber.
• Are you building something from scratch or adding new features? If you’re just adding features to an existing app, a feature-driven roadmap makes more sense. You still need to settle on some goals, as those features do need to achieve something - but your focus is on the functionality.
• Who’s creating the roadmap? You can’t ask a non-technical team member to create a technical roadmap in detail. If it’s a project manager or business executive creating the roadmap, it’s more convenient to create an outcome-driven one. Whereas if your CTO is doing it, they can collaborate with the technical team and create a feature-driven roadmap.
• How much time & resources do you have? Creating a very detailed roadmap takes time and effort. If you’re trying to get out there & build, chances are none of these roadmaps will be suitable for you. You might start by your executive & management team creating an outcome-driven roadmap, and then delve into detail by involving your UI/UX design team and then technical team to map our user stories instead of a feature-driven roadmap. If you do have plenty of time & resources, a roadmap that unites both of these concepts might be a good choice for you.

After all, whether you made a feature-driven or outcome-driven roadmap, it’s very useful to create one in the first place. You’re getting a clear starting point, you can assign work and create a project timeline, and you’re not building based on a vague concept but using a detailed plan.

If you’re having trouble coming up with your project roadmap, we can help you create the best roadmap for your software & business needs, entirely for free.

If you liked this article subscribe and get an email when we publish new, juicy stuff. We hate spammers, so we don’t spam.