Build A Better Execution Roadmap
Intentional or not, every company follows an execution roadmap, where teams allocate time, i.e. resources, to execute against a list of initiatives in certain order.
Building an execution roadmap typically starts with setting priorities. Many tools are built to allow easy ranking of feature priorities. Your team works through this list of priorities and delivers features to 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 the frustration, I wondered why 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 micro management 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.
Even if we can define product priority, here are still several key factors to consider when you build your execution roadmap.
Priority
Priority indicates the level of impact towards your strategic goals.
Effort (or Opportunity Cost)
High priority and high effort initiative may not produce better market/ customer result than a few lower priority but much smaller effort initiatives combined. Since hiring and ramping up takes long lead time, effort indicates opportunity cost that should be evaluated thoughtfully.
Skillset
There are different skillsets within a team .e.g. frontend, backend, devops, QA, UX… demand for each skillset fluctuates and differs from actual distribution of skills. If a company adopts resource forecast, temporary skillset balance between teams may be adopted to improve portfolio output, instead of having un-utilized skillset for one team to take on less beneficial 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 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, prototype validation.
Deadline (or Quick Wins)
Some relatively lower priority features can be desired/ demanded by customers or required by legal… launching them on some deadline needs some plan-ahead in your execution roadmap.
Time in Market
Often it’s better to iteratively build, release and test 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 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.
* * *
This post was originally published at dragonboat.io
