How do you make a product roadmap?

Here some things I have learned about building a product roadmap for a software business:

It’s a living document. Don’t see the roadmap as fixed & unable to change. Changing roadmap every week is (probably) a terrible idea but so is thinking you plan for a year then you are all done. It’s inevitable that you will be bringing new information into product discussion so it’s never appropriate to stick to a completely fixed plan.

There’s often more than one! Think about it…there isn’t just one person who cares about your roadmap. A huge turning point for me was when I realised that different groups of people care about different information. For example we currently run 3 roadmaps:

Leadership - we have a theme-based, high level roadmap split into quarters

Customers & prospects - high level roadmap showing simply what we have in development & what is planned. You can see that here.

Development team - Detailed feature level roadmap is accessed and owned by product/development

It’s all about the input - You have to understand the demands from your customers, market and internal teams to design a product that really packs a punch

Bring data to roadmap decisions - It’s very easy to start getting pulled around by your most demanding customers or loudest internal voices. Understand the requirements of your stakeholders & their priority. Back all decisions up with hard data.

Automate - Our roadmaps are automatically built & updated using our own product, Receptive. Prioritized requirements are automatically gathered and as features change status, the roadmaps are updated. This is a HUGE time-saver….roadmaps can become an unwieldy admin task for your product team if you are not careful.