If you’re involved in product development you’ve almost certainly been asked at some point to produce a product roadmap. This might have coincided with a client conference or been part of a request for slides to incorporate when talking to an important prospect, or it might have been part of an annual business review. Knowing exactly what kind of document to supply in response to this request might have depended upon who asked you (something I talked about here and revisited in different ways here). I admit to sometimes finding this request a bit frustrating, and the reasons for this were well articulated at the Everyday Innovators Summit I attended virtually back in April and that I’ve been writing about ever since. In a session led by Janna Bastow the co-founder of ProdPad and Mind the Product, two key problems with product roadmaps as they are typically developed were discussed; she also talked about a much more helpful way to think about roadmaps that I want to adopt heading forward.

The first problem with typical product roadmaps that Janna spoke about is that they lock you into not learning; if you commit today to building defined solutions a year from now you are ‘planning’ not to learn anything new between now and then which would change your priorities. Even if you’ve correctly determined what client needs you want to address in 6 or 12 or 18 months, the learning you can do between the present and when you start that work will almost certainly impact both how you solve that problem and how long you want to work on the solution, making the dates on a roadmap inaccurate at best. An Agile product team that seeks to improve its own processes and listen carefully to what the market wants can never commit to exactly what it will work on building a year from now.

A second fundamental issue with standard product roadmaps is the way they are used by some sales teams to sell undeveloped features. Part of this stems from confusing roadmaps with release plans; release plans are about project management while roadmaps are about product management. Release plans are concerned with properly messaging what has already been built (or is nearly complete) and orchestrating the rollout of these new features, while roadmaps point toward new areas of functionality where the development team is still trying to deeply understand both the customer problem and what the ideal solution might entail. Janna stressed that ideally your sales team is focused on selling what you’ve already built – and if they cannot sell that then either you’ve not built the right product or you’ve not hired the right sales team.

Instead of these poor uses of product roadmaps, Janna helpfully reframed their purpose. A good product roadmap should be a prototype for your product strategy. It lets users know not what functionality you are building when but what problems you plan to solve in what order. Viewed in this light the product roadmap becomes a conversational collaboration tool with both internal stakeholders and external clients and prospects, allowing you to check and refine your assumptions about what the market truly values and iterate based on feedback about your strategy. Like any other prototype the roadmap doesn’t represent a commitment on what you will build and so it doesn’t need to be perfect or even ‘high fidelity’; instead its purpose is to foster learning about what your target market values and what assumptions you are making, thereby helping you understand the next most important problem to solve for customers.

With this goal in mind, she advocates maintaining a simplified roadmap that lays out what is being worked on now, what problems will be tackled next, and what you intend to research further so you can potentially work on it later. She also spoke about the value of not erasing completed items on the roadmap so that instead you can continue to track outcome to see if you really solved the problem well. I like this view of what a roadmap can offer to the many people who regularly request a copy of it: it focuses the sales and marketing teams on promoting existing solutions, it helps the rest of the business know both what solutions you’ve recently built and what new problem areas you are exploring, and it lets clients and prospects see the future of your product strategy and your commitment to solving more of their real world problems.  Of course this approach won’t make everyone happy because in truth it’s not that simple.

[featured image comes from TheOneRing.com]