Over the course of the years, the way we build software has changed. Starting at the waterfall approach -that emphasized planning and process over flexibility-, passing through a rebellious phase that culminates with the introduction of a more agile mindset -that adopted more streamlined processes that put communication and flexibility at the forefront.
This story, however, is only true for those that succeeded in shedding their dusty process-heavy skins. For most, it all stopped with Scrum, or more accurately, scrum-fall.
So, unless you are working at one of those hip and cool companies that is truly agile, you probably are familiar with the woes of planning. This article is my attempt at convincing you, regardless of your role in the planning process, that you should throw away some of the process, and leverage communication instead.
Building a roadmap
Let’s assume you already know enough about your users to make informed decisions. (Otherwise, we might as well roll a dice for every planning decision you face, and the odds of you choosing the most impactful change are about the same.)
In this context, armed with the knowledge and the research regarding the value and the impact of the possible changes, how do you choose the order we should tackle things?
Step 1: Document value and impact
First, capture the expected value and impact. Write this down in a way that is easy to reference and compare. Exact values are not recommended, abstract it away to a level where you can still compare two options, without getting stuck comparing things that are orders of magnitude below your target.
For example, given the following features and their expected impact:
| Feature | Revenue Growth | Users Impacted |
|---|---|---|
| Feature 1 | $12000 | 60% |
| Feature 2 | $12500 | 50% |
| Feature 3 | $5000 | 90% |
You may want to represent these values with a lower resolution:
| Feature | Revenue Growth | Users Impacted |
|---|---|---|
| Feature 1 | Big | Medium |
| Feature 2 | Big | Medium |
| Feature 3 | Medium | Big |
This saves you time discussing if the impact of the extra 10% of your users from “Feature 1” really is more important than the $500 from “Feature 2”. Instead, you can agree that they are equivalent.
Step 2: Prioritize across features
Now that you have the means to compare and decide which features should be first, make sure to not simply sequence them without giving it some thought. Your product might be in a different phase, where different approaches are more valuable. This information allows you to make better decisions, regardless if you are launching something, growing your user-base, or hunkering down to face tough competition.
Aside hard-dependencies, when most of your options are parallelized, you want to look at them at a higher level and identify opportunities: Problems that have the same root cause; Features that address the same problem; Features that simplify other features; Smaller implementations that validate unknowns. These are the types of things you want to highlight and communicate.
Step 3: Repeat
I can guarantee one thing to you: once you build your roadmap, it is stale. Don’t let this discourage you, because it is still useful despite that. As the world around you changes, and new things are discovered, you need to reevaluate and continuously rediscover your roadmap.
A competitor can launch a competing feature, your customer-base might change, a previously unfeasible project might have been facilitated by other efforts. When these things happen, make sure you revisit your roadmap and update it to reflect this new reality.
Don’t be ashamed of updating your previous estimates and research. After all, you’ve learned something new!
Culture change: Talking about your roadmap
Make sure all of this information is not only captured and shared in small circles. Disseminate the information and make sure that not a single key is pressed without the awareness of the value and impact of the work. Once again, this is for everyone, regardless of their role.
Keep an open channel to spread this information, as well a channel to challenge it. You don’t want to be the only one allowed to think about clever solutions or edge-cases. Let your team contribute with their own ideas and insights. Sometimes, only those closer to the code or to the customers can see opportunities.
Some of the benefits of this approach
Alignment and empowerment
Keeping your roadmap up-to-date and clear allows for everyone to visit it and learn from it. This means you can (and should) stop those never-ending email conversations to share updates on the roadmap. Instead, just use the roadmap as a single, living, source of truth.
This also allows your team to be involved in your product, beyond just “doing their assigned tasks”. They can see the road ahead, make suggestions, think about the future and get excited for the work ahead.
Better risk management
All of this communication and information also allows your team, at every level, to make responsible decisions.
We know plans don’t always come to fruition and that blockers can appear for a multitude of reasons. With this knowledge at-hand, your team is allowed to make informed decisions, even during a crisis.
When the time comes that something needs to be prioritized, or that an unforeseen problem appears, you will be glad that your team know the value expected, as well as what else they can choose not do.