How do you balance the level of complexity / granularity of a roadmap? What is just enough fix and flex?

Your roadmap should have just enough details on the top level that will explain the below three things:

• WHAT?

  • Summary of the problem, high level potential solution and the link to resources (documents, diagrams etc)

• Why?

  • Value prop and mapping with the business goals and priorities

• When?

  • Delivery time

  • It's great to break down the delivery time into smaller chunks and have clear milestones for the phases.

The rest of the details and granularity should be out of the roadmap and into execution process/tools.

A roadmap should provide structure without rigidity—a foundation for change rather than a fixed plan. The tech world is dynamic, and no 12-month roadmap will remain untouched.

Striking the Right Balance:

1. Start with the Problem & Persona – A roadmap should be anchored in a deep understanding of who you’re solving for and what pain point you’re addressing.

2. Plan for Learning – Build a quick MVP, collect feedback, and continuously adjust the roadmap based on insights.

3. Keep a North Star – Maintain a high-level vision that defines success and ensures alignment with customer and business value.

4. Adjust Granularity Over Time:

• Multi-year roadmap → High-level vision, flexible and directional.

• Yearly & quarterly roadmap → Strategic priorities, adaptable based on learning.

• Monthly roadmap → More concrete, but still open to changes.

• Sprint/Iteration roadmap → Fixed to minimize distractions and allow focused execution.

Managing Complexity:

• Too much detail too early? Leads to wasted effort as things inevitably change.

• Too little detail too late? Causes misalignment and slows execution.

• Balance is key → Keep long-term plans high-level and adaptable, while short-term execution remains focused and predictable.

The rule of thumb: Anything before development starts is open to change. But once a sprint begins, the team should work without disruptions.

My preference is to focus a roadmap on "big digs" or themes of investment. Customers (and your sales team) generally want to see a roadmap not because they care about each individual line item, but to understand your general direction and whether that aligns to their own strategy. The roadmap is a tool for you to tell your story, and the more wiggle room you can buy yourself (i.e. staying away from very granular investments), the easier it is to tell that story. Roadmaps are as much marketing instruments as they are representations of product investment.

Now, I recognize I've always had the luxury of working at a Series B or later company, but I am also an investor and I've read enough pre-seed and seed-round pitches to know that this holds true even for earlier stages. The only difference is that at earlier stages, you are likely to pivot your roadmap eight ways till Sunday; if you are pre-revenue, nobody is going to take those roadmap items as commitments. They merely want to understand that you've thought logically about where your company could be in a year.

What is shared on the roadmap is all about who the audience is you are talking or preparing it for review and what incentives they have. Some things I have found success with are:

• For the executive team the focus should be on a few large items or themes that have clear ties to business outcomes. If the business focus is on new revenue focusing on the high level items that are intended to drive new sales with high level explanation of how (It serves a new buyer persona, it is a new usage based add on, etc.

• For a delivery team the roadmap might need a lot more granularity and may need to be a lot shorter in time horizon. The team cares about what they are working on right now with a glimpse of the future. I find it is really important to remind the team of an overall vision, why it is important we are going there and how the most recent work keeps us moving in that direction to keep them motivated and focused on what we are doing.

• For fellow product managers you might focus on how your upcoming deliverables are impacting the larger KPIs or how you are building features they might leverage to improve their own KPIs.

There are many other stakeholders you could be building a view for at any time. Unfortunately there is not a one size fits all roadmap format for them because their incentives are different and you want to show them what you are working on as it contributes to those incentives.