Sinclair recently wrote a post on why ambitious digital strategies have platforms as the end game. In working with clients, a question that often comes up is “should we build an app and turn it into a platform or should we build the platform first?”

There is no clear right or wrong answer and it is often situationally dependent. You can have success by building an app in a platform-aware way so that later, a platform can be extracted from the app and then be extended and enhanced by first and third parties. You can also have success in building a platform that initially caters to a single or small group of tenant applications. One thing is for certain, however, if you build a platform without at least one specific highly demanding tenant application or workload, your chance of success is close to zero. In this context, “highly demanding” means that the application exercises a broad set of platform features and has performance and scale requirements meeting or exceeding those of future platform applications.

Great Platforms have Killer Apps

During the desktop glory years, Microsoft always released Office and the Windows client together, largely for business reasons. It was pointless to ship a new version of Windows if Office didn’t run great on top of it. Office was also normally the first desktop application to exercise new platform features delivered within the Windows platform. It’s how the Windows team knew that their new platform features actually worked and worked well. They could also be sure that if they worked for Office and its tens of millions of users, third-party developers would probably be happy too.

Similarly, while Google and Amazon have come to be known as platforms, they both came to market with specific applications of those platforms (search and book store) before opening them up for progressively more general-purpose use such as Amazon Web Services. There are countless other examples both within and outside of the technology industry. This Seems Obvious, What’s the Catch?

Having an anchor tenant application for your platform usually means making compromises from a business, technical and political perspective within your organization because your primary initial goal is to make your first customer a huge success. You’ll have to find ways to make features that seem very specific to this customer more broadly applicable. Tough as that may be, it’s surprising how many organizations begin building a platform (without an anchor tenant application) simply for the sake of having one. They figure that by providing useful abstractions, shared services, and operational cost savings, lines of business would be crazy not to take advantage and they expect their platform to be a runaway success. What usually happens though, is an impedance mismatch between the application expectations and platform requirements and capabilities. It’s really hard, if not impossible to get the requirements and implementation of a platform correct without an actual customer guiding the decisions. Forcing application teams to use your platform “because you built it” is a poor way to do platform product management and any success you might see is likely fleeting.

Having a platform tethered closely to an initial highly demanding application creates several advantages:

1. It ensures that your platform actually works

2. It ensures that your platform is delivering the intended benefits to application developers

3. It gives you a customer on day 1

4. Helps ignite an ecosystem around your platform (especially if your first application has lots of data)

In a future post, we’ll explore the approach of turning an application into a platform and how to design for that upfront.

Rakesh Malhotra