The Platform Mindset

A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it. Then it’s a platform. – Bill Gates

There are moments when a product or company hits a size where they decide to create a platform that current and future products are built upon. The exercise that follows segments the organization, one focusing on the “product” and the other on the “platform.” The platform consists of commodity or non-revenue-generating features.

This is a perfectly fine place to start. The product always continued, though. Its feature needs continue to grow, making higher demands than the platform has the capacity for creating a challenging environment to thrive. The team starts to feel like they are running on a treadmill. It needs to be clearer what the team should work on and what they shouldn’t. Reputation starts being challenged – team is too slow, too rigid, they don’t understand our product.

How to operate is an afterthought to who is part of what team and what capabilities belong where. There is a mindset to platform building that the team needs to adopt.

Know the Customer. Something strange happens when you split a product and platform team. A virtual wall is put in place barring you from access you had in the past. You’re not part of the strategic product decisions. You’re no longer part of the day-to-day chatter of what’s working well and what isn’t. None of this is malicious, and the organizational processes often reinforce the team-focus behavior. You’ll need to work harder on establishing the relationship again. Regular syncs to understand the goals and real jobs to be done. As platform requests, the former will be framed as solutions, not problems to be solved. Taking them at face value will result in success in delivering what was asked, but not necessarily the desired outcome and overall company leverage.

A Rubric for Leverage. The value of a platform is the leverage it provides to its users. The easy trap to fall into is taking on useful problems that are not providing significant benefits. Have too many of those, and you start hearing feedback that the platform only helps a little. Picking fewer, more important problems to solve helps create (a) focus and (b) leverage where the user feels the benefit.

Create a rubric to guide the team on opportunity decision-making. Use something simple to spark discussion and require the team to think deeply before adding a new capability. It could be as simple as saying 10x value, empowers multiple products, and strategic advantage.

Let’s take an example where many products use geo-location to serve users personalized content. Is it 10x? Not really; a single developer can determine how to utilize browser or device APIs to capture good enough location information. Does it empower multiple products? Sure. Is it a strategic advantage? Heck no! Unless your business is mapping technology, you’re providing no strategic advantage.

One additional perspective to be careful of is to take the number of customers and use that as justification for a 10x value. Technically, this is true, but if a developer or two can achieve the true value, then any customer could decide to move off at any given time. Think about the 10x value as an impact on a single customer.

Flexibile, Composable, Interfaces. Think about some of the greatest platforms out there. Windows, Mac, iOS, Android, AWS, Azure and Google Cloud. There are an infinite number of products built on top of them. Each is unique in how they were made and the problems they solved. For each one of those products, the platform is no different. It provides interfaces in such a way that are flexible to other use cases, composable to be mashed up in novel ways. You will only be able to predict some of the use cases.

Grows with You. The problem a developer starts with may be different from what they need to solve as their product grows. Take a typical use case of authentication. Initially, all you want to achieve is authenticate a user and let them use the product. The developer integrates with account creation and authentication APIs. Great! Months later, they started adding multiplayer features into their products, where having displayable names, privacy controls, and sharing options are necessary. If the developer has to switch platforms to achieve this, you’ve lost them. They want to be able to use the capabilities they need now and add more over time as their needs evolve.

Mandates and Optional Use. In a perfect world, every product in your company uses the platform. Mandates are often given, leading to team friction because people feel forced to use something. The platform team starts to rely on mandates instead of the merit of their value, thus starting a slow degradation of overall quality.

While mandates can be taken advantage of to simplify decision-making and overall costs, platform teams should operate with the mentality that use is optional. This creates a forcing function for the team to prove value every day. Underappreciated aspects such as developer experience and workflows start to raise in importance to capture developers. A desire forms to solve the best problems and deliver on outcomes.

There might be common sense areas where mandates should be put in place. You want a company to refrain from inventing multiple identity platforms. Multiple ones will need to be clarified for your users. You want to use only one commerce payment platform. You want a united team focusing on integrating as many providers as possible, fighting fraud, and constantly trying to lower overall processing costs.

Prepare, Partner, Publish. The most important, last. As a platform, you need to constantly anticipate needs for products. Invest to position and prepare for new spaces. It takes time to create high-quality and scalable software. It was cloud infrastructure decades ago, it’s AI today, and who knows what it’ll be a decade from today.

Find one to two to partner with before going wide to many customers on a new capability. They benefit from having the platform deeply support their outcomes, and the platform team gains perspective on a good interface.

After those customers have been made successful, go wide and publish to more. You have the partnered customers as proof points and, best of all, advocates of the work. Developers in product teams tend to trust other product developers.