TEI 226: Creating product roadmaps, Part 2 – with Bruce McCarthy

Creating a product vision of the future that’s awesome for everyone. Got to Part 1 of Product Roadmaps. Got to Part 3 of Product Roadmaps. Part 2… Product roadmaps are frequently used badly, almost as handcuffs for product managers. A year ago we explored roadmaps and how they should be used with Bruce McCarthy. At the time, he had recently co-authored the book, Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty. Since writing the book, Bruce has been busy helping companies improve how they use roadmaps. I wanted to find out what more he has learned in the last year, which is what this discussion is about. We cover: * What a product roadmap is * Who the roadmap is for * The pitfalls of roadmaps * The inputs needed to create a roadmap * How to organize a roadmap * How to prioritize product features Summary of some concepts discussed for product managers [2:35] It’s been a year since your book came out. What’s changed since then? A lot has not changed. The idea that a roadmap is a collaboration tool, not a project plan, still holds true. It’s all about the why and crafting a compelling vision that explains the vision to the customer and the company. A good roadmap avoids being specific about dates to achieve those outcomes. One of the things I’ve discovered in working with companies around the world is that they don’t have clear objectives for outcomes. If they are done correctly, those Objectives and Key Results (OKRs) can map really nicely to the roadmap. The specific dates and deliverables on the roadmap are in support of those larger objectives. I’ve also worked with companies to make sure they are organized in a way that’s conducive to executing their roadmaps in support of their objectives. When companies do not have cross-functional teams, they become siloed and progress slows down. [13:40] Who creates the OKRs? It usually starts in the product or engineering teams, but there’s an increasing interest among organizations trying them out and adopting a top-down approach. In those situations, the leadership will write the OKRs in isolation and hand them down without collaboration. Without that input, no one does anything to support them and they wind up sitting on a shelf. Getting buy-in from all levels is necessary for OKRs to be successful. A number of companies are returning to this method a second or third time after running into some of these issues the first time. [19:02] How do you create a roadmap? The first thing people often do is start making a list of features and they think in terms of engineering steps. The result is a list of things that no one has stopped to consider whether they’re really needed. I encourage them to take a step back and think about who the customer is and what that person really needs. It starts with the why and a vision of the future that’s awesome for everyone. Once you have that vision, you need to consider what the obstacles are to achieving it. Make a list of problems and prioritize how to solve them. If you follow the process correctly, you have a framework to determine which features to include. [28:15] Once you have the basics in place for your roadmap, what comes next? One of the main things is obtaining buy-in. To do that, you need to understand how big each part of the project is and how long it will take to complete. This can be as simple as assigning problems to quarters and trying to do as much you can to work on that problem during its assigned quarter.