1. Is roadmapping useful in software development?

Suppose you are a mayor of Smallville. You might create a roadmap for the city that covers the various endeavors to be undertaken this year. An item on the list is “Expand Main Street” since citizens keep demanding that their commute time be reduced.

Most roadmaps are focused on delivering specific features. Instead, they should focus on the problems being solved.

Taking our example from above, the true core of the problem is that there is too much congestion. And that is a problem because people don’t want to spend their time sitting in traffic. So our roadmap item should instead be called “Commuters are frustrated by traffic.”

Software product (and problem) validation

Now that we have a problem clearly defined, the team can validate it. Since we are a good mayor, we’ve previously set up a system to allow our citizens (paying customers) to voice their concerns. We can interview them and qualitatively determine if they are personally experiencing this issue.

This gives us an idea of the impact of the problem. With user interviews, we have a clear and validated problem statement, as long as we’ve been careful not to bias the outcome of our small investigation.

Ideation — Creatively scoping technology for software developers

Another benefit to defining a problem instead of a solution is that we can use divergent thinking to creatively approach the issue. If commuters are frustrated by traffic, the natural idea is to expand the road. But maybe it makes more sense to invest in mass transit. We can go even further and create an incentive program with training for businesses to encourage remote work, thereby reducing the number of commuters.

The creative alternatives would likely never have surfaced if the roadmap item was called “Expand Main Street”. Don’t forget that you have hired individual contributors to be the experts on the specific issues. Don’t pick the solution for them.

2. How to create context in product roadmaps?

Another area where traditionally formatted roadmaps fall short is by providing too little detail. Gantt style charts are one primary example where people viewing the data don’t see any details. By documenting as much information as possible you can alleviate this issue.

By describing user interviews and possible edge cases, your technical team can provide the best solution. It’s important for engineers to understand the trajectory of a product and the functionality so that they are building things using the correct levels of abstraction.

Many roadmapping products allow items to be grouped by tags or themes. This helps the team understand the relationship between a particular effort and the overall strategy. If your team uses OKRs, consider aligning your themes with objectives types.

3. Carts and horses: prioritization and planning resources in software

So now your roadmap is filled with many problem-based items. When will it get done? I don’t recommend aligning it to a calendar since estimates are always wrong. What’s more important is that you define a maximum effort for solving or investigating a specific problem. Task prioritization is complex and effort is a key input to consider. There are a variety of methods such as ICE, Cost of Delay, and Weighted Short Jobs First (WSJF).

No matter which method you go with, don’t split your team’s focus. Knowledge work is collaborative and you’ll see faster and better results by focusing your team completely on the one most important thing. Figure out what that is and set your sights on a clear outcome.

As the current task is being completed, have a couple of options (3 or fewer) on deck. These are the tasks that have the next highest priority, after the current one is complete. Your team can ideate on possible solutions as part of the preparations (see bullet 1, above). Beyond that, a couple tasks more are in the problem validation stage. Ignore everything else since it may never be done, and if it’s truly important it will resurface.

By working backwards, you’ll identify the top 10 items your team should be thinking about, separated into three groups: the 1 most important thing to do, the 3 or so things to be worked on soon (solution ideation), and the next 5 problems to validate and deal with later.

4. Zoom out: communicating with other stakeholders

It helps to have a strategic level view of a roadmap (epics) as well as a granular version for the engineering team (refined tasks). Both versions should be readable by everyone in the company, although the details might be highly technical for the engineering version. In either case, by using consistent columns and limiting the number of items on the roadmap, your organization will find it easier to converse about strategy and tactics.

5. Estimating work in software companies

When will the work get done? Why does my engineering team keep missing deadlines? It’s hard to plan a strategy when building software is unreliable. Should I even use estimates?

Should we estimate?

Short answer: No.

Long answer: No, since estimates are unreliable. Not only does the Cone of uncertainty apply at the project level, but it also applies at a feature level. Estimates also encourage waterfall-style development where the scope is very fixed. With detailed requirement specification, the variance in estimation is 50% and with full UI design, 25%. That’s still a big variance.

Estimates are unreliable and intensive. You can quickly use t-shirt sizing estimates (xs, s, m, l) or use story points to get some idea of the complexity, but complexity does not translate to time. Additionally, you must have a refined scope, with edge cases clearly defined, before these tactics give any aspect of accuracy (something with 50% variance).

A much more effective strategy is setting a maximum cost (effort) to address a specific problem. From there, your team can experiment and prototype to ideate solutions that fit within the budget. The smaller the experiment, the more likely your team will hit the budget target. We are talking hours here, not weeks. After that, you can agree on a version that should be cleaned up and shipped to production.

Another approach is to define a run rate for expenditures and then discuss each week what the team thinks they can accomplish within that time period. Over time, your team will become more accurate with their analysis; however, there will always be variations due to unforeseen consequences, new information, legacy code, shifting priorities, and variances in communication overhead.

But if you don’t estimate effort, how can you hit deadlines?

Should my team miss deadlines?

Short answer: No.

Long answer: No, if the deadlines are reasonable. Consider if your deadlines are arbitrary and capricious or rational and consistent. Did the engineering team set the deadline? Were there changes in resources or scope? Do you have a lot of legacy code?

These are only some of the factors that can affect a team’s ability to deliver. Instead of focusing on deadlines, prepare your team to continuously deliver. By scoping down work, you can create faster iterations. With small teams (think 2), you reduce communication overhead. By investing in prototyping, you can discover edge cases and adapt as needed. Remember, that if the deadline is inflexible then the scope must be adjustable.

There are times when business needs call for a deadline, but estimations are not the way to hit them. Break down the work and empower your team to make decisions to solve the problems at hand. Continually deliver value and adjust as needed. This, along with well-formatted roadmaps are a key way for your team to communicate clearly with you. Steady progress is the easiest way for a CEO to know what’s being built.