How to Identify Platform Opportunities

Developer Pains

Identifying common pains with a combination of anecdotal and analytical can give one good place.

However, just cataloging pains is not necessarily sufficient.

Sometimes the pains shared by developers has to do with their backgrounds (were they FAANG or mostly from start-ups) or their team (quality of onboarding). Pains are the smoke; it's just not always due to legitimate fires.

Before going into the details, it's good to get a high-level perspective:

• Has there been attrition because of the unproductivity?
• Has lack of a platform contributed to fire-drills, late on-calls, security issues?
• Is there a general sentiment around slow tempo for release?

Getting specific can help identify potentially low-hanging fruit to tackle before engaging more strategically.

What kinds of developer pains can be good signals?

• Time spent going through a wiki or other manual SOP:
• Time that the wiki or manual process results in errors, modifications, or in-person clarification:
• Cognitive overload for developer (non-think time) for given task unit (PR, deploy)
• Hand-off or wait-times
• Breakage or sluggish deployments because of dependencies

Slow Developer Onboarding

The time to productivity or whatever is a useful first atomic shippable unit for a new developer can be a good guiding north star to uncover problems.

Often, the developer onboarding stops at the issuance of the laptop and perhaps a link to the wiki, when there is often much more necessary to get a local development environment up and running to successfully shipping to production.

Although there's danger going overboard, this is a possible metric that can be automated to capture date of hire to time something is shipped into production. For smaller teams this can be done manually and is a great opportunity for the Product Manager to hear about the user experience.

Organizational Divergence

When teams are empowered to select their own tools, this initial autonomy accelerated execution in the beginning.

The difficulty is identifying at what point is divergence more a negative than a positive.

The divergence can cover different elements, from system design to the actual tools.

These can also be due to workloads. A team focusing on shipping Machine Learning capabilities may have a different set of processes, tools, and infrastructure from someone shipping the marketplace app.

While there are opportunities for overlaps, identifying where there is diverge is an opportunity to find the happy space between harmonizing the infrastructure or diversifying what is available for all teams but with an abstracted control plane.

As more teams proliferate, being able to balance their speed or uniqueness with a smaller infrastructure and tooling footprint is an opportunity for product management to make trade-offs and think creatively after understanding deeply the concerns and preferences.

Large Engineering with Scaling Future

When the engineering gets "large" (which is relative, but I try to define in a hand-wavy way shortly) AND there's a scaling future, that is a good direction for platform.

I don't know if there's a magic number. Because I suspect a big factor is the number of dependencies and processes.

A team could be "small" in size, but they are broken into lots of different teams which create dependencies among each other. Normally this happens when the engineering team scale. And despite working in "pizza teams" and micro-services, they still want to ensure they don't have to go through manual DevOps approval processes or painful on-call.

The platform's focus at this stage would not just be harmonizing, but overcoming bureaucracy and even be an accelerant.

Market Leverage

When there's an opportunity to apply leverage in market, a platform can be strategic and valuable.

In my article on Why Platform Product Managers Impact Valuations, I reference PayPal. Their TAM expands because they are able to add adjacent modules across the financial services lifecycle for their customers.

Being able to do so quickly and, more importantly, in a way that leverages customer data and user flows, becomes a compelling competitive advantage. A visceral way was expressed by the CEO, who, in a 2018 interview, said "customers have so many different passwords, and they have password fatigue."

To solve that customer pain by removing the need for many point solutions created massive market leverage for PayPal.

I think more opportunities like this will emerge as fast-growing SaaS look around at adjacent opportunities and need to quickly expand their TAM.

This applies not just to existing SaaS but to PE-acquired SaaS companies to rediscover growth through leverage.

Conclusion

Building the different use-cases around the different opportunities can give a shot of momentum to a Platform team. It can also help to be proactive around the best times to think about Platforms and the role of a Product mindset.