One of our clients recently asked me to present to their team of platform-focused product managers. The goal was to provide an external perspective on how to approach product management (PM) when building and bringing platforms to market. Specifically, they wanted to hear my thoughts on what makes being a platform PM unique from being a product PM. I’ve written about this before so this blog post extends on some of those thoughts. Before we dig into the differences between platform and product PM, we need to define the difference between platforms and products. At Nuvalence, we like to tell our clients that digital products target consumers of applications whereas digital platforms target consumers and producers of applications.

The Developer Persona

Any platform PM must consider the third-party developer persona as a key constituent in their use case development. In some enterprises, “third party” developers might just be developers in other parts of the organization who you treat as external to the system. Superficially, you might conclude that “we need an API” and call it a day. However, every product needs an API in 2019 so a good platform PM must dig deeper.

• What type of tooling and experience will I provide to developers to make it easier to interact with my platform? Examples might include integration with popular public cloud services, templates for deployment, simulators, CI/CD and IDE integration, etc.

• How much do developers need to understand about how my platform works before they can begin interacting and extending it? Can they quickly learn it on their own? Am I sure the barrier to entry is sufficiently low?

• Is my team using and extending core abstractions in the same way that I expect third parties to do so? If not, how do I know it will work and work well?

In short, the developer experience is as important as the application consumer experience. In some cases, the consumer is the developer so the concerns converge.

Generalized Solutions from Specific Requirements

Platform PMs must constantly be thinking about a generalized framework to support specific business requirements. Specific business requirements should become test cases for platform features as opposed to being platform features themselves. This is best illustrated with an example.

When I ran Product for an enterprise platform startup, we had a large enterprise client ask us for the ability to inject a CA Wiley monitoring agent into an application’s runtime upon deployment to our platform. This was in order to comply with their corporate monitoring policies. We decomposed this into a more general platform capability that became very popular and used by nearly all of our customers.

Here’s how we approached it:

1. We didn’t want to tie ourselves to CA Wiley so we made the actual agent payload configurable. I know. You don’t need to be a genius to figure out that hard coding an agent config is bad.

2. We didn’t want to limit ourselves to just agents so we enabled the injection of any type of transformation to the application payload. We called these transformations “bootstrappers”. Since this could potentially be a major security attack vector, we implemented a set of constraints and controls to mitigate this.

3. In the event that application deployments started failing due to poorly written bootstrappers, we defined an interface that all bootstrappers had to implement. This standard interface simplified diagnostics, versioning, and troubleshooting among other things.

4. We had to actually make this usable without writing a JSON novel. As a result, we implemented an API and GUI allowing platform users to register bootstrappers, determine the conditions upon which they should be applied and test them out directly in the GUI. There is always a tradeoff between complexity and flexibility so I can’t stress how important this step is. Too many platforms stop at step 3 and if you’re lucky, leave you some terse documentation.

5. It occurred to us that although this feature was initially intended to enforce a policy, bootstrappers could actually be used to optionally add capabilities to applications. As a result, we implemented a flagging system where application owners could “request” specific bootstrappers be applied to their applications. Examples included vulnerability scans, transformations that reconfigured apps for different operating environments, etc.

Once implemented, we saw our customers use this capability in powerful ways that we had not originally envisioned. One used a bootstrapper to scan an application config for personally identifiable information and took appropriate remediation action as a result. Drawing a straight line between this use case and our original goal of injecting a monitoring agent doesn’t seem obvious, does it? A good platform PM team does exactly this kind of work. This feature also enabled us to work with third parties to bundle their software with our platform and provide our joint customers with a turnkey solution.

I wouldn’t categorize being a platform PM as being easier or harder than being a product PM but it certainly is different.

Would love to hear your thoughts and experiences as well!

Rakesh