If you’re here, you’ve probably worked with product roadmaps before. You may even have been responsible for owning one. This article isn’t an introduction. Instead, consider bookmarking it for a few helpful reminders to come back to when you’re starting a new roadmap, or re-evaluating an existing one.
Product strategy first, then product roadmap. The strategy informs the roadmap, not the other way around. Don’t make the mistake of jumping right in to plotting a course before setting a cardinal direction.
Product roadmaps are not built on intuition and persuasion. Product management is not about lone visionaries. In most organizations, it’s an exercise in influence without authority. Don’t write your roadmap and then try to sell it to the team. Make your roadmap a shared document of the plan that everyone on the team has committed to, because they are equal partners in developing it.
Don’t wait until the end to get executive buy-in. Similarly, while you can add folks later in the process, there are a few who should be involved from the beginning:
- the business leader (CEO, or similar role within a department of a larger company);
- the head of sales, marketing, customer service, or whoever is going to be selling this product to customers;
- the CTO, or whoever leads the team that will be building the product.
Another note about working with your CTO: Any good engineering team will have work to do that is not focused on implementing new features. This includes bug fixes, refactoring, automating deployment processes, paying down tech debt, and other capacity-building activities. Have a frank discussion with your CTO about what kind of development capacity you can expect to be available for new features. Express this as a fraction of overall development time. This will help you better align your plan with actual capacity instead of an imagined ideal capacity.
Sequence, then schedule. Order features by priority before you start to schedule them to quarters or months. Not only does this help you avoid building features in the wrong order (who cares about password reset when you can’t create an account?), it also makes scheduling easier, because you can combine your sequence and user story points with dev capacity to generate an estimated schedule.
Begin discussions with a strawman. Make a first draft that you expect to be wrong, and be clear with the people you’re sharing it with that it is probably wrong. Humility is your friend. Use that artifact to collect useful input from everyone involved. It’s a lot easier to react to a concrete plan, even if it’s absurd, than to pull useful insights out of thin air.
Once you have the final draft, make sure to check with the wider team (legal, compliance, HR) about what risks they see down the line, so you can be ready for them and everyone can have as much time as possible to prepare and adjust.