Leading product decisions inside a large organisation is really, really hard. In a regulated industry, harder still.
But not for the reasons you might expect.
Here’s the part that took me a while to see. The people at the top want simplicity. They genuinely do. They preach it, and they push hundreds — sometimes thousands — of people to chase it. Remove the things we don’t need. Declutter. Think about only what’s absolutely necessary.
All laudable stuff.
And the people on the front line want precisely the same thing. The engineers, the customer service teams, the designers, the operational folk. They understand the essence of what’s required. They’ve understood it for ages.
So if the top wants simplicity and the front line wants simplicity, why is it so hard to come by?
The middle bit.
Between a leader setting a direction and something actually happening in the real world, there are layers of people whose whole job is to process that direction. There is a class of smart people working in that space whose currency is the roadmap.
I’m one of them.
First you need a vision
To get to a roadmap, you need a vision. And the vision is the hard bit.
That’s the part where you have to be bold enough to propose something the business will actually get behind. But not so outlandish that you end up on the rocks. There’s a narrow channel between those two and most of the skill is in finding it.
Roadmaps are also a dangerous thing to own.
Once you publish one, people quite reasonably want dates against it. And that is reasonable. Building and keeping teams burns through serious £££s, so the people paying want to know what they’re getting and when they can cash the cheque.
The trouble is that putting dates against things involves predicting the future. Which, however much we all agree to pretend otherwise, is impossible. (Basecamp are blunter about this than most.)
A strategy is a response to a challenge
Here’s what I think gets missed.
A strategy doesn’t appear out of thin air. At its core, it is a response to a challenge.
The challenge might be, “we’ve got decent market share but we’re not profitable enough”. Or it might be, “we’ve got a product people love but not enough of them use it often enough”. Those are completely different problems, and the strategy in response to each will be completely different too.
But whatever strategy you set, that is the thing that shakes out the roadmap. Not the other way round.
I’ve written before about picking the right problems to solve, and about checking each one against the strategy before you go anywhere near it. What that post quietly assumed was that a strategy existed to be checked against.
Take the first one. Not profitable enough. We can’t move on price, so we need to be more cost efficient. Which means we need to simplify, and prune the waste out of how we work.
Fine. Now go and get a few thousand people to rally round that idea as it lands on their particular team, in their particular department, with their particular targets.
A tough call.
Then there’s the lag
The other dimension in a large organisation is the lag between strategy and execution.
You see it most clearly in the teams out on the outer reaches of the business. By the time an idea makes its way out to the provinces, the central direction has changed, or evolved, or been watered down enough that those teams can’t see any benefit in it. So they let the wave wash over them and carry on doing what they’ve always done.
And honestly? Who could blame them.
Because the question they’re asking is a fair one: how many strategic pillars, pivots, refreshes, business themes and key mandates have come and gone, and been abandoned
to short-sightedly hit the scorecard, as the organisation watches Q4 hove into view?
Quite a few, is the answer.
Make your vision easy to use
So the real question for product leadership isn’t “what’s the strategy?”. It’s this:
How do I make my vision easy to use?
That’s an idea I’ve nicked from Luke Wroblewski, who writes about design principles needing to be specific enough that people can actually choose between options with them. “Make it easy to use” is a uselessly broad design principle. It is a surprisingly good test for a strategy.
Because humans go for the path of least resistance. All of them.
That goes for the teams producing the work. It goes for your peers, who have their own ideas that happen to depend on yours. And it goes for the leaders who need confidence that the business knows where it’s going.
So the roadmap needs to be easy to find. Easy to read. Easy to understand. And it needs to give whoever reads it some benefit that’s relevant to them, rather than to you.
Better still is a roadmap that draws automatically from the tools the business already uses, so it acts as a mirror — showing back what teams are really planning to do, rather than what everyone agreed to say they’d do.
And if you don’t like what you see in the mirror, well. At least now you can do something about it.
None of this is an argument for abolishing the roadmap. I’d be out of a job. It’s an argument for remembering which one is the tail and which one is the dog.