TBM 48/53: One Roadmap
(Know someone excited about product, design, and education? My team — the product education team at Amplitude — is hiring learning experience designers. I’d be grateful if you could pass along a link to the job description).
Resist the temptation to divide "customer facing" and "non-customer facing" work. Use a single roadmap.
Why?
You risk creating a hierarchy that devalues important work. On one hand you have the shiny new stuff. People love new stuff. It goes on slides 1-5 to coincide with the coffee kicking in. The product manager is in full pitch mode. Nods. Insightful questions.
And then you have the nitty gritty, hard to describe, "necessary evil" type work (infra work, tooling, etc). That goes near the end of the presentation, at which point the execs are checking their phones.
The embattled engineering-lead-turned-accidental-product-manager does their best, but people have checked out. Worst case, a soft commitment turns into a "can we make progress with half the engineers?" Or an "UGH REALLY, we've been talking about data pipelines and design systems for five years now!"
The irony? The infra work may be the most important thing the company can do to unlock flow, and value creation. Imagine an org doubling or tripling the time it takes to get feedback, or deliver even. Very Important! But no one knows that because it goes on a black box "technical roadmap". The executives have never seen how the sausage is made. It always plays second fiddle out of sight (until something goes very wrong, at which point it becomes a BIG SURPRISE).
To complicate things further, the folks doing less visible work often don't have the chops to make a strong business case. So when it comes time to "present roadmaps", there's a tendency to de-prioritize talking about these efforts. I've had engineering leaders tell me they prefer keeping their plans on the down-low. "Better to go a bit slower without getting a million questions..."
Which all contributes to devaluing the less shiny work more and more, and maintaining shadow roadmaps. And going slower. Which in turns makes it even HARDER to prioritize the work the enables the work. Which causes debt to pile up. Which cases things to explode, and trust to deteriorate.
This is unsustainable and undesirable.
Product leaders should encourage their engineering counterparts to share the roadmap. Treat these things as apples-to-apples. It is all work, so it is should be presented as such. Coach the accidental product managers. Teach them how to make a strong business case, even if it means prioritizing that work ahead of your pet efforts. I’ll always remember an engineering lead ace a presentation to the whole company about something generally seen as “unsexy”. No they didn’t make it sexy, but they explained how incredibly important it was to enable future progress.
So…as a healthy forcing function…try to keep it all on one roadmap. Simply visualizing it in one place can go a long way.