Whether you build a product or a platform is not a strategic choice you make in a planning meeting. It is a consequence of what your unit of value actually is. Finding the unit is the work. Everything else follows.
Product or platform? The question drives org design debates, roadmap trade-offs, headcount requests. It sounds like the right place to start. It is not. The choice between product and platform follows from something more fundamental, something most teams have not yet found when they start the debate.
That thing is the unit of value: the smallest piece of what you are building that is genuinely useful on its own, and that repeats across the problem space. Until you can name it precisely, the product-versus-platform debate is premature.
In the mid-1800s, chemists had accumulated enough observations of specific substances (sulfur, mercury, salt, phosphorus) that Mendeleev could see a pattern underneath them. The elements were always there. Carbon was carbon long before any chemist encountered it. What changed was that enough specific instances had been studied that the underlying unit became legible. The periodic table was not designed top-down. It was read off the accumulated evidence of specific materials.
Biology works differently. The protein structures that make life possible were not waiting to be discovered. They did not exist before evolution built them, one specific experiment at a time, across billions of generations. The immunoglobulin fold, a structural unit that appears in antibodies, cell adhesion molecules, and immune signaling, emerged through iteration. Evolution did not design it. It accumulated it through relentless contact with specific problems.
In chemistry, the unit is discovered through accumulation of observations. In biology, the unit is innovated through accumulation of experiments. Both require the same prerequisite: you cannot see the unit from a whiteboard. You have to encounter it.
A few years ago I was building a product for sales, support, and customer success teams. The surface problem looked different across each group. Sales wanted to know which accounts to prioritize. Support wanted to know which customers were at risk. Customer success wanted to know which relationships needed attention before renewal. Three teams, three different framings, three different dashboards already in the room.
We built specific things for each group and kept looking for what was actually the same across them. What we eventually found was not a data model or a reporting structure. It was a decision type. Every one of these users, regardless of function, needed to answer the same question: what is the single most valuable action I can take right now, given everything I know about this account? The dashboards and insights tools already in the room were all circling this question without answering it. They gave users information. They did not give them a next move.
We did not start by building a sophisticated AI system. We started with one business unit, one sales persona, and a small set of hard-coded rules that approximated what the next best action might look like. No model. No generalization. Just enough to put something in front of real users and learn whether the unit (the decision, not the data) was actually what they needed. It was. Once that was clear, the product design followed: collect signals across all available data, run a model, surface a concrete action. The assembly happens inside the product. The user receives the output intact. That is a product unit.
Not all units work that way. I have also built infrastructure for data teams where the unit looked entirely different. The core capability was storing, processing, and serving data reliably at scale. That capability was genuine and reusable. It also could not be delivered directly to an end user, because end users do not want infrastructure. They want outcomes, and outcomes vary so dramatically across teams and use cases that no single experience could contain them.
What those teams needed was the capability itself, delivered through APIs, so they could build their own logic on top of it. Data analysis, visualization, inspection, manipulation: each team had different business rules and different definitions of a useful output. The unit was the same (reliable access to data operations) but it required downstream assembly before it became useful to any specific user. That is a platform unit.
The distinction between these two is what determines the delivery form.
| Product unit | Platform unit |
|---|---|
| Travels to the user intact Assembly happens inside the product. The user receives the output (a next action, a recommendation, a decision) without needing to work with the underlying components. | Requires downstream assembly The unit is a primitive: a capability, an API, a data operation. Builders combine it with their own logic before it reaches a user. |
| Consistent experience across users Different users, same interface. Variation is handled inside the system, not by the user. | Varied experiences from the same unit Different builders produce different user experiences from the same underlying capability. |
| Example Next best action surfaced to a salesperson. The signals, model, and ranking are invisible. The user sees a concrete recommendation. | Example Data infrastructure APIs. One team builds a visualization tool. Another builds an analysis agent. The unit is the same. The experiences are not. |
The strategic choice between product and platform is not prior to this distinction. It follows from it. Build a platform when your unit requires assembly to be useful. Build a product when it does not.
In 2012 I co-founded a company built around a real problem: enterprises were drowning in their own information. Employee-generated content (emails, documents, conversations, support tickets, sales notes) contained enormous institutional knowledge that was effectively inaccessible. People recreated work that had already been done. The information existed. Nobody could get to it.
We spent five years building specific things and looking for the unit. We found real components: data integrations that could pull from dozens of enterprise systems, access control logic that could enforce permissions across sources, end-user surfaces in the tools where employees already worked. What we could not find was a clean separation between the language layer and the context layer. How do you take a user's question, understand what they actually need, retrieve the right organizational knowledge, and return something genuinely useful rather than a list of documents? That question is now called retrieval-augmented generation. It has a name and a toolkit and a generation of companies building on top of it. In 2015, none of that existed.
The unit we needed required a technological precondition (transformer-scale language models) that would not arrive until years after our runway ran out. A class of companies is now building what we built, with that missing piece available off the shelf, and the timing is dramatically in their favor. The problem is the same. The externality resolved.
This is a failure mode that does not appear in most post-mortems: not that you searched poorly, but that the unit you were converging on depended on something outside your control that had not happened yet. You can find every other component and still not be able to complete the picture. The search was sound. The precondition was absent.
If finding the unit requires accumulating specific observations, the sequence of how you build is not a choice either. You have to start specific. Not because starting small is virtuous, but because specific things are the only raw material from which the unit eventually becomes legible.
In food delivery, early market experiments ran at the level of a single zip code, testing specific item categories to understand what demand actually looked like before generalizing. In the sales product above, the first version covered one business unit, one sales persona, and a handful of hard-coded rules. Not to be cautious, but because that scope was the minimum needed to learn whether the unit was real. Neither of those starting points looked like a platform or even a product. They looked like solutions. That was the point.
Solutions become products when the unit repeats across enough customers that a consistent experience can be built around it. Products become platforms when the unit turns out to require downstream assembly. When what you have built is more useful as infrastructure than as a finished experience, that is the signal. Each transition follows from what you have learned, not from a plan made upfront.
Building a platform before you can name the unit is building the periodic table before you have encountered any elements. You will produce an architecture. Whether the primitives are the ones people actually need is a question that only specific observations can answer, and those observations come from building things narrow enough to actually learn from.
Before the next product or platform investment: can you name the unit? Not the customer problem, not the product vision. The unit. The thing that is genuinely useful on its own and repeats across the problem space. If you can name it in a single precise sentence, you have enough to make the next decision. If you cannot, more specific observations come first.
The unit is not designed. It is found. Everything else depends on that.