tl;dr — A product is a conceptual whole intended to serve a specific purpose. A platform is a set of independent-yet-interlocking tools which can be externally orchestrated to create products.

This post is in continuation to my redux of Steve Yegge’s blog post about platforms and builds on my thoughts and learnings from trying to convert Myntra’s supply chain technology to a more platformized avatar. Here I want to talk about how products and product thinking differ from platforms and platform thinking.

The logistics team at Myntra was recently discussing how to model master bags (big bag of individual shipments shipped as a single unit), and we initially came up with entities like “first mile master bag”, “last mile master bag” etc. They would each exist in different legs of transportation and would behave very differently (have different state machines etc). Only when the duplication of capabilities became very obvious did we start talking about the general concept of “master bag” which could be used by all logistics legs. The debate rages on today :), but new business requirements coming in of late are bearing out that intuition about a central, re-programmable entity which can cross domain boundaries and change behaviours as it does.

It is worth looking at that example (I often do) to understand why the final design wasn’t the first thing to spring to mind. There are two aspects to this. First, we didn’t start out to model master-bags per se. That conversation was a by-product of a new business requirement to use master bags in the last mile when they had so far only been used in the long haul stages. As such, we set out to solve a specific problems and a context neutral, behaviour-less entity didn’t make much sense in the discussion. After we agreed to build the central entity, the problem would still have to be solved using this new component. The requirement to build the product was blindsiding us from the beginning, taking us away from the platform.

The second aspect is the way the team thinks. We are the team that build products for logistics operations. Our design instincts are to encapsulate behaviour and data inside products which serve a well defined purpose. So we wanted to round up behaviours of a specific kind of master bag into one component, another kind of master bag into another. They should be different because they behave differently. The “master bag service”, as it is to become (development to start shortly) does not contain much logic of its own. Much of its complexity comes from the various hooks that had to be built in it so that specific logistics workflows and products could extend its basic domain and states. Beyond some very basic things, it does not impose any restrictions of its own. The entity has almost no behaviour of its own. All of this goes completely against the grain when you are used to thinking about well-defined, stand alone systems.

And so we come to the point of this little back-story.

A product is the final business offering — the end product that we hope to satisfy our customers with. It does not really matter to the customer how it is built, just that it should work delightfully. It is the castle made of Lego bricks — built to serve a specific purpose very efficiently.

A platform, on the other hand, is the set of Lego bricks itself- a variety of pieces that fit together in ever varying forms. That is what a well designed platform feels like. A set of tools which are all very different but work very well together. Just look at AWS. You may go there only for the compute, but it is so easy to start using RDS or SQS once there that it becomes very easy to get pulled into using it all.

This is why teams that are used to building products have a tough time switching to thinking in terms of platforms — a platform never feels like a complete, cohesive thing. It is too diffuse, and never seems to serve a final business purpose, and so they never really buy into it, at least not easily. They are not able to conceive of a widely different set of tools as all belonging to a single toolbox. I have found that a platform conversation is more accessible to developers if it is about a purely “technical” concept like authentication or rate limits or configuration management. Then design purity automatically pulls them towards designing an “identity platform” or some such.

However, when taking about business entities like items or payments, people find this definition of purpose much more difficult. This is because the business context starts playing a bigger role and they start looking for product boundaries which will serve the business purpose. A platform offers none of that at the outset, so it is unlikely that we will stumble upon it during the regular course of product engineering. It has to be conceived very deliberately, and pursued with the collective will of the organisation if it is to be built at all.

Read Next : Why build platform architecture?