Unbundling your roadmapping process

A recent podcast on Lenny Rachitsky’s show rekindled some thoughts on roadmapping I’ve had for a long while about how complex product processes such as roadmapping can be easily corrupted. One common culprit is “artifact escalation” i.e When an artifact shifts from being the output to becoming an influencer of the process itself.

Three key activities during roadmapping / prioritization are : 1. Building 2. Evangelizing 3. Documenting. All three are time consuming (also iterative), need different mindsets, take completely different approaches and produce different artifacts. One product crime during roadmapping is the muddling / blending of these distinct steps into one step.

A common culprit is using frameworks that are good for one of these steps, but are unfortunately mis-applied across all three, thus blending different steps into one. For example using a tabular prioritization framework like RICE during roadmap building vs its intended use during roadmap documentation.

A tabular framework forces a linear / row-wise way of thinking. But creating and prioritizing opportunities in a roadmap is non-linear and graphical in nature. Imagine you are a PM for a car driving simulation game and are tasked with improving the vehicle satisfaction for one of your top selling vehicles. You put your head together , work with your fellow design, engineering, manufacturing and growth counterparts and put together a causal-tree (for example a NSM tree or a fishbone diagram or a strategy tree or an opportunity solution tree).

Then you start looking deeper and identify the sub-levers that move each of these above drivers.

You along-with your team are looking under the hood of your car, identifying top level problems you need to tackle (improving driver experience, enhancing security, increasing passenger comfort etc) and then looking at the levers you can pull (better acceleration, better cornering) and finally the opportunities that can move those levers.

Your brain is operating in “assumption laddering mode” where each opportunity has a likelihood of moving a lever, which has its own likelihood of improving one or more key drivers which are in turn moving your north star in a favorable way. You’ve done the hard work of researching your customers, bringing your teams together, understanding these different associations and are now finding the top most opportunities to focus on, each with a certain likelihood. These assumption maps are also going to be enriched by multiple stories, data points and knowledge titbits during this brainstorm — contributed by multiple different perspectives. Make those assumptions and associations explicit, challenge your teams to question them and debate them — refining and iterate until you have a winner. A sample artifact would look like a decision tree similar to this — (a hybrid of John Cutler’s North Star framework or Teresa Torres’s OST’s)

This collaborative, time consuming process has a higher likelihood of making the “why” — clear to your counterparts, and also make it stronger by trial / debate. Most importantly the why is more likely to be backed up and transmitted by voices other than yours. When opportunities are finally prioritized they can take into factor other inputs as well, such as effort, complexity, cross functional dependencies/blockers — and you end with a portfolio of bets, which the team has co-created.

Tabular roadmaps are not unhelpful though. Once you reach the “documentation” step, these frameworks allow you to document bets and outline assumptions in a trackable manner. Since you have built and evangelized your roadmap with your peers / managers , these tables are a good way of documenting the roadmap, and all the assumptions behind it.

With this approach you are ending up with a tabular document that is

• Co-created by a cross functional team vs created/pushed down by product
• Assumptions are identified & published vs hidden & obfuscated
• Timeframes to bet maturity / impact are clear vs indefinite and ambiguous

Documenting your bet matrix helps you track, reflect and ultimately decode the quality of assumptions you are working on. But more importantly they will eventually also tell you a lot about the surface area of your product itself. For example, is there an area you have been overconfident about — and have consistently missed the mark on impacting your top driver or NSM. Or for example an area where the bet had an outlier impact on your NSM, through a driver that you are probably underinvesting in.

In summary, to avoid issues with your roadmaps such as “lack of strategic clarity” “lack of buy in” “prematurely stopping bets in flight” , try to make your roadmapping processing transparent ; and use the right frameworks in the right step.

Credits to Jiaona Zhang and Lenny Rachitsky for a great podcast (link) to rekindle my thoughts.