Your data product roadmap is a doppio or two separate espressos?
There’s a ritual I never skip: in the morning a pour-over, ground fresh, and after lunch a double espresso that’s the exact caffeine dose to get through the afternoon without needing anything else. You have to agree with me, coffee for anyone working in tech is never too much.
(And in this piece I allowed myself to use the word espresso spelled with an “s” because it’s simply more elegant.)
But there’s a difference that seems small and changes everything. A doppio is two shots pulled together, in the same cup, with the same pressure and in the same time, while two separate espressos are obviously two independent extractions, each with its own pace, its own drinking window, its temperature and its bean origin. The final result might look identical to someone watching from the outside, but for whoever made it, the difference in preparation is enormous.
This reminds me of a problem that few people talk about clearly in the data product world: most data products live on top of a platform that also has its own roadmap, and these two roadmaps rarely get pulled together.
A data product has its own lifecycle that starts with a business purpose, moves through maturity phases, and evolves or gets replaced/versioned as context changes. It serves people, systems, and increasingly AI models, carrying with it dependencies on quality, readiness, and timeliness of the data that feeds it, along with security initiatives that need to be reassessed as requirements evolve.
The platform supporting that product also evolves, just at its own pace, faster or slower depending on context. Platform technologies like Databricks and Snowflake have frequent update cadences, with new integrations and deprecations that often don’t wait for the product to finish one before appearing. Native cloud services like Azure and AWS are even more agnostic: they evolve broadly, more convex and with more complex coupling, making them far less predictable, which makes joint planning even more challenging.
When these two cycles don’t talk to each other, the bill doesn’t land on the platform or on engineering: it lands on the data product, which is the one that fails to deliver the promised business value, generating frustration from the stakeholder who often doesn’t even understand that the blocker was one layer below what they could see.
When I was responsible for both roadmaps at the same time, the first sign of trouble wasn’t technical, it was prioritization. You either prioritize the platform because it enables the product and the product sits blocked waiting, or you prioritize the product and the platform becomes a debt that will charge interest at the worst possible moment, exactly when you need the most innovation, or to scale more defined initiatives with low FinOps impact. The criteria for both need to be in sync, even when the teams aren’t the same, because when they aren’t, the one who always pays is the final product.
And this is where the question that defines governance lives: are you drinking a doppio or two separate espressos?
The doppio demands that both roadmaps be managed in harmony from the start, with the same priority vision, the same delivery rhythm, and the same cup, which is harder to operate but produces a more cohesive result, even if slower. Two separate espressos is a bet on independence with coordination, where each roadmap has its own DPM, its own cadence and criteria, and the result can be equally good as long as communication between the two sides is impeccable and constant. Which one works depends on the size of the company, the maturity of the platform, and how many data products it serves at the same time, because a platform serving ten different contexts cannot be managed as an extension of any one of them.
What’s non-negotiable in any model is that the Data Product Manager needs to be involved in both worlds in some capacity, whether as a demand side, a related area, or through a formal alignment cadence that ensures mutual visibility. The DPM who doesn’t know what’s on the platform roadmap will be caught off guard and won’t think about innovation for their own context either. And in data products, surprises tend to have the same return address: the stakeholder who didn’t get what they expected, and one more product added to the list of things that didn’t make it.
How to consolidate the artifacts from both roadmaps
If you manage both roadmaps, build a unified visibility layer that doesn’t need to live in the same tool but needs to speak the same prioritization language, even if the roadmap language itself differs, with one being more technical and the other more business-oriented. Define shared criteria where what blocks the product blocks the platform and vice versa, and revisit those criteria with the platform team at every planning cycle.
If you manage only one of the two, invest in communication with the other side before the problem surfaces, making sure your requests are timed with enough lead time, because visibility is not optional when enabling teams are on the critical path of your product. In either case, document interdependencies not as a risk bullet at the end of a presentation, but as a roadmap item with an owner, a deadline, and explicit resolution criteria.
Doppio or two espressos, the choice depends on your context, but ignoring that a second extraction is happening in parallel is the most expensive way to find out the coffee went cold.
And let’s be honest, nobody deserves cold coffee, just like nobody deserves a data product that never got there.
My closing question: Do you manage both roadmaps within the same team, or is there a clear split in your organization? How does that separation affect your product’s velocity?