Is Your Engineering Roadmap Destined to Fail?
Maybe you’ve been there:
You’re in a meeting with your engineering team. You’re discussing the projects you’d like to finish in order to improve the codebase. Maybe this includes refactoring, security stuff, replacing dependencies, or adding redundancy for when us-east-1 inevitably goes down again (but the status page: ✅). You prioritize these projects and everyone agrees they’re important.
Months pass. Nothing gets done.
Here’s the secret: these roadmaps are doomed to fail. Not because your team is bad, or your PM is bad, or that the projects were bad. But the system is designed to pit one set of priorities against another — disregarding their relative importance — and the new shiny things always win.
In theory, engineering roadmaps are a tool of great empowerment for your engineering teams. It’s a curated list of the projects that matter most, made by the people who know best.
But in practice, engineering roadmap projects are almost always deprioritized when they go up against product roadmap items, meaning new features and enhancements that come through your product management or sales teams. Engineers are left fighting for scraps of time to get critical work done.
Where things go wrong
Classifying priorities as either product or engineering creates an artificial world where they don’t align to the same goal. All projects - whether coming from a PM or an engineer - need to have clearly articulated business impact. This impact can be measured in user satisfaction, revenue, or whatever other metrics show up on your dashboards. Once you have clear measurements of predicted outcomes, it’s a matter of prioritization.
Here’s what I mean:
It could be the case that the first 3 projects on your engineering roadmap will have more positive impact on user experience and revenue than the first 3 on the product roadmap. So if you’re working from two lists, and bargaining to say “let’s do two new features, and then we’ll make time for an engineering product”, everyone loses, including your customers.
Here are roadmaps for my fake documentation app.
Product
Custom notifications
Editor role type
Add toggle options to headers in text editor
Keyboard shortcut to add a new post
Trello integration
Support for payments via invoice
Engineering
Optimize image compression
Migrate last test suite
Spike - Feature flags
Untangle and remove dead code
Fix memory leak in text editor service
In this case, it’s so critical that the memory leak in the editor is fixed before adding toggle options to headers, or bringing more people to editor by creating a new role type. If the memory leak stays hidden in the engineering roadmap, the risk is high that the increased usage of the product will actually result in poor satisfaction instead of the upward momentum the business needs.
This isn’t about giving your product manager unilateral authority over what gets built. They don’t want that. Instead, elevate engineering to have an equal stake and ownership over the product and the outcomes. Product teams have a high sense of ownership, and with that ownership comes accountability for outcomes.
Better measurements always win
I said above that “the new shiny things always win”. The shiny new thing almost always has better measurements. It’s a lot easier to count the number of new logos, or the increase in average deal size, that results from launching a new feature.
It’s much more difficult to measure the absence of something. For example, how do you measure the absence of an incident because you took a week to add some fallbacks for a 3rd party dependency that’s been a bit flaky lately?
Contributing to this is the tendency of some engineering teams to skip a mini-discovery or validation step before pitching projects. Using data to inform decision making is a key skill for engineers, so don’t skip it. You should be able to make a case for your projects that goes beyond just “we know this needs to be done.”
To be extremely direct about the point above: it is the responsibility of engineering teams to articulate the business value of projects to their cross-functional partners. It’s sometimes the case that your PM doesn’t have the subject matter expertise to know the value of a project pitched by engineering, which makes prioritization very difficult. It’s your job to communicate with data so everyone has the same information.
Money is a language everyone speaks. How much does an outage cost when you need to refund monthly subscription fees per your SLAs? How much risk and cost is associated with a security breach? How many enterprise customers would be likely to increase their investment if you had an executive report from an external pentest?
In the absence of money, think about UX and customer satisfaction. Dig up support tickets that mention latency or perceived lack of product quality. Look at churn rates and exit surveys from former customers.
Where do internal engineering projects get tracked?
Pushing toward one roadmap doesn’t mean that all engineering-proposed projects need to be a discussion with external stakeholders (no one wants that, even the stakeholders). A stronger partnership with your PM doesn’t mean that engineering loses all autonomy. There are some projects which don’t necessarily belong on your product roadmap, where engineering should have the final say. A rule of thumb here is that if you’re not going to write about it in your changelog or release notes, or if you sales and customer support teams don’t need to know about it, you can skip the overhead of adding a formal roadmap item. These projects are usually about research, internal efficiency, or velocity.
Spikes or POCs of new technologies
Improving development environments
GitHub cleanup (stale PRs and projects)
Adding new automated tooling (artifact scans, dependency scans)
You might call this is a roadmap, but it’s really just a backlog. These projects are important and your team needs to create capacity to accomplish them.
Some teams schedule only 75% of their available time with roadmap sprint work, leaving the rest of the time flexible for bugs, incidents, and internal-facing work. An alternative approach is to remove any sprint commitments from the on-call engineer. This protects your team from falling behind in case there is an incident, and if there isn’t, they can use their on-call week to work on internal projects.
And what if this isn’t your reality?
The organizational headwind working against you might be very strong. You may not have a PM that is routinely having conversations with your development team, you may be outsourcing a lot of work which leaves little room for internal work. In addition to factors like these, you might work in an organization with a very strong command-and-control culture and a focus on deadlines.
In these cases, change can be very slow. It might take you months to build relationships with external stakeholders that put you in a position to advocate for projects your team proposes. In the meantime, get creative with ways to carve out and protect 10% or 20% of your team’s time for the items on your internal roadmap. Do some internal debugging and try to understand where the pressure around deadlines come from. There are likely some projects that help you team execute faster, and if you’re armed with the right data, you can make a compelling case for those projects because they quickly pay for themselves.
