Escaping the Roadmap Trap

This article proposes several alternatives to feature driven roadmaps.<p>But it ignores the main reason that roadmaps exist: as communication documents to the rest of the organization. This is what I used roadmaps for as a PM for a decade, but it was driven home after talking to hundreds of PMs after founding my fourth company[1] and coaching PMs and product&#x2F;dev teams to level up for another decade[2].<p>The real roadmap trap in my experience is that the org takes a roadmap as a promise of when specific things will be delivered. The best approach to avoid this is to not do roadmaps. But that’s also unrealistic for most orgs. The next best approach is to show the org short-term work that will definitely get done, and caveat the heck out of anything longer term. I’ll happily commit to 6-8 weeks out, tentatively commit to 10-20 weeks, and add large asterisks to anything longer than that.<p>1- <a href="https:&#x2F;&#x2F;www.savio.io" rel="nofollow">https:&#x2F;&#x2F;www.savio.io</a><p>2- <a href="https:&#x2F;&#x2F;www.Reemer.com" rel="nofollow">https:&#x2F;&#x2F;www.Reemer.com</a>

I&#x27;m really wondering in which world the product managers are living in.<p>What is the goal of a roadmap ? This article doesn&#x27;t even touch a point on it.<p>The goal is : In any company there are people who want to have an answer to the question &quot;what comes next on your product?&quot;. Those people can be any of: CSM to prepare a presentation for customers, bored customer who want to talk to CSM, Sales people who want to impress their prospect, Execs to tell the public and investors that things are moving. Do those people care that the roadmap is going to be respected ? Not really.<p>The roadmap is not a product management tool, it is a communication tool. So my advice to PM, you are asked to create a roadmap ? Put all the things in the roadmap that people want to hear, forget about it, and continue working on what you were working on.

Interestingly there is no product on the markt to collect feature ideas and classify them. Kanban boards etc. Are nice, but if you store many ideas you will completely lose focus.<p>Ideas, which may or may not be implemented one day have so many dimensions: time required to build it, dependencies which must be built first, usefullness in several aspects, module the software needs to be implemented in and interacts with.<p>The best i have yet seen was a good crafted excel&#x2F;airtable with a lot of columns. But deciding which one to build was again not easy as you could not see dependency chains etc.

Ever since I worked in multi stage stochastic optimization I think of strategies in terms of decisions at each nodes of a tree of scenarios. Basically you want to optimize on the long term objective function, and take decisions at the optimal time based on the cost of indecision and the estimated benefits of having more information. Having probabilities associated to each branching in the tree of scenario also makes it have baked in risk management. This is not so easy to apply in practice but it is worth doing and allows having a much longer horizon: else how could you make a strategy with decisions in 6 months not being dependent on the results of the decisions you take now ? As another comment pointed out, the main goal of product roadmap is communication, strategy is something else. In this case the roadmap could be the most likely path to take in the scenario&#x2F;decision tree, with diminishing confidence over time based on the probabilities observed.<p>Multi stage stochastic optimization is often used in finance&#x2F;trading (e.g. portfolio optimization), I highly recommend to check it out.

If you&#x27;re interested in the mathematical background, I can highly recommend: <a href="https:&#x2F;&#x2F;medium.com&#x2F;@kentbeck_7670&#x2F;decisions-decisions-or-why-baskets-of-options-dominate-9ac63658b593" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@kentbeck_7670&#x2F;decisions-decisions-or-why...</a>

A lot of resources on product management are mixing what some commentators are pointing here: roadmap can mean:<p>1. Communication tool to tell others in the organization (or even outside) what you&#x27;re planning to build.<p>2. A framework for your product and&#x2F;or engineering team that helps you prioritize the work.<p>This article obviously focuses on the latter. One of the most common mistakes however is that PMs try to use a single deliverable for both.<p>Yes, there are interesting tools trying to address this but my advice is to study different frameworks to help you think about what your main challenges are - then stand up the process in a spreadsheet as you&#x27;ll need a lot of flexibility to get to something that works in your specific case. Only then look for dedicated products and choose the one that works best for the process you ended up with.

Does everyone know what we&#x27;re doing or not doing and why?<p>I&#x27;ve written a bit about these topics.<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25288605" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25288605</a> (a reply to someone interviewing product managers).<p>Excerpts:<p>&gt;<i>Explaining the objectives at a high level in terms everyone understands, then going incrementally deeper to tie these objectives to specific actions of the relevant people.</i><p>&gt;<i>Tying revenue to scalability to spinning up Kubernetes nodes to an open issue to a line in a particular file that should be changed is a journey across abstraction levels.</i><p>This link contains links to other replies. An &quot;index reply&quot; here <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25244246" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25244246</a> that contains links to other replies.<p>The ones that pop to mind expose what I call &quot;fractal communication&quot;: communication that spans across several levels of abstraction that allows people to hook into at the level of abstraction that is relevant to them.<p>Excerpt from <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25398448" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25398448</a>:<p>&gt;*- Align everyone: through written communication accessible anytime by anyone. Communication should tie objectives to actions and penetrate several abstraction levels and be consumable by advisors, board members, non-technical people, technical people. Call it &quot;fractal communication&quot; that still makes sense from any abstration level you read it. This enables everyone on the team to chime in at the abstraction level they&#x27;re comfortable with. You write an email that ties objectives on say, revenues, in a language that speaks to some, and then tie it back to specific activities, an issue in the issue tracker, and a line of code, so that everyone sees how things fit together and are intertwined. Everyone knows what to do and why they&#x27;re doing what they&#x27;re doing. They can come up with ideas or correct assumptions or mistakes.<p>Other relevant replies:<p>- <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21598632" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21598632</a> (communication with the team, and subsequent reply: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21614372" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21614372</a>). The second link explains the types of emails I send (&quot;synthesis emails&quot;, &quot;shift emails&quot; that are sent when we&#x27;re taking a turn, and &quot;announcement&#x2F;status&quot; emails).<p>- <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22827841" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22827841</a> (product development)<p>The &quot;index reply&quot; contains other replies I believe are useful as well.