Thoughts? <
# product-management
Does that mean an IDP team shouldn't have a roadmap, or that the mere existence of one isn't a good proxy for being an effective platform as a product? I've been asked to put a roadmap together for my newly formed team that is leading the development of our IDP, so I'm also curious how import a fully formed roadmap is
a ignore what product managers tell you. You’re a startup not a mature product. Follow the startup guides not mature PM advice. This will be counter to the rest of the org most likely.
Most platform teams haven’t realized this, they think they are a mature product but if they were they would already have a roadmap, product thinking etc.
Also you are selling, dont mistake having a mandated monopoly as not having to sell. This is a huge mistake I have seen over and over
Also you are competing against the market if you do this right, you should be examine vendors and trends so you will need to have a compelling vision and need to at least be the market leader as defined by your org
I agree with what Andrew in the sentiment of keeping things simple, and acting to your maturity level. The screenshot is from the CNCF maturity model. A maturity model is not advice. I would say that most of the “platform as a product” is also not aimed at small companies (I’ll avoid “startup” as that term is more vague) and should be treated with some caution. Naturally, you should solve for the challenges you have today. If your definition of “roadmap” is simply having a plan for what you should do next, with a rough understanding of why, I’d say that’s useful for any team, regardless of whether they’re doing “platform as a product”.
That said, I’m disappointed that “make a roadmap” is about the sum-total of the advice that I see. That, and surveys. I feel we’re missing a lot of practical, in-the-trenches advice. Actually, to Andrews point of keeping is simple, there are some very cheap ways you can gather insights and feedback… which is exactly my point. I’d argue that most companies who are told to “_define a roadmap_” will spend weeks in the trap of arguing and debating random solutions “_Let’s migrate to vault!_“, “_Let’s use Kubernetes_!” etc, etc. But actually, depending on your maturity, a simple quick survey of the greatest pain points, or simply sitting next to your users for a couple hours could glean far more insights than getting round a table and defining a longer-term “roadmap”.
If I were tasked with creating a roadmap, I’d want to go back and ask some follow ups about what is the expected outcome of the roadmap exercise. Because “roadmap” is a loaded term, so it’d be important to understand what they are expecting from you… • Who would be the consumer of the roadmap? Who will view it? When? Why? What do they need to know? • Is the roadmap for clarity and alignment on what the team should build next? Or something else? • Will the roadmap need to justify investments for internal stakeholders? e.g. leadership? • Is the roadmap to understand ROI of the investments the platform team is making? • How much research is expected to go into deriving that roadmap? • Are timelines relevant? Estimates? This could indicate more of a delivery plan, than a roadmap.
Love this and very much agree with the idea that a roadmap is an artifact which only brings value with the practices of customer engagement. And Andrew said it well that a roadmap for an early stage product looks very different than one for a more mature/later stage product. I've come to describing platform engineering as the written necessary to evolve from the team topologies collaboration interaction model to the xaas model. Meaning, we as platform engineers are perpetually working in the merky area of discovery through to automation/consistent interfaces and then doing it all again. Therefore very much making it a more Pre PMF style team (at least for a long time).
If it's useful, the maturity model is now live and can be reviewed in full 🎉
Roadmaps are good, when you are clear about users needs and now can prioritize them. If you are in such a situation this is a comprehensive guide to Agile roadmaps (not feature roadmaps, but problem/value roadmaps or OKRs) If you are not clear what are the needs of users this is always a subject for discovery and validation first before committing to any roadmap-like artifacts. Look at this recording (which btw explains why classic roadmaps are not recommended) to see how to deal with uncertain ideas

But reality is always a blend: some of the stuff is clear or it's a mandate or regulation and does not require extensive discovery (it may require some) and other work that is not clear are requires discovery.


recommend reading blog by Marty Cagan on various PM aspects related to discovery and validation. Marty is not famous in Platform world, but he is in Product Management world and since we speak Platform as a product, everything he says applies to platform.