Roadblocks in roadmapping

Philipp Schneider7/21/2020

Observed bad examples

After having worked in one lean start-up and later a start-up merged into a corporate, I noticed that roadmapping for the next few months never “felt right”. Much of the description below focus on the corporate scenario – but the majority of core issues applied to the lean startup as well, just with less steps and overhead.

• Managers align on what should be done in the next time interval. Politics are being played: everyone tries to use their influence to steer the ship in the right direction from their (limited) perspective. Sometimes managers realise that they themselves can’t scope and estimate effort, and pull half of their team into the process. Those employees main role then is to fill question marks and variables in the plan(’s master excel sheet). Managers try to cramp in more scope, while involved employees try to drive estimations up to protect themselves. This is how the fallacy occurs that the question “how much is this worth to us?” is never openly asked. As the planning uses much time, there’s a period with much less active team management, in which regular work lies fallow. Developers sometimes put good use to it by addressing tech debt which accumulated. Other times, the lack of goals and momentum is discouraging employees.
• Managers communicate to outside stakeholders (customers / investors), committing to the plan. There’s no turning back.
• Managers officially announce the finished plan to their teams. Since the plans are done, employees don’t (get to) give their honest feedback. This chatter then happens behind the heads of managers. A crucial feedback loop – Is the team motivated? Are the plans realistic? Are we working on the most important things? — is decoupled from management, leading to worse roadmapping down the line.
• In particularly bad cases, managers even never officially share the plans, e.g. because planning is only finished after the time interval for which the planning happened has already started. This communication is left to project managers, who do it ad-hoc. As a result, crucial discussion of the “why” dimension is diluted. It might even happen that people executing the projects aren’t getting a sense of the “why” at all, leading to demotivation and the feeling of organisational dysfunction and incompetency.
• Sometimes the time period is so far progressed by the time all information required for the plan has been gathered that the attempt to plan the time period is given up. In those cases, usually some new development occurred during the planning, un-doing everything that had been planned.
• There is rarely ever a retrospective on whether and how well the original plan has been fulfilled. This furthers the de-calibration between plans and actual progress.

Roadmapping utopia

In a company where employees have been hired because for their sound judgment, trust-worthiness, and job knowledge, roadmapping is a group exercise where the diversity of perspectives leads to better outcomes. Management mainly orchestrates the roadmapping process, so that it stays within limits given by the business, and to make sure that all perspectives are weighted appropriately.

Here’s a process proposal for a company with 30-50 employees¹:

• Managers take a look at the company strategy, and identify main problems and opportunities. Managers prioritise the list of problems and define roughly how much resources the solution is worth. Additionally, managers define a fallback plan for each problem space, so that every project has a course of action if it goes above resource budget or fails. Most problems should be measurable, so that the success metrics of problem spaces are known.
• In an all-hands, the company strategy is re-shared. Managers explain the identified problem spaces to tackle with the allowed resource budget. The why is front and center.
• A representative subset of the company — balancing the group is the challenge — gets together to ideate a list of sketches of possible solutions how to address the prioritised topics, keeping the resource budget and success measurement in mind. Managers are present to support (not own!) the discussion by keeping it within healthy boundaries. Ideas are rough enough that there’s no false feeling of great estimations. The precise steps what to do remains to the team members who will execute the projects. Pretending to foresee more details is hubris.
• The ideas are pitched to the company. There’s a voting process between different proposals for the same problem space. The value added by management is that management organises the voting (rules) in a way that all perspectives are balanced (e.g. to account for cases where teams have different head counts compared to their importance for the bottomline).
• The “why” and the voted “how” are officially announced as plan, again with reference of how it’s based on the company strategy and mission, and how success could be measured.
• Share the plans with outside stakeholders. Promise solutions for the problem spaces, not concrete scope.
• Towards the end of the roadmapped time interval run an official show and tell and compare what has been learned and archived compared to the original plan.

Conclusion

• Identify the most important next problem / opportunity areas to tackle by consulting the company strategy. Cap the resources you are willing to invest for the solution of a problem space. Let teams on the ground scope and estimate.
• Repeat the roadmap and the reasoning behind it as often as possible in front of the whole company. Focus on the strategy and the problem statements, not on concrete deliverables.
• Try to minimise the outside commitments to reduce delivery pressure which could put other important items on the plan at risk.
• Before making the next plan, judge how well the old one worked out and why.