Product Development Instincts Are Bad for Building Platforms

August 23, 2022, Last updated December 27, 2022

In my day job, I build a platform: that is, software that lets other people build things. The tools we build are used by people both inside and outside the company to make some pretty neat stuff.

Since we’re co-workers, though, the internal folks using our platform get the privilege of talking directly to me and my team on a regular basis. As a result, I deal with a lot of teams on that are in this kind of situation:

They have some product they want to build using our tech.
In order to build this product, they need some additional features from the platform.

The people that do this tend to be great product developers that know their intended audience well, and can build something really compelling. They have a keen sense of what they’re looking for, and are very talented.

But the trouble is, there’s a subtle but important mindset shift that’s needed when switching between product development and platform development.

What do both of these words mean?

Different people can have different definitions of “product” vs. “platform”, but here’s mine:

A product is a tool meant for end-users, which allows them to either create some artifact for use outside the product, or to engage in some kind of experience. To give some concrete examples:

Photo or video editing apps are products: they’re used to create standardized image and video files (the artifacts) which can then be taken outside the product and sent to friends, shared on social media, added to your memes folder, etc.
TV streaming apps, or most games, are also products: they let you spend a few hours of your time watching or doing something enjoyable.

A platform is a tool meant for creators or developers, which allows them to build products.

How is this different from a product “creating an artifact”?

In a product, the artifact later exists outside the platform it’s built on. You don’t need to open up your photo or video editing app to view the photos or videos you created with it.
In a platform, the thing you create strictly requires the platform in order to function.

As a concrete example: video games that provide map/level editors are arguably platforms, since you can’t take the map out of the game and expect it to make sense. This is doubly true for any video game that is dependent on online connectivity or is a “live service” game, where you now not only need the game, but also the online service that’s backing it.

And more obviously, anything that provides an API that a developer can call into from their own code is a platform. The web is the biggest example of that, being a platform that multiple companies develop clients for. (That is, web browsers.)

But note that platforms don’t strictly have to cater to software developers: any content creator that’s making content that’s not trivially portable to another system is arguably building on top of a platform.

How do you build a good product?

There are some commonly-accepted best practices you want to abide by if you’re building a product:

Ship broadly and be agile. You want to find product-market fit as soon as you can. You want to quickly discover if you’re going down the wrong path, and that means validating your ideas as soon as possible with as many people as will tolerate your minimum viable product (MVP).
Most mistakes can easily be corrected as long as you’re shipping fast, so don’t worry too much about them. Bugs can be fixed, bad UI can be redesigned, incorrect assumptions can be corrected.
Experiment and look at the data. Not sure whether a given UI should be one way or another? Do both, randomly assign users, and see which one works best! So long as you can afford the development time, this is a great strategy.
Control and polish the details in your design. After the MVP stage, you can add polish. Focus on exactly how your user flows will look like, how things should be positioned or animated, and tailor it for each of your target platforms. (E.g. users will probably expect different UI conventions on iOS vs. Android, macOS vs. Windows, etc.)
Don’t build a tool factory when all you need is a hammer. Don’t build huge supporting architectures that will slow down your MVP in order to support a small number of variations on a single feature.

How do you build a good platform?

In contrast, the things people usually want out of platforms are a bit different.

Prioritize stability. With enough users, any change in behaviour of your platform—even fixing a bug—will change how the things built on top of that platform function, usually for the worse.
Set expectations of backwards compatibility. The things people build on your platform will be 100% dependent on that platform in order to live. Set expectations with your creators for how long they can leave their creations before they need to be maintained or updated.
Be judicious about your API surface. Because of the requirements of backwards compatibility and stability, every feature you build into your platform brings with it major maintenance costs. Err on the side of not adding APIs that you don’t strictly need.
Build small, flexible, composable systems. If someone asks you for a feature, consider how you can provide it with the minimum amount of new APIs. The ideal case you’re aiming for is is zero, where they can build their intended feature by stringing together APIs you already provide.
Build systems that generalize. Build APIs that are applicable to a wide array of circumstances. Otherwise, every time someone wants a slight change in the way an API or feature functions, they have to go through you. Making things generalizable can sometimes (though not always!) mean more work, but it almost always gives you a better return on investment in the long run.
Make sure your platform works consistently everywhere. You don’t want the creations people make to work incorrectly on some devices, operating systems, etc. You can explicitly choose not to support some of them, but if you do choose to support them, they can’t be broken or inconsistent.

