Platform Engineering 07 - Platform as a Product
The Mandate Trap
A common pattern emerges when a central team builds a new tool and leadership mandates organization-wide adoption. Developers comply on the surface, but they find workarounds for every part of the tool that does not work well. Six months later, the platform team is drowning in support tickets.
Having lived through this firsthand, the alternative is clear: treat the platform like a product and treat developers like customers.
Developers Are Customers
Viewing developers as "users who should be grateful" is the wrong framing. Developers are customers with choices. Even when the platform is the only official option, developers can always find workarounds. Shadow IT, reverting to manual processes, or simply ignoring the platform altogether โ all of these are available to them.
If the platform is genuinely good, developers will choose it voluntarily. That voluntary adoption is the standard by which a platform's success should be measured.
Product Practices
The first thing to do is talk to developers directly. This means actual conversations, not surveys. Observing how developers use the platform and identifying where they get stuck provides far more valuable insight than any questionnaire.
The pain points discovered through these conversations should drive roadmap prioritization. The ordering should follow the severity of problems developers actually experience, not what seems most technically elegant. Making the roadmap public builds trust with the developer community.
Issue reporting must be made trivially easy. A Slack channel, a simple form, office hours โ whatever provides the lowest barrier to entry. And the feedback loop must always be closed. When people report issues and hear nothing back, they stop reporting altogether.
The key is to ship in small increments, gather feedback, and iterate. Plans to disappear for six months and emerge with the perfect platform almost always end in failure.
The Voluntary Adoption Test
If developers were not required to use your platform, would they still choose it?
If the answer is no, that is a product problem, not a marketing problem. The product itself needs to be improved before investing in promotion.
Measuring Success
| Metric | What It Tells You |
|---|---|
| Adoption rate | Are teams choosing the platform? |
| Time to first deploy | Zero to production, how fast? |
| Support ticket volume | Intuitive or confusing? |
| Developer satisfaction | How do developers feel about it? |
| Lead time for changes | Actually speeding teams up? |
| Retention | Staying or migrating away? |
There is no need to measure everything at once. Selecting 3 to 4 metrics that are most relevant to the organization's current situation and focusing on those is the more effective approach.
Internal Marketing
Even the most well-built feature is meaningless if developers do not know it exists. The key is to announce where developers already are โ Slack, all-hands meetings, team syncs. Demonstrations should be kept to short sessions, and documentation should take the form of task-oriented guides. Most developers will not watch 60-minute webinar recordings or study complex architecture diagrams.
The Most Common Failure
The most common failure that platform teams encounter is building what they think developers need rather than what developers actually need. The pattern is familiar: the team identifies a problem from the infrastructure perspective, designs an elegant solution based on their own mental model, ships it, sees low adoption, and blames developers for not understanding the value.
To avoid this trap, the conversation with developers must happen before building, not after. A platform that nobody wants to use is nothing more than expensive infrastructure.
In the next post, we dive into CI/CD at scale.