An execution roadmap is the plan that brings your company’s strategy to life.
Intentionally or not, every company follows an execution roadmap, where teams allocate time, i.e. resources, to execute against a list of initiatives in a certain order.
Building an execution roadmap typically starts with setting priorities. Many product prioritization frameworks and tools are built to allow easy ranking of feature priorities. Your team works through this list of priorities and delivers features to the market. This works quite well when most work is done exclusively within an agile team.
As the company grows, it will have multiple product managers and multiple teams. Often one product manager needs other teams and other product managers to support her features.
When this happens, a friendly negotiation may settle the request. Sometimes though, the competing demands need a mediator, often the engineering manager of the team. The inevitable question usually is, which feature/ story has a higher priority. It seems that once we get our priority straight, the roadmap will fall into place effortlessly.
That’s what I thought too, earlier in my career… Back then, our engineering team supported both our “home” product managers and product managers from other business areas. Often there were back and forth debates on which projects are higher priority. Since they came from different groups, it was harder to gauge one group’s metric (priority) against the other group’s. Out of frustration, I wondered why the CEO or the head of product can’t just define priority for the entire company, from 1 to n. Then the team can just build them out in sequence and produce the best results for the company….
Or so I thought… but this approach fails everyone!
First off, no one person can/ should define the fine-grain level list of features for the entire company, let alone prioritizing all of them. This type of micromanagement, assuming everything is known ahead of time, is dangerous. Leaders should focus on defining strategic problems (setting strategic goals), not dictating the solutions and sequences.
Factors to Consider When You Build an Execution Roadmap
Even if we can define product priority, here are still several key factors to consider when you build your execution roadmap.
Impact
Impact indicates the level of benefits towards your strategic goals.
Effort (or Opportunity Cost)
High impact and high effort initiatives may not produce better market/ customer results than a few lower impact but much smaller effort initiatives combined. Since hiring and ramping up takes a long lead time, effort indicates opportunity cost that should be evaluated thoughtfully.
Resources (Non-fungible Skillset)
There are different skill sets within a team e.g. frontend, backend, DevOps, QA, UX… demand for each skillset fluctuates and differs from the actual distribution of skills. If a company adopts resource forecasting (often on the quarterly or semi-annual frequency), a temporary skillset balance between teams may be adopted to improve portfolio output, instead of having an un-utilized skillset for one team to take on less impactful projects while another team has to take fewer projects due to skillset constraints.
Skillset limitation also creates a new dimension to the opportunity cost.
Dependencies (or Readiness)
No one likes to be blocked… one of the most common blocking factors is when there is a dependency, either unplanned or known but poorly coordinated.
For example, there is “hurry up and wait” as you are ready, but your partner is not. Or your team can’t start because they are waiting for upper stream deliverables, e.g. user research and prototype validation.
Deadlines (or Quick Wins)
Some relatively lower priority features can be desired/ demanded by customers or required by legal… launching them on time needs some planning ahead in your execution roadmap.
Time in Market
Often it’s better to iteratively build, releasing and testing parts of a feature before the final release. Allowing time in market for feedback before building the next phase is the right way to build product… Team should use the gap to work on other features or address tech debt.
Building a good execution roadmap needs to consider all these factors. However, the process does not need to be a drawn out one that requires all the “facts and figures”. There is no perfect information on any of these factors. Create a draft, try it out, iterate as you get more information.
