The most common reason why a software product fails is because the wrong thing is built. As software developersThe most common reason why a software product fails is because the wrong thing is built. As software developers, we are in the business of taking good ideas and turning them into software, but often good ideas aren’t the right ideas or the most important ideas.

For nearly ten years, EndGame has been a long-term product partner for a group of visionary founders who are building SaaS and IoT products. But as any product team knows, there is a constant tension between building the next good idea, vs following a roadmap.

‍

How can owning the roadmap help to make sure you are building the right thing?

‍

If the most important thing about building a software product is having a vision, then the second most important thing would be knowing how to execute on that vision. A roadmap is simply your next steps toward your vision — a plan for how you intend to execute your vision over the next 3–12 months.

In a previous blog post, I talked about impact driven development and how having a vision is not enough. If achieving your vision is step ten on a ladder, you need to start at the first step and work your way up — instead of just setting out to build your vision on day one. To do this, you need a roadmap.

Are roadmaps pointless?

I’ve heard plenty of times that roadmaps are pointless and a lot of roadmaps are pointless. Anything beyond 3 months is a guess and you don’t need a roadmap to know what you’re working on next. Plus, sharing a roadmap is just going to set people up for disappointment when the plan changes — right?

In this blog post I’d like to show you why having a roadmap is a great communication tool — being a snapshot of your vision, broken down into goals for the next year and then your plan to deliver on those goals.

‍

Plans Change

A roadmap is a snapshot of your plan because plans do change. Thanks to our continuous build-ship-learn cycles — we expect our plans to change, as we learn more about our customers and the problem we are solving. But, assuming your vision is strong and unwavering, then your goals will be stable and won’t be changing. How you are going to achieve the goal can change as much as you like — in fact if you doing R&D, then you are continuously making and testing hypotheses — if your plans aren’t changing, then you’re probably not doing R&D.

If you’re struggling to write a roadmap, think about why? Is it

(A) you don’t know where you’re going (focus on vision)
(B) you don’t know how to get there (focus on goals)
(C) you don’t know how to execute on your goals. (focus on plan)
(D) you don’t know how or why to write a roadmap (read this blog)

If you’re reading this blog post because you’ve asked us how much it will cost to build an app, or to create your IoT platform, or to turn your idea into a SaaS business, then the answer to that question lies in the roadmap and in the goals you want to achieve — which may include an MVP, a beta version, solving the problem for yourself before solving it for others, finding product/market fit, prioritizing your key features, creating an on boarding process, improving conversion of trials to paying, automating subscription fees, supporting resellers, integrating with other systems, improving retention, improving performance, improving UX, scaling to the first 1,000 customers, scaling to the first 10,000.

The list of software demands goes on and on and your funding will run out, so the question is — what goals do you want to achieve before you need to raise more money (from yourself or from others)? Do you want to focus on delivering one goal really well, or get some traction on a few goals? This is your roadmap.

‍

How do you write a good roadmap?

Step 1: Key streams

Start by breaking the roadmap into different streams of work you want to manage. This might be development, marketing and support for a single product — or it might be different products or teams that you want to show on a single roadmap. Having multiple streams can be useful to highlight dependencies between different teams who are all working toward common milestones. I like to colour code the roadmap by these streams because typically they do relate to different teams who are delivering the work.

Step 2: Quarterly goals

Goals are best when they are quarterly or smaller. In other words — break your annual goals down into the big steps you need to take to get there. There are different types of goal -

Metric based goals - ie increase the conversion rate to 15%. In this case, we need to experiment and measure to reach the goal.

Outcome based goals - ie I want a mobile app that allows you to place an order. In this case, we have the freedom to design and plan how to achieve the outcome.

Feature based goals — the customer has asked us to implement specific features or enhancements and we need to understand why (the objective) and how we will measure when we have achieved it (the key results).

Step 3: Order your goals

Its important to think about the order in which you need to deliver your goals — will they be sequential, or in parallel. Its not uncommon to have 4–5 goals in development at the same time, but you also want to make sure you are finishing what you start.

