Platform Product Leadership
I share book summaries in an email newsletter! Sign up here.
–
Note: The views expressed here are my own (Nitin Julka) and are not an official representation of my employer’s perspective on these topics.?
–
Context
Few technologies provide the impact, leverage, efficiency, and scale of great platforms. This article is intended to persuade product managers to consider the platform and technical architectural implications of their product choices. It is also a “call to arms” for product teams to be ”Platform First” when designing and building scaled software.?
For platforms to deliver on their full potential, the CEO must embrace platformization as a top priority at the company. Steve Yegge said it wonderfully well in his famous platform rant, “A product is useless without a platform, or more precisely and accurately, a platform-less product will always be replaced by an equivalent platform-ized product.”
What follows is an outline of my thinking of this topic, including:
What Is a Platform?
Platform Definition
I think of platforms as distinct from applications, marketplaces, or technology companies. An application delivers value for a user or set of users. The New York Times app is an example of an application. A marketplace is an application that has multiple sides interacting in an exchange through a core interaction. For example, Lyft is a marketplace that allows passengers to connect with drivers and get rides.?
A platform is the underlying technology that enables multiple applications to be built upon it through common capabilities. Typically, platforms come in two flavors:
Platforms need at least two applications built on top of them to create leverage and value.?
Platform Product Manager
Platform product management is about distilling multiple current and future use cases into leverageable building blocks or common capabilities using an underlying technology. It requires doing sufficient research up front to create a well-designed interface because frequent changes can disrupt developers who expect a stable platform to build on. It also involves building a technical architecture that will scale into the long term. And it is difficult to measure cause and effect because there is typically not enough data.
All product managers should consider the platform implications of their product choices. They should consider the scalability, leveragability, extensibility, and future proofing of their choices. As quick definitions, I think of:
While it may seem faster to build and launch quickly without thinking through the platform implications, it becomes slower in the long-term because poorly designed architecture harms the customer experience, developer velocity, and team collaboration.?
This is not to say that there is no place for vertical product management. Platforms need killer applications built on top of them. Vertical product managers are doing discovery, understanding use cases, optimizing funnels, driving growth, and rapidly prototyping, testing, and iterating — all in service of building great products. I have no objection to any of this. My main suggestion is for product leaders to consider the platform implications of their product choices.
Once PMs have discovered a great solution, they should default to platformization when taking their products to market. The most preventable mistakes are when product folks unconsciously choose not to platformize because of a lack of understanding or uncertainty about near-term benefits. My hope is that PMs consciously decide to be “Platform First,” or if not, then that being an intentional decision.
PMs should also be aware of the psychological tendency to overweight what can be easily measured when making investment decisions. Charlie Munger writes about this in Poor Charlie’s Almanack (summary): “Practically everybody (in business) overweighs the stuff that can be numbered because it yields to the statistical techniques they’re taught in academia and doesn’t mix hard-to-measure stuff that may be more important.”
Platform Benefits: Combinatorial Innovation, Developer Velocity, Accessibility, and Dependency Management
There are many cons to “Platform First” thinking. It slows down development in the early stages of a project. It may feel like an ongoing tax on the organization to continuously think through the platform implications rather than quickly iterating. Platform enhancements are not easy for rapid prototyping and testing. They are difficult to measure, so it is hard to understand cause and effect (i.e., this feature led to this impact). Platforms also increase the security risk surface area, especially when there are third-party developers building applications on the company’s assets. Platform investments can be large and up front. And if the platform does not get utilized, then it can feel like a waste of time, effort, and energy.?
Because of this, companies need to be deliberate and careful about their decision to evolve into a platform company. One way to think about the timing of platformization is that teams need a certain amount of conviction in a product to invest in a scalable platform underneath it. If you are in early stages and still trying to identify product-market fit, then it will be too much overhead to build a platform for multiple solutions. But once you’re ready to scale your solution and take it to market, platformization may make sense.?
And the benefits of platforms are often powerful. Platforms enable combinatorial innovation, developer velocity, accessibility, improved dependency management, and technical craftsmanship.?
Platform Benefit: Combinatorial Innovation
Combinatorial innovation is combining assets from different sources to create delightful experiences. It's hard to predict precisely the ways customers/users would use a product. No single company can solve all these current and future customer problems, and especially niche problems, alone. Multiple companies must cooperate to solve customer problems. For example, look at the home screen of Google maps. The search bar is likely using search technology that was originally developed for web search. There is a widget to list the current weather likely fed through a separate company feeding weather data by geo. The voice recognition on the search is using a voice platform shared with other Google properties. The mapping data from Google maps is a platform itself that is leverageable by other entities such as crimemapping.com that shows a map of crime statistics. And it goes on and on. Platforms enable the combining of data across multiple internal and external applications to create delightful user experiences.
Platform Benefit: Developer Velocity
Platforms increase developer velocity for the platform’s clients. If there is an interaction pattern built in one place, it saves time to be able to leverage a platform for the same interaction pattern in multiple products. It’s important to think of capabilities as LEGO pieces. Developers must be able to quickly and easily combine capabilities as they would LEGO pieces. For example, imagine you work at a company with multiple lines of business (LOBs). And each LOB wants to use the same pattern of a step-by-step product walkthrough as part of onboarding. One way of accomplishing this would be for each team to individually build this capability. Another way of accomplishing this would be for one team to build this capability as a platform, and then for every other LOB to leverage the same underlying technology. The platformized way of building that capability may be a bit harder and more time consuming up front, but provide more leverage and higher developer velocity in the long term.
Platform Benefit: Available Everywhere
Platforms enable you to serve a wider variety of customers and use cases. It is impossible to think through one product experience that is going to serve a large swath of customers from small to large and across verticals. Each customer will have their own specific use cases, workflows, tools, and integration needs. By building capabilities as platform products, it creates an opportunity for partners to build upon your core capabilities, and offer the product and services across a variety of interfaces.?
For example, Stripe enables easy payments across entities. Because their API and user experience is so easy to use, Stripe can power payments across a variety of eCommerce stores. It does not require a clunky iframe going into some separate experience or application. It all fits seamlessly into one application experience.
Platform Benefit: Dependency Management
Strong platforms enable small teams to move fast with fewer dependencies. If your project requires active collaboration across many different teams to get work done, then each meeting is actually a drag on the organizational velocity. Each team should be able to self-serve their understanding of other platforms, integrate seamlessly, and effectively get their work done without dependencies.
In a non-platformized world, two application teams collaborating requires expensive prioritization exercises, and the teams responsible for resolving the dependencies feel the work as a drag on their roadmap. Think about all the times that teams need to set up multiple meetings to discuss how they want to build their integrations. Both teams need to prioritize building the integration. And then they may build a one-off integration that is not leverageable.?
As a company scales more and more, this creates a complex set of dependencies that slows velocity, makes collaboration inefficient, and requires large teams across groups to get even small projects done.
By contrast, if each platform within a company is operated with well-defined, well-documented APIs, it makes collaboration and evolution much easier and more efficient. If a team wants to collaborate with another team, they can self-discover the capabilities through documentation. They can build their capabilities on top of the other team’s capabilities. It does not require meetings and custom integrations to get work done. This is the premise behind “service-oriented architecture.”
My article on Working Backwards goes into depth on how Amazon accomplished a service-oriented architecture.?
Platform Benefit: Technical Craftsmanship
The final benefit of great platforms is improved technical craftsmanship. Whether for internal developers or external developers or both, building great platforms is building great software. This is the way to build for scalability, maintainability, leverage, and extensibility.?
Platform principles: Multi-Decade Abstractions, Build with Externalization in Mind from the Beginning, Trust Above Everything, and Ecosystem Value?
As outlined in My Product Strategy Approach article, I’m a fan of principles when building products. I think of principles as enduring truths for a product area for the next 10+ years. Principles enable teams to make decisions without leadership. Some of my favorite platform principles are picked up from companies across the industry.?
“1. All teams will henceforth expose their data and functionality through service interfaces.”
“2. Teams must communicate with each other through these interfaces.”
“3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.”
“4. It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn't matter. Bezos doesn't care.”
“5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.”
“6. Anyone who doesn't do this will be fired.”
The idea is not to externalize every endpoint. But rather, design endpoints “outside-in” so that they can be externalized in the future. To begin with, this is simply better technical craftsmanship – especially for a rapidly scaling business. Even if there are never external consumers for a service, a team may build a capability that multiple internal teams may want to leverage. This way, by designing “outside in,” it becomes easier for other teams to leverage those capabilities in the future. Designing this way also creates the option value such that if teams want to externalize a capability in the future, they have the option to. If the technology architecture is not designed this way up front, it becomes much more expensive to design that way in the future.?
Platform Measurement: Cause and Effect Is Hard!
Measuring the success of a platform is challenging and leaders who build platform capabilities rarely get full attribution. Nonetheless, I’d recommend thinking through the platform benefits and creating measurement plans around each benefit. For example:
Another approach to measurement is thinking through the developer growth funnel. For example:
One additional measurement approach to consider is a scorecard. For example, reviewing UI-API parity scorecards, trust scorecards, or API program maturity scorecards, etc., can create a mechanism to hold teams accountable.?
If your platform does not directly monetize, then causal studies are another way to understand platform value. For example, if you want to understand the value of a developer platform, you can run an analysis to see customers using partners vs. similar customers not using partners, and see if there is a positive causal relationship between partner usage and customer value.?
No matter what approach you choose, measuring platform value is challenging. It is difficult to run traditional AB tests to understand the cause and effect of platform investments. These investments frequently need to be made based on a “leap of faith.”?
Platform product leaders may never get full attribution for their work. For example, imagine investing multiple years in building a platform that a bunch of teams can then innovate upon. Feature teams may be able to run AB tests on their features and show stat sig impact from their investments. But because both variants are built on top of the same underlying platform, teams rarely attribute success to the underlying platform that enabled those successes in the first place.?
Platform Design: Outside In?
Platform design and user experience design share many common characteristics. In both cases, I’d suggest starting with foundational user research, deeply understanding problems and/or use cases for specific audiences, keeping holistic experiences in mind, designing solutions as an ideal state, choosing the appropriate starting point, and finding the minimum ways to test key assumptions until you build a complete experience.?
One difference though is that platform changes are more expensive given the dependencies on the platform (i.e., multiple developers expecting stable integrations with these designs). For this reason, it’s important to be detail oriented and deliberate when making platform or architectural decisions that can have implications for years to come.
One approach is to start by thinking through the most complex and feasible future use cases. By starting with the complex use cases, you’re able to identify edge cases and how the platform will scale in the future.?
I also recommend partnering with an influential technical architect in the company when thinking through the long-term architecture of your product. I’ve had engineers challenge me as a product manager about what I envision for the product 5+ years from now. So much of product management is about the day-to-day, week-to-week, or quarter-to-quarter. But technical architecture and platform decisions need to be about the 5+- or 10+-year decisions with fairly high confidence. Jeff Bezos talks about building products around “what won’t change in your product in 10+ years” and this is how I think about designing platforms.
For example, if you’re running a messaging company, there could be hundreds of use cases. You might be doing messaging for customer support, selling, or collaboration. The message may be synchronous or asynchronous. You may want to message through multiple channels — web, mobile, or API. You might have different types of messages — text, voice, or video.
Each question above can become a capability layer that needs to be considered in the design. Even if the full functionality does not get built up front, you want the technical design to be built in such a way that it can expand into those use cases in the future.?
Said differently — great platforms are built on a detailed understanding of what the future is going to look like and then building those platforms with the potential to scale into that future.?
Notice how this approach contrasts with moving fast, rapid prototyping, testing something small, or getting started quickly. Platform PMs need to be thoughtful about the long-term (10+-year) implications of their product choices. They need to avoid letting the day-to-day distort thinking through the long-term implications of the product choices.
“Outside in” API design is another way of thinking about accomplishing these goals. If you assume your company is going to grow 10x or 100x the next 10 years, then there could be a bunch of internal consumers for the capabilities your team is building. Therefore, it is best to design and document the architecture and technology assuming outside developers who you’ve never met will want to integrate with the services you build. Also, if you build your software as if outside developers may integrate at some point, then that will strengthen the scalability, craftsmanship, and extensibility.?
领英推荐
User-centered API design means building APIs that have holistic coherence and familiarity. It means there should be cohesion across the multiple parts of the platform and predictability in how multiple layers of the information hierarchy operate with each other.?
API designers will describe how the “data model” matters a ton in the same way user experience designers will describe the “information architecture.”?
When you are in the design stage, you can create API stubs or “prototypes” and do actual research with internal or external developers on the API designs before building the technology.?
Great platforms must be designed outside-in with developers as a primary audience.?
It is important for product teams to get away from the mindset that we are building “UI features” and toward the idea that we are building “capabilities.” This is about solving a business problem and building the right underlying technology to scale that solution across all surface areas and not about a specific interaction on part of the app.?
One final note on platform design. Some may think these decisions are more of an engineering problem than a product problem. I could not disagree more. Great designs in any domain require the multidisciplinary approach of product management, design, and technical folks all understanding a problem space and exploring the best solutions to that problem. We want designers and architects talking to users, validating assumptions, thinking through the definition of done, planning future cases, considering third-party partners, and more. These are product and design challenges that require more than engineering to solve.
Org Design: Setting Up Platform Teams for Success
One of my favorite innovations at Amazon was how they aligned their technology, organizational structure, and dependency management via a commitment to collaborating via APIs.
But before diving more into the specifics, I want to reiterate principles of org design from my article Dear New Group Product Manager.
If there is an underlying technology platform with multiple consumers, the first step is to make sure there is a XFN product team including a product manager who is responsible for the platform. I would discourage product organizations from building teams only around specific use cases or audiences, and not around platforms. Product teams need fully staffed platform teams who are managing, leading, and building the underlying platform capabilities or driving partner success.?
One issue that frequently arises is complexity around the relationships between horizontal “platform” teams and vertical “feature” teams. The way I think about this is:
Signs that platform teams are not fully staffed may be issues with platform reliability, platform design, or platform documentation. Let’s imagine that one team wants to leverage a capability built by another team. If it requires a bunch of meetings to understand the non-documented APIs that were never designed to be consumed outside the primary organization, then this is a sign that the organization did not invest in the appropriate platform teams. If an integration with another team seems unreliable, buggy, or constantly breaking without considering the platform’s consumers, then that is a sign that the platform organization is either understaffed or unaware of their core responsibilities as a platform.
The reason this problem perpetuates itself is that not having fully staffed platform teams is “good enough” in the short-term. Teams can “get by” with engineers managing the platform capabilities. But the cumulative effect of a lack of outside-in design, platform product leadership, and fully funded platform teams is an organization that is not meeting its full potential.
There may be cases where a platform team is reliant upon feature teams to externalize their products to serve a partner audience. In these cases, I’d recommend that the platform team fully staff their product management and engineering team and lend these resources to supplement the feature teams to be platform champions within those organizations. This way, the vertical teams and horizontal teams are partnering together to ensure the success of the overall platform.
Platform companies have different roles that do not exist or do not have as much prominence in other orgs such as:
Sara Drasner at Netlify also wrote a great article on organizational designs titled Developer Experience at Netlify. In it, she describes three major roles:
And then the book Continuous API Management, by Mehdi Medjaoui, et al., describes additional important roles:
Platform Governance: Centralization vs. Autonomy
Governance is a core part of platform product leadership. There are vast numbers of cross-team decisions that need to be managed when building a platform. At the heart of these decisions is control. How much should be centralized and how much should be left up to individual teams??
The way to manage these decisions is through governance. By governance, I mean creating an automated process and/or group of individuals who are committed to upholding standards, principles, guidelines, etc., for the overall platform. Great governance requires thinking through the decisions that need to be governed, current state, platform best practices, plan to close the gap, and ongoing management and maintenance.
Decisions That Need to Be Governed
There are multiple decisions to consider when building the best platforms. What are the naming conventions? What programs should be open, closed, or vetted? Which teams should be responsible for the capabilities? What are our standards? What decisions should be centralized and what decisions should be for teams to make individually? Are there security implications with this decision?
On the one hand, you want to give feature teams the autonomy and empowerment to build fast and serve their specific use cases. On the other hand, you want to ensure that the holistic platform gets designed in a way that is aligned with the overall vision.?
Before progressing with governance, it is important to think through each of these dimensions.
Current State
The API designs are an area frequently in need of governance. Given this, Kin Lane writes that the first step to effective API governance is simply documenting your current APIs. “Identify EVERYONE who is developing APIs, and start tracking on how they are doing what they do. Sure, you want to get an inventory of all the APIs each individual or team is developing or operating, but you should also be documenting all the tooling, services, and processes they employ as part of their workflow.”
Platform Best Practices
At this point, it would be useful to articulate the best practices for governing your platform. A central team should document and publish a handbook of best practices so that these guidelines are clear to all folks working on the platform. These may include the ideal state, holistic design, conventions, standards, principles, etc.
Plan to Close the Gap
There is likely a gap between the current state and best practices. Once the gap is identified, teams can begin building a plan to close the gap.
Ongoing Management and Maintenance
There are two approaches to ongoing management and maintenance of these standards. One is having a group of people manually tracking, monitoring, and governing the platform based on the established best practices. But another approach is to programmatically enforce as many of these standards as feasible. My recommendation is to use both approaches.
Platform Culture: Tops Down and Bottoms Up
When I do a root cause analysis on nearly any systemic problem at a company, the issue is almost always culture. Typically, a successful company became successful for a reason. There was a visionary founder who had some insight — about a market, technology trend, or consumer behavior — and was able to leverage this insight as the basis for a strategy to rapidly scale up their business. But achieving the next level of scale sometimes requires rethinking fundamental assumptions about how the business operates. Fundamentally, these changes are organizational transformation and culture change — and these are some of the most challenging business problems that leaders face.?
Platform product leadership is especially challenging because it requires orchestration across business strategy, organizational design, roles and responsibilities, technology leadership, product management practices, partner strategies, go-to-market mechanisms, operations, and more. While the benefits can be extraordinary, the cost can be quite high and require sustained investments over long periods of time without immediate return.?
For these reasons, it is critical for platform transformations to be led by the CEO. Amazon would not have been able to drive the transformation that they did had not Jeff Bezos made the bold decision to embrace platforms relatively early in the lifecycle of the company. As companies continue to scale, it becomes more and more expensive to embrace this type of transformation.
For those who are not CEO, there are still strategies you can deploy to help drive the culture change and organizational transformation including:
While the goal is for the CEO to promote this transformation as a top priority, there is still hope that persistent advocacy and evangelism by a group of committed leaders can create change. As Margaret Mead says, “Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has.”??
Signs that you’re successful in driving this platform transformation include:
The Future of Platforms: Infrastructure, Services, Web 3.0, Decentralization, and Blockchains
Predicting the future is always risky, but I will share a few trends related to the future of platforms that have piqued my interest.
Infrastructure, Then Services
Patrick Salyer, a venture capitalist at Mayfield Fund, wrote an article in Forbes titled API Stack: The Billion-Dollar Opportunities Redefining Infrastructure, Services, & Platforms. In it, he says, “This first layer of the API economy can be defined as API Infrastructure, the picks and shovels, or the foundation of the API Stack used to build applications. Examples include authentication (Auth0, $6.5B acquisition), Messaging (Sendgrid, $3B acquisition), Chat (Drift), Search (Algolia), and Video (Mux)...
“The API economy is moving into a new era where APIs are moving beyond providing a utility to providing an embedded service that enables higher-order software applications to be created.? As an example, we see APIs for Banking, or Banking as a Service, that allow any existing or new business to offer bank accounts, credit cards, or lending as an embedded service within another application.”
Web 3.0, Decentralization, and Blockchains
Naval Ravikant describes an overview of Web 3.0 and the implications to API platforms in his podcast with Tim Ferriss from October 2021. Here are some excerpts: “We’re used to thinking of a computer program as an application run by a third party where they control the code, they own the data, and they own the platform and the economic benefits and then we get our scraps.…The beauty of Web 3.0 is, for the first time, all the data is actually open. The data is literally living in the blockchain or in distributed systems, but it’s secured…Then, who owns the platform underneath? as Chris said. Its contributors own the platform instead of corporations own the platform….
“So, it’s this insane concept, a revolutionary concept. When we’ve flipped applications from being closed-code (corporations own the platform and users are the data) to open-code, contributors own the platform, and users own their data. So now these things become completely composable…It connects to all the other LEGO pieces of the kids down the block, and they can build anything they want out of it and that’s how code on Web3 works…”
“The beauty is this is all open source, right? So it’s not even APIs anymore…I can literally connect to the code at any point that I want to. Then, in open source, you only solve each problem once. So if somebody has built a good version of how to solve a certain problem, I’m just going to reuse that and reuse it again…”
Some startups are emerging at the intersection of Blockchain and APIs. As one of the founders of these startups puts it: “The hurdle is that web APIs are incompatible with the blockchain. That’s where API3 and other oracles like Chainlink come in. In the simplest terms, oracles accept data from external sources and make it compatible with the decentralized consensus mechanisms of blockchains… API3 in particular makes it extremely easy for data and service providers to take their current APIs that work with existing web infrastructure and make them available to blockchain-based decentralized applications. Rather than relying on third parties, API3 enables providers to become their own blockchain oracles.”
Conclusion
I am still early in my journey of learning about platform product leadership. This is a complex domain that spans business strategy, technology, organizational design, governance, design, operations, and more. Nonetheless, platform product management has also become one of my favorite sub-fields within product management. I love thinking about the impact, innovation, leverage, scale, speed, and beauty of building great platforms.?
If you have any thoughts, ideas, or brainstorms on how to build the best platform products, or a set of best practices, please let me know in the comments below.
—
Read more:
—
Special thanks to Aaron Scales, Zane Homsi, and Ann Bartz for reviewing drafts of this article.
—
I share book summaries in an email newsletter! Sign up here.
Senior Director of Product Management at LinkedIn
2 年I just heard a great quote from Dan Reid about measuring platforms. "The sign of a great platform investment is when people leverage it later and it feels so natural and obvious that it should be there..."
Engineering@LinkedIn
2 年Nitin Julka, amazing article!!
Brex | Asana + LinkedIn Alum | Army Veteran
3 年I love your book summaries ??
Product, Data, Technology, Business Operations Leader | Real World Data | Data Insights, Analytics, & Cybersecurity | Future of Product & Technology | AI & ML in Healthcare | Digital Transformation
3 年Insightful newsletter Nitin Julka. The platform first mindset as you have highlighted in your newsletter starts with willingness of the organization to adopt a flux mindset to evolve a company culture, org design and product development. Everything around us is constantly shifting, products need to evolve as well to stay relevant and deliver value to its customer base. This can be achieved with a platform based product because of its compounding effect from internal and external stakeholders interacting with the platform.