Product principles don’t work for platforms

The thing is, many of the best practices for building products are actually counterproductive to building platforms.

Agility trades off against stability. If you ship an unproven API or feature broadly and then realize you did it in a buggy or not-so-great way, you can’t simply retract or change it. People’s creations may be depending on your API to work the way it originally did. Changing it would make your platform unstable.
Mistakes may live forever. Because of the need for backwards compatibility, you can’t just change something that was a bad idea. You have to continue supporting it for at least as long as you originally promised. If you go back on that promise, you risk alienating your creator community.
Experiments need to be carefully controlled. If you open up a new API to half of creators on your platform randomly, that will lead to immense confusion to anyone working on a creation in a team, because your platform won’t be consistent across members of that team. If you want to experiment with a new API or feature, the better move would be to open it up to the entirety of a small team or group of teams, tell them about it, and then set expectations for how stable or backwards compatible they should expect this experimental API to be going forward.
Details are emergent. If you’re building a good platform by creating small, flexible, generalizable systems, you won’t be able to control and polish the details of products built on that platform to the same extent as you would if you were designing your own product. People might make things that aren’t to your standards of quality, and you won’t have much of a say in that.
Tool factories let creators make their own tools. Instead of saying “I want this icon to be ten pixels from the left margin”—which would require a huge API surface to support all minor variations—you’d be better off making a generalizable system allowing people to put any image at any position they want. Your creators can then build their own tools or libraries on top of that, enriching your platform even further.

From product to platform

Does that mean you have to throw away your product designs in favour of just focusing on low-level platform features?

Not necessarily. You can still keep your desired product feature in mind as a general guideline for what you’re working towards, and to help prioritize. But I’d strongly recommend doing the following:

Break your desired product feature down into small, composable parts.
- Picture: if you were a creator yourself, how would you build this? Work this out in detail.
Check whether the platform provides any of those parts already, and identify the ones you’re missing (if any).
- Start by leveraging any existing documentation the platform may have.
- If the documentation isn’t enough, and if, like my co-workers, you have the privilege of support from the engineers building the platform, check what support channels they have available for you. They should know the platform better than anyone.
  - Just make sure to give them enough context on your high-level goals so you don’t fall into the XY problem.
Consider whether any of those parts you’d have to add would be reusable to build other features for other products.
- If the answer is “no”—if it’s only solving your specific problem and no one else’s—this might not be worth the maintenance cost to add to the platform.
Consider alternate product features similar to what you’re trying to build. (Though the more different they are, the better.) Work through them in detail like you did with your original feature. Would any of these be buildable using the APIs or platform features you’re proposing?
- If the answer is “no”, you probably need to break things down further.
Have some flexibility in your product designs.
- A product that’s 80% of what you want, but that’s built entirely using flexible and composable platform features, is better than one that’s 100% aligned with your designs but that leaves the the platform full of cruft.
Ask yourself: what background assumptions about this feature am I making? Are any of these background assumptions subject to change?
- E.g.: What if your product priorities change and force you to rethink what you’re building? What if you discover you were wrong about what end users want? What if you decide to target different operating systems or hardware?
- Can you make sure that the platform feature you’re asking for still works flexibly and consistently in the face of that uncertainty?

This is a good chunk of what I personally do when I talk to partner teams in my day job. If everyone in those teams gets good enough at doing this, I can retire happy.