A Platform is a Product "in Process"; it's the Impact that Sets It Apart
It matters to you that you build your platform as a product; it matters to your users that it is a product and can be adopted like one
A bank pours millions into building its “Next-Gen Platform.” The project plan is immaculate—Gantt charts, steering committees, and a roadmap that looks like a train timetable. They obsess over JIRA burndown rates and “feature completeness.” Two years later, they launch. It’s polished. It ticks every box.
Nobody uses it.
Developers find it clunky. Customers see no new possibilities. The CPO and Product Management Committee pat themselves on the back for “delivering on time,” but the platform is dead on arrival.
Why? Because they built for process, not for impact. They forgot that platforms live or die by the lives they change, not the milestones they meet.
A Platform is a Product, and a Product is Impact
A platform is not a fling. It’s a marriage. A long haul. A road trip with no map and questionable snacks, but with the promise of something extraordinary if you stick with it.
A product, not a project.
Too many treat platforms like projects—temporary, box-ticking, neat endings. But a real platform has no ending. It’s alive. It breathes through every developer who uses it and every product it makes possible.
Think of it like one of Stephen Hawking’s1 light cones:
(Image from “A Brief History of Time” by Stephen Hawking, illustrated edition)
Tech stacks build up quietly, invisible to most. Then—bang—there’s an inflection point. A platform is possible, or even simply emerges. The cone splits around that event.
Stretching out from the event are neat, anticipated impacts: faster builds, cheaper hosting, smoother releases. Outside that, broadening the cone unexpectedly, the wild, unanticipated impacts: whole industries shift, new companies bloom, economies tilt. Nobody in 2007 thought the iPhone would spawn entire rideshare economies, dating markets, or armies of mobile app millionaires. Cloud wasn’t just cheaper servers—it was the soil for AI, global collaboration, and startups that run the world from a laptop in a café.
That’s the hallmark of a platform: it doesn’t just solve problems. It changes what problems exist.
To get there, you don’t just “ship a product.” You curate. You synthesise the newest evolutions of technology, prune the noise, and serve something stable, elegant, and empowering.
You have to think like a chef—not a fast-food line cook. Taste the ingredients. Discard what’s rotten. Fuse flavours no one expects, but everyone remembers. Wardley mapping helps you see which tools are commodities, which are ripe for curation, gaps for invention, and where the next inflection point may lie.
And the punchline? The process—the product management, the roadmaps, the rituals—is just scaffolding. The thing that matters is the impact. The cone that widens. The world that looks different because of what you built.
You won’t control the impact. You can only prepare the soil. The greatest platforms are remembered not for the process, but for the surprising ways they lifted everyone else higher.
That’s the gig. That’s the impact.
Aphorism
A platform is a product in process, but it’s the impact that sets it apart.
Practices
Treat your platform as a long-lived product, not a finite project.
Regularly synthesise emerging technologies into curated, stable offerings.
Use Wardley Mapping to spot inflection points and evolution trends.
All products are change, An internal developer platform is a change to the software development and delivery Habitat. You will need to plan to communicate and market your platform to your, internal, masses.
Engage users not just as customers but as co-creators of impact.
Measure success by the downstream effects your platform enables, not just adoption metrics.
Things to avoid
Treating a platform like a short-term project or cost center.
Pretending you are the expert in user needs. Go see what it is like to try and use your platform. Explore and learn from your users with empathy and kindness.
Over-engineering process while under-delivering impact.
Ignoring unexpected use cases instead of embracing them.
Confusing “shipping features” with “creating impact.”
Checklist
Have we committed to long-term stewardship and investment?
Do we curate, not just accumulate, technologies?
Do we measure user creativity and enablement, not just throughput?
Are we prepared for unexpected uses of our platform?
Is our vision impact-driven, not process-driven?
Some Examples
Cloud computing: Began as cheaper hosting, became the substrate for global collaboration, AI, and trillion-dollar companies.
iPhone ecosystem: Anticipated mobile browsing; unanticipated impacts included entire industries (apps, rideshare, mobile payments).
Open-source platforms: Started as volunteer projects, became the backbone of modern software, powering everything from Kubernetes to Linux.
Further Reading
- Stephen Hawking, A Brief History of Time (for light cones and inevitability of expansion).
- Dan and Chip Heath, Switch (on change)
- Simon Wardley, Wardley Mapping (for technology evolution and platform strategy).
- Benedict Evans, essays on mobile and platform impact.
- Clayton Christensen, The Innovator’s Dilemma (on disruption and unexpected impact).
A platform is a product, yes. But it is a product in motion—an evolving process of curation, synthesis, and long-term stewardship. What makes it great is not how it was built, but how it changes the lives, creativity, and possibilities of those who use it. Measure impact, not rituals.
A platform is never “finished”—its worth is measured not by its process, but by the anticipated and unanticipated impact it unleashes.
Focus less on perfect roadmaps, more on curating evolving technologies into something that amplifies others’ impact far beyond your intentions.
Projects end. Platforms endure. They are investments that outlive individual releases and shift the world in ways their creators can’t predict. Their true measure is not process efficiency but the expanding cone of impact they create.
If you enjoyed this article in the Software Engineering Enchiridion series you might also enjoy:
Correction: Light cones predate Hawking by some way. It's been a standard way to talk about and teach special relativity since its early days. It comes from Hermann Minkowski's formulation of Einstein's theory. Einstein's theory was 1905 and Minkowski's work was 1907–8.
A big thank you to my good friend Kevlin Henney for the correction!
A little correction from my wonderful friend, Kevlin:
"Now, I don't want to be that guy, but I'm going to be that guy: you attributed the light cone to Stephen Hawking, but it predates Hawking by some way. It's been a standard way to talk about and teach special relativity since its early days. It comes from Hermann Minkowski's formulation of Einstein's theory. Einstein's theory was 1905 and Minkowski's work was 1907–8."
How absolutely wonderful. It's insights like that that I love.
Keep being 'that guy' my friend!!