If there’s one technology change that sums up the last decade it is the “cloud”. Cloud services such as AWS, Azure, and the Google Cloud Platform started with a promise of cost reduction through the use of shared infrastructure that scaled based on your needs.

Why waste money running big beefy servers throughout the night, when you only had a handful of customers using your site? The promise of elasticity transformed the delivery of infrastructure. Now through micro-services and server-less, software architecture has also simplified.

The AWS platform started the Internal Amazon culture of developing micro-services and their collaborative open-source model. When writing new services developers now look across their organisation. If an API already exists that provides the required functionality they will use or adapt it. If not, they develop a new service and make it accessible to everyone else.

Before, developers would duplicate many of the shared features required for their applications. As an example, all their customer applications need a log-in function. Amazon may have ended up with many different authentication implementations. Each one with different capabilities, bugs and maintenance overhead. It was costly enough that it forced a rethink.

Amazon developed a strong internal platform for its common functions. They had developed something bigger than a set of APIs to sell products on their store. The platform was the birth of AWS and has since developed into an 80 billion dollar business.

Platforms have become the plat de jour over the last decade. Infrastructure platforms, the Google and Apple stores, and double-sided marketplaces like Uber, Airbnb, and PayPal have transformed the B2C, B2B and B2B2C landscapes.

Platforms create advantages such as stability & quality code, network effects and reduced support overhead. It’s easy to see why they are growing in traction as commercial solutions, as well as within private organisations.

Platform or Product?

In the book ‘Platform Revolution: How Networked Markets Are Transforming the Economy — and How to Make Them Work for You’ the authors defined a platform as: “A business based on enabling value-creating interactions between external producers and consumers. The platform provides an open, participative infrastructure for these interactions and sets governance conditions for them.”

Where products enable users, platforms enable development teams to build products (faster). Typical “personas” of platforms include developers, product managers, administrators, and partner networks.

A big question for consumer product teams will be to decide whether they should build functionality or buy from a vendor. When building a platform, that decision is reversed. Platform teams are instead required to determine the key features which will enable other teams:

• What are the core features that users will regularly utilise?

• What features are non-core that product teams will need to develop themselves?

Emerging Roles

In May 2020 ThoughtWorks released their most recent technology radar on the tools, techniques, platforms and frameworks that they believe are worth investing in.

‘Applying product management to internal platforms’ was their number 1 technique to adopt. As a product manager with a development background, it caught my attention.

Platform Product Managers and Developer Experience are two emerging roles that have not traditionally been on technology org charts. They are new roles that serve an emerging customer group — the developer!

Platform Product Management

The platform product manager has many of the same responsibilities as a typical business product manager. They still set a product vision & strategy. They still have a roadmap to manage. They still manage the three core product risks — desirability, feasibility and viability.

Desirability is where the biggest change occurs for a Platform PM. Instead of consumers or business users, in a platform, the main users are developers. Secondary users will often include other product managers, administrators, and partners.

Platform product managers optimise the developer experience. They prioritise for developer velocity and develop a range of features aimed to speed up the product development cycle. Self-provisioning of access, self-management of product configuration, new API capabilities, and providing accelerators like SDKs are all common to platform roadmaps.

Instead of working on external marketing like websites and advertising, Platform product managers will instead focus on help documentation, sample code, code generators and walkthroughs.

Platform product managers will have some overlap in the metrics that product managers typically focus on. They will also track unique metrics relating to the developer experience. One example of this might be the time elapsed from developer sign-up through to the developer executing their first API call (often as part of a “hello world” sample application).

Feasibility considerations for a platform product manager include:

• Alignment with the organisation’s API strategy

• Does the API expose private data?

• Should the platform use public or private APIs?

• Should the tools be closed or open source?

• What are the availability requirements for the platform?

Finally, a platform product manager considers the viability of the platform, balancing the cost of development vs. a monetisation strategy.

There are several successful platform monetisation strategies a Platform PM may consider. Tiered API Call Volumes & Limiting, Subscription Access, Profit Sharing, and Premium Access to limited services & volumes create flexible business model opportunities.

Payments platform Stripe recognised that premium access provided an opportunity. Through their Stripe Connect platform, they provided access to incentivise partner signups. Partners can now publish extensions on Stripe’s marketplace and generate their own revenue. Both partners and stripe win. Stripe benefits from the network effect, taking a slice of the profit from their platform partner transactions.

For in-house platforms, PMs may also secure funding through a business case. The upstream revenue opportunities flowing through the platform are justification for continued investment.

Platform product management is a new function, but one I see a growing demand for going forward. Shared components and micro-services reduce wastage across teams whilst creating new revenue opportunities. The management of the platform’s bug fixes and feature requests from several clients will benefit from product thinking.

Developer Experience

As developers gain more responsibilities, they need to use increasingly complex software. Unfortunately, for many dev tool interfaces design was an afterthought.

What is DX?

Like typical product managers, platform PMs benefit from working with someone who specialises in user experience.

In consumer-facing applications, UX designers seek to design simple interactions. Through common sense, known patterns and learned experiences, a process of simplification occurs. But developers are not typical users.

Designing developer tools requires a different approach. Where consumers appreciate simplicity, developers need and expect a level of complexity to do their job.

In Justin Bakers’ 2016 post ‘Devs are humans too’ — he proposed that devs instead need:

• Function — Expected behaviour, feature-rich

• Stability — Reliability, Consistency

• Ease of Use — Quick access, shortcuts, speed

• Clarity — Intuitive visuals, clear displays

Developer Experience is a new craft which optimises APIs, frameworks, and tools for developer velocity. DX’rs ensure that platform function is as expected, and look for optimisation opportunities.
 
DX is important in much the same ways that UX is. DX increases the likelihood that developers engage with the platform, minimises frustrations and dropouts, and makes developers more effective in their job.

“Designing an API is easy, Effective API design is difficult” 
 — Ronnie Mitra, Principle API Architect, Layer 7

Ronnie summed up DX quite nicely. “DX is the sum of interactions between the developer and the API (platform) owner”.

Smart companies are increasing their success through platform product management and focus on developer experience.

At the end of the day, good product managers build products their customers love. With the majority of product teams often developers, it seems obvious that we should have always been investing in their end to end journey.

We need to treat the developer journey in the same way we would approach a customer journey.