Product leaders reject a spec with no success metric. They ask for a feedback loop before build starts. They refuse to ship a feature nobody asked for. Then they go home, or into the next meeting, and run their own team, and their company, on a policy memo and an annual engagement survey: adoption enforced by request, not earned. Success measured by compliance, not by anyone choosing to use what was built. Treating your company as a product is not a new discipline. It is the one you already apply to every feature, pointed for the first time at the place you have never aimed it.
What platforms learned the hard way
Ten years ago, “platform as a product” was a slogan. Now it has evidence behind it. Team Topologies gave platform teams a vocabulary for it: treat the rest of the organisation as your customer, not your captive audience. The idea has since hardened into practice. A platform team needs a product owner and a roadmap, adoption earned rather than mandated, success measured by usage: the same discipline used to ship a customer-facing feature, aimed inward instead.
The evidence for taking that seriously is now concrete, not aspirational. Ninety per cent of organisations run an internal developer platform, and three-quarters have a dedicated platform team. Yet 2026’s platform engineering maturity data shows only 18.3 per cent reach what it calls participatory adoption: engineers pulling the platform toward them, not being pushed onto it. Just over a third still run on mandates, and mandate-driven adoption is getting less effective as the practice matures, not more.
That is not a platform-engineering trivia stat. It is a measurement of the exact distinction every product leader already claims to believe in: a mandate is not adoption. And it is failing in a domain stacked in its favour, where the customers are engineers who already believe in product thinking, on a team built by product people, using product vocabulary from day one. If mandate-driven adoption cannot clear that bar, it has no chance in the domain nobody has even tried to apply product discipline to: how your own team runs, and how your company runs.
The pull test
Here is the test, stated plainly: would you ship a feature with this little feedback and this much mandate? A quarterly OKR review is a roadmap review with no user research behind it. An all-hands is a release note nobody was consulted on. An annual engagement survey is a churn analysis run once a year, on a product people use daily. None of this would survive a product review. All of it survives, indefinitely, because nobody is applying the review.
John Cutler has argued a version of this: product leaders bring craft and curiosity to customer problems, but rarely to their own team or process. RICE scores and roadmaps are not hard to point at your own function. Nobody has been pointing them there, because nobody has had to.
I’ve made a version of this argument before: a scoring framework can survive being run a hundred times, but a tension nobody names rarely survives being asked about directly. The same pattern holds here. The scoring tools were available all along. Pointing them at your own team was always optional in a way pointing them at the backlog never was.
Company as product
The extension beyond the team is not a metaphor stretched too far. It already has practitioners. Jason Fried, co-founder and CEO of 37signals, said it plainly on Wisdom From The Top: “One of the things that we do differently is that we treat our company as a product.” Yuval Yeret has built a sustained body of writing on developing the company itself as a product: a roadmap instead of a strategy deck nobody reads twice, a feedback loop instead of a suggestion box, and adoption of the operating model as the metric that matters, not compliance with it.
That is not yet a movement with hard data behind it the way platform engineering now has. It is closer to a handful of practitioners taking their own medicine in public. Worth saying plainly, because overstating the consensus here would be the same mistake as pretending the mandate-versus-pull data covers ground it does not.
It is also the company-scale version of a point I’ve made before about doing the hands-on work yourself before telling anyone else how: you cannot mandate belief in a model you have not tested on your own team, or your own company, first.
Where the metaphor breaks
There is a real objection, and it deserves an answer rather than a wave of the hand. Alon Schwartz has argued that framing employees as customers reframes labour relations as a service relationship, one that can launder genuine structural problems (power, pay, authority) into UX-sounding friction solved with a better feedback loop instead of, say, an actual raise or an actual say.
He is right. The answer is precision about scope, not denial of the risk. Product discipline belongs to process, tooling, and how work actually flows: the operating model. It has no business anywhere near compensation, authority, or job security: those are governance questions, and a roadmap cannot answer them and should not be asked to try. A version of this argument that pretends the metaphor is costless is not more persuasive to a CPTO or CTO who has seen it misused. It is less credible. Say the limit out loud, and the rest of the argument gets to stand on its own.
What this actually asks of you
Stop asking how to get the team, or the company, to adopt the next change. Start asking whether you would ship a feature with this little feedback and this much mandate. If the answer is no, the fix is the same roadmap, the same feedback loop, and the same adoption metric you already trust for a feature: aimed at the operating model you run, with product thinking kept strictly away from pay, authority, and job security, because those were never the product’s job to fix.
You would never ship a feature nobody asked for, tested by no one, judged only by whether people complied. Why is that exactly how most companies run themselves?
Leave a Reply