Step 4: Breaking a goal into deliverables

When we are scoping out a new SaaS product or IoT platform, we use a story mapping process to get an understanding of the big picture. This usually involves a hundred or so post-it notes which we then organize in two dimensions. The first dimension is usage sequence — looking at the user journey to understand the order in which tasks need to be done. The second dimension is criticality — looking at which tasks are more important to the user and to the business. This process can help to flesh out the priority of the goals as well as the planning out how to break down the goals.

Later on in the product development, when planning out goals for the next quarter, it’s useful to brainstorm the list of tasks and deliverables then prioritize them by difficulty and impact. If the funding and/or timeframes to achieve a goal is limited, as is normally the case, then this can help flesh out what work will help us best achieve the goal with the time and money available.

We refer to the blocks of work that will achieve a goal as epics. I explain more about how epics, user stories and objectives fit together in this blog post, Mind the gap.

When the product team come to deliver an epic, it will be broken down into user stories. But the user stories are too much detail to include on a roadmap.

When we are working with our long-term partners, we will sometimes get specific instructions for what to build and sometimes we will get a high level goal. In both cases, it is our job to articulate this as an objective that is delivering against a product goal so we can show our partner that we understand the bigger picture, communicate with the squad and track our time against the goal.

Step 5: Identify objectives

This step can happen with or before step 4, but often when you are brainstorming the roadmap — it’s easier to just let the ideas flow and then look at them later and see how they can be grouped into objectives.

An objective represents a bundle of work that can be defined, measured and released and will typically take 1–3 sprints to complete. It may include a single feature or deliverable or it may contain a group of related deliverables. It really is a mini-goal and the reason for using objectives is to help us track progress. When starting a goal, we often don’t know what will be required to fully achieve the goal, and as we proceed — how do we know the difference between the work dragging on forever and never being finished, vs making good progress and shipping often? The answer is to break the goal into objectives, which can be measured.

To help define our objectives, we’ve borrowed the concept of definition of ready and definition of done from scrum. DoR and DoD are usually applied to user stories (which we do), but in this case we are applying them to objectives too. The reason for this is to answer two questions:

• How do we know we are doing the right thing?
• How do we know when it’s done?

We use these 9 tests to define a good objective.

‍

Definition of ready

1. Business value is clearly articulated
2. 1–3 key results are provided which can be used to measure that the objective is done
3. The work has been broken down into user stories and designed
4. The squad has estimated the work
5. The customer has signed off

‍

Definition of done

1. The work has been delivered (live or into UAT)
2. An appropriate handover (to customer, support team, release notes, blog post etc) has been completed
3. Weekly updates have been provided to the customer
4. Timesheets have been recorded against user stories

‍

Step 6: Communicate it

Why should you take the time to communicate the roadmap to the team? And how should you communicate it? The key reason is to help communicate your vision and to reinforce your goals in everyone’s minds. One of our core values at EndGame is ask why. Why does this piece of work matter, what difference will it make? How do you know when you’re done? The answer to these questions aren’t solely the responsibility of the roadmap — but during the development, when the team are facing hundreds of small decisions, if they know the goals they are working toward, then they are much better positioned to make decisions that will help achieve those goals.

In our roadmaps, we also communicate the progress, so its possible to see what work is planned, in progress and completed.

Looking back

Have you ever looked back and wondered what you’ve achieved in the last year? As plans change, do you sometimes lose sight of what you were doing 6 months ago because it doesn’t matter any more? That’s a sign of developing without a roadmap. A roadmap also gives you the ability to look back and review your previous goals. Did you execute them well? did you stay focused? Did you see the goal through?

And the most important question of all: Are you:

(A) Executing your roadmap, achieving the right goals and moving toward your vision?
(B) Executing your roadmap, achieving the wrong goals and not going anywhere?
(C) Not executing your roadmap, despite knowing what your goals are?
(D) Not executing your roadmap, because you don’t have any clarity about your goals?

If you’d like help with your roadmap, then get in touch. Our product managers are all trained on creating and communicating roadmaps and we are happy to help!

‍