Yesterday's article ended on a warning: a platform team that builds what's technically interesting instead of what's actually needed produces a beautifully engineered failure. Today's article is about the specific habit of mind that causes it. It's the difference between treating a platform as a project — something with a start date, an end date, and a "done" — and treating it as a product — something with users, a value proposition, and a lifecycle that never actually finishes.
Projects get delivered. Products get adopted, and adoption is earned continuously, not granted once at launch.
The project mindset, and how it fails quietly
A platform built as a project looks something like this: a team scopes "the developer platform," builds it for a year, ships v1.0, and moves on to the next initiative. The signals that this is happening are recognizable in hindsight, and painfully expensive to notice in the moment:
- One-time build — treated as complete once it ships, with no plan for what comes after.
- Built for the team, not the users — designed around what the platform team found clean to build, not what developers actually needed.
- Success measured as "delivered," not "used" — the retro asks "did we ship it," never "is anyone touching it."
- No real user research — nobody interviewed the developers it was supposedly built for.
- Feedback ignored — early complaints get logged and never revisited.
- Stale within a year — the platform doesn't evolve, teams quietly build workarounds, and eventually just route around it entirely.
Warning
"We built it. Why aren't people using it?" is the signature sentence of a platform run as a project. It's usually asked in genuine confusion, and it's usually answerable: nobody asked the users what they needed before building it, and nobody's tracked whether it's solving their actual problem since.
The product mindset, side by side
| Platform as a project | Platform as a product |
|---|---|
| One-time build | Continuous discovery |
| Built for the team | Built for developers (real users) |
| Success = delivered | Success = adoption and value |
| No real users consulted | User feedback actively drives the roadmap |
| Feedback ignored | Iterate, improve, evolve |
| Becomes outdated quickly | Owned, maintained, and loved |
The "owned, maintained, and loved" framing isn't a soft aspiration — it's the actual bar. A product team that shipped a feature nobody used would treat that as a real signal to investigate, not a footnote. A platform team should hold itself to the same standard: low adoption isn't proof developers "just need to get used to it," it's usually proof the platform isn't solving their actual problem yet.
What product thinking looks like in practice
Discover → talk to developers, understand their actual friction
Build → the smallest thing that removes that specific friction
Measure → is it being used? Is it actually faster than the workaround?
Iterate → fix what's not working, expand what is
Repeat → this loop never closes — the platform's lifecycle continuesThat loop is identical in shape to how a good product team builds a customer-facing feature. The only thing that changed is who the user is — instead of an external customer, it's the developer on another team trying to ship a service by Friday.
What real-world adoption looks like
Backstage, Spotify's open-sourced developer portal, is the reference example precisely because Spotify treated it as a product from the start — continuously informed by what their own engineers needed, not delivered once and left alone. It's now used by thousands of engineers internally and adopted well beyond Spotify, and that trajectory doesn't happen to a project. It happens to a product with a team that kept listening.
Why this matters more as the platform grows
A platform with ten users tolerates rough edges — everyone using it can just ask the platform team directly when something's confusing. A platform with a thousand users can't run on tribal knowledge and personal relationships; it needs the same discipline any product at that scale needs: documented value propositions, tracked adoption metrics, a roadmap driven by what users report rather than what's interesting to build next. Skipping that discipline early doesn't cause problems while the platform is small. It causes them exactly when the platform is too embedded to easily replace, and too under-adopted to justify the investment already made in it.
Tomorrow's article looks at the outcome all of this product thinking is actually in service of: developer experience — the thing users of this particular product feel every time they build, test, deploy, or operate anything on top of what the platform team ships.
