Should a software business describe itself as a product or a platform? It sounds like a branding conversation. It isn't. The framing you choose sets off downstream consequences for team structure, architecture, roadmap, and how you sell. Get it wrong and the org quietly follows in the wrong direction.
When people say "platform," they usually mean one of three things, and the three are not interchangeable.
Option 01
One product with categories of features
A single integrated experience. Capability areas exist internally but the seams are invisible to the customer. The roadmap is optimised for the whole, not the parts.
Examples: Notion, Linear, Figma
Option 02
A platform of products
Multiple distinct products sharing data, infrastructure, and brand. Customers land on one and expand to others. Value grows with adoption across the suite. This is where most "platform" companies actually live.
Examples: Atlassian, HubSpot, Salesforce
Option 03
A true platform
Infrastructure that enables multiple participants (customers, developers, partners) to build and transact in ways the platform owner didn't prescribe. Value compounds externally. New products emerge that the platform team never designed.
Examples: Stripe, AWS, Twilio
Most companies claiming "platform" are in category two at best. That's not a criticism. A well-executed product suite is hard and valuable. But the gap between two and three isn't closed by a rebrand. It requires APIs as a product in their own right, developer experience investment, and ecosystem logic. That's a multi-year architectural commitment, not a positioning decision.
You'll know you have a true platform when participants build things on it that you didn't design and couldn't have predicted.
Conway's Law adds another dimension: organisations design systems that mirror their own communication structure, and the reverse is equally true. Call something "one product" and the org will consolidate around that. Call it a "platform of products" and teams will orient around domain ownership. The framing isn't neutral. It shapes the system that follows.
Which is why this decision should start with the customer, not the org chart. What do they experience as one thing? What are they actually buying: a single integrated outcome, or a suite of capabilities they can adopt over time? The answer to that question should determine the architecture. The architecture should inform the org. Not the other way around.