I was reflecting on a roadmap discussion this week.
The roadmap was clear. The work was there. The rationale made sense.
And yet, it still read too much like a list of things we were going to build.
Two questions kept coming up:
What does the customer actually get, and when?
And:
Why does this matter to the business?
At first, these felt like different questions. One is about customer outcomes. The other is about commercial outcomes.
I've been thinking they're actually asking the same thing.
We describe the work, not the change
Product teams are very good at describing work.
Build the integration. Migrate the service. Launch the workflow. Add the capability.
But those describe what the team will do, not what changes because we did it.
Compare:
Build a new self-service capability.
with:
From December, customers can do something themselves that previously required support.
Same initiative. Different conversation.
Then add why it matters to the business. Perhaps it reduces support cost, improves retention, removes friction from a sale, or opens up a new customer segment.
Now the roadmap connects three things: the work, the customer outcome, and the commercial reason for doing it.
I'm not convinced the answer is another roadmap
It's tempting to create different roadmaps for different audiences.
A commercial roadmap talks about revenue, pipeline and margin. A customer roadmap talks about outcomes and capabilities. Somewhere else sits the delivery plan.
I'm increasingly uncomfortable with that.
Different views make sense. Different underlying stories don't.
What I'm experimenting with instead is asking a few more questions of every meaningful roadmap item:
Who gets what, and by when?
Why does it matter commercially? Not everything needs an ARR number. Defending revenue, reducing cost, managing risk and improving reliability all count.
How certain are we? Is this still a concept, something we've validated, or something we've actually committed to?
And what needs to be true for us to deliver it?
The customer-facing version can still be simpler. But it should be a view of the same thinking, not a separate story created afterwards.
The bit I've been thinking about
What struck me afterwards was that most of the commercial rationale already existed.
It was in the conversations. The planning. The context people carried around in their heads.
We knew why.
We just hadn't written the why next to the what.
Maybe that's partly a roadmap problem and partly a product maturity problem.
A better format won't magically create better product thinking. But the questions we put into our artefacts do shape the conversations around them.
If a roadmap only asks what are we building and when?, perhaps we shouldn't be surprised when that's what everyone talks about.
I'm starting to think a useful roadmap should make it difficult to describe the work without also describing the change it creates.
For the customer and for the business.