One of the things that our clients often struggle with is scoping and framing what their “platform” should actually be. Organizations with pre-existing investments are tempted to take their existing technology portfolio and simply rebrand it as “The <companyX> Platform”. This is an alluring shortcut to entering the platform market but it’s rarely the right path to take. It results in a wildly inconsistent user experience which erodes trust. If people can’t trust your platform, nothing else matters.

Fundamentally, this is a product management exercise, and platform product management is a unique beast. PMs can’t simply collect the top use cases and stage them into an agile board for delivery. Almost by definition, platforms are meant to provide use case flexibility. On the other hand, the “let’s build all of the Lego bricks” approach almost always leaves users swimming in complexity. Some of you will recognize this tension in the “opinionated vs un-opinionated” debate in software engineering circles.

Entire books could be written on this topic but here I want to highlight two key decisions that platform product managers should make as they define their offerings. I’ll spare you the PM 101 part of the exercise of “who is your customer?” and “what are your business goals?” which are obvious precursors.

Platform Interaction Model

Do platform users interact with your platform only through APIs that you expose or does your platform actually “host” code for users and execute on their behalf?

This is a critical question to answer because it dictates the types of functionality that can be offered and also the architecture that needs to be designed. Executing code on a user’s behalf generally requires a very narrowly scoped set of use cases and interface definitions. This helps preserve a consistent and more secure user experience. While more constrained, this type of interaction model can enable more tightly integrated use cases. It also allows the platform to take more responsibility for runtime aspects of execution (i.e. state management, scaling, diagnostics) versus an API-only interaction model.

SaaS billing and subscription management platforms serve as a good example here. These platforms allow users to reuse and customize web forms that the billing platform hosts on their behalf. If you’re a website, you simply redirect customers to the web form hosted by the billing platform to sign up customers and get access to your offerings. In return, the billing platform ensures PCI compliance and users don’t need to manage credit card numbers or other personally identifiable information directly. These billing platforms also provide APIs as an interaction model allowing you to bypass using their pre-built and hosted forms. This is more flexible but also transfers risk and ownership of data management back to the website clients of the billing platform.

Customization Boundaries

Can users extend the platform by adding to existing capabilities or can they replace existing capabilities? 

This is particularly relevant for applications that have been converted into platforms through APIs. Enabling users to extend functionality allows your platform to expand its use case reach and change what it can do over time. Enabling users to supplant platform functionality changes how the platform actually works.  Allowing users to change how the platform works requires an entirely different level of architectural rigor. It means that your platform components can never be dependent on how other components work. While one might argue that this is an important design consideration regardless, it’s rarely strictly enforced unless absolutely required.

A good illustration of this decision point can be found in most platform authentication systems. Adding steps to an existing authentication process (i.e. multi-factor) versus enabling a complete customization of the actual authentication scheme (i.e. enterprise single-sign-on integration).

As another example, let’s assume you are building a platform to manage IoT devices. As a PM, you’ll need to decide if you want the platform to have the ability to manage new types of devices and/or change how those devices are actually managed.

At each of these decision points and the countless others that platform PMs are faced with, the temptation will always be to go with “both”.  Sometimes this is truly the only right answer but in my experience, it’s rarely the right answer on day 1. This is where knowing your customer and business goals, and having a little courage as a PM come into play. Optionality always has a cost and that cost normally comes in the form of complexity. Always be aware of this trade-off.

We’ll cover other key platform decision points in future blog posts.