Ben Linders makes a point that sounds obvious but cuts to the core of how we think about technology: having a platform is not the same as having a product people actually use. The distinction matters because so many teams mistake internal delivery for external value. You can ship a capability, tick the box, and call it done. But if no one outside your immediate circle can understand it, trust it, or adopt it without friction, you have not built a product. You have built a project that happens to be running in production. Linders pushes us to ask two questions instead: "Is this being used?" and "Does it reduce friction for users?" Those questions reframe the entire job from delivering features to enabling outcomes. It is a shift from counting outputs to measuring adoption, and it is long overdue.
This framing connects directly to the broader challenge of making complex systems approachable, whether you are deploying computer vision models optimized for mobile devices or migrating a content platform to a new CMS. In both cases, the underlying technology is only half the story. The other half is whether the people interacting with it can do so without a PhD in the internals. Linders is not saying platforms are irrelevant. He is saying they are table stakes. The real differentiator is whether the platform has been shaped around the user's actual workflow, not the developer's convenience. That is a humbling thought for anyone who has ever been proud of a well-architected system that no one outside the team can operate.
What we find most useful here is the emphasis on "reliably used by others." That word, reliably, does a lot of work. It means the user can count on the system not just once, but consistently, under real conditions, without constant hand-holding from the platform team. It also implies a level of self-service that many internal platforms lack. If your users need to file a ticket every time they want to do something slightly new, you have not built a product. You have built a bottleneck with an API. The question "Does it reduce friction?" is a sharp diagnostic tool because it forces you to look at the experience from the outside in. It is not about whether the code is elegant or the architecture is clean. It is about whether the person on the other end feels more capable, not more constrained.
Our take is that Linders is pointing at something deeper than a checklist item. He is describing a cultural shift from a delivery mindset to a value mindset. That shift is hard because it requires humility. It means admitting that your technical preferences are secondary to user outcomes, and that a "done" capability you cannot point to in active use is not done at all. If you are a leader reading this, the practical move is to change your definition of done. Stop asking your team when a feature will ship. Start asking who is using it and what they were able to do differently because it exists. You can also look at how teams like the ones behind AI-designed hardware explorations are pushing the boundaries of what is possible, but the principle holds: the value is in the adoption, not the announcement. The concrete point to watch is whether your next retrospective focuses on what was built or on what changed for the user. If it is still the former, you have not finished the job.