Platform Thinking: How to PM a Platform

Jason Fox
Indeed Engineering
Published in
5 min readDec 10, 2019

I’ve always enjoyed building products quickly. In my current role as a product manager for Indeed’s employer platform, I enable many teams to build many products quickly. In the process, I’ve learned a lot about the challenges of building platforms.

When I joined the Indeed employer platform team in June 2018, I found it difficult to explain what a platform even was. Now, not only can I explain it clearly, I can also tell you how to be a successful product manager of a platform team.

How do you “PM” a platform?

Working as a product manager of a platform has been entirely different from my previous experiences in various technical roles and industries. The “product” I manage is challenging to define because not everyone sees it or directly interacts with it. I can’t show stakeholders mockups or prototypes, and I’ve had to learn how to describe a platform’s value in ways that integrating teams can understand.

So how do I explain a platform clearly? A platform is an open and flexible framework on which products can easily be built. A platform essentially takes the core pieces of an organization and packages them in a straightforward, clear manner so a developer can use them without help. A product manager of a platform needs to understand how to effectively create an ecosystem for building products.

Our target users are developers who build products on the platform, and they have different needs than users for whom we traditionally develop products. I had to focus on making my product — Indeed’s employer platform — easy for integrating teams to use. Complexity had to be abstracted away from users whenever possible. Any time a developer has to ask for help with platform integration, I believe the platform has failed.

Indeed’s API Platform

When I joined the Indeed employer platform team, our company was moving quickly to a service-oriented architecture. We needed an API platform to facilitate communication between services. My challenge was to build an ecosystem of well-documented, easily consumable, self-service APIs to facilitate product development. These APIs would be an important piece of our employer platform.

We needed teams to begin using our platform as soon as possible, so we only built what we felt was necessary to provide value — the minimum viable product (MVP). Our team started building a collection of APIs on top of Indeed’s core employer capabilities like posting jobs and managing candidates. Even before launching our MVP, a few teams were willing to wait to start new development until our core set of APIs was complete. We were confident our MVP provided value.

Typical product teams use data to decide how to iterate on a product to improve it. The API team was no different. We set out to build our core APIs, and based on early usage and findings, planned to iterate and improve the experience for integrating teams.

If I build it, will they come?

Within a few months, the Indeed employer platform team had developed an easily discoverable collection of APIs and had achieved our MVP. However, we suffered from slow adoption outside of a few initial teams. Other teams that already had developed products didn’t move their products to our APIs because using the APIs didn’t provide short-term value. This was frustrating and we started feeling pressure to increase usage, just like any user-facing product team.

Timing was critical, but we were confident we’d increase our adoption rate, given early feedback about how easily developers created new products with these APIs. So we kept pressing forward. Over several months, we saw more teams use our APIs. As we iterated with new APIs and enhancements, we found that not only were teams creating with these APIs without our help or knowledge, but the resulting products were fundamentally different than we expected.

What changed to drive adoption? We saw growth after developers told one another about the ease of use and availability of our APIs. Communication played an important role in the adoption.

Defining value and advertising it

The slow early adoption resulted in a healthy debate about the value our APIs were providing. Our organization generally saw the need for APIs. But if only a few teams were using them, how valuable were they? This is where I felt particularly challenged as product manager of a platform. We didn’t necessarily have the same freedom to iterate on the APIs that a consumer product might, because iterating on a platform might take significant time.

I’ve found ways to iterate on our platform to provide quick wins while investing larger scale improvements. For instance, we received requests to make several smaller APIs available, which we could we deliver quickly. We also received requests for an entirely new API access pattern, which would take more time. Therefore, I prioritized the smaller APIs and delivering value incrementally. Once our adoption grew, I faced fewer challenges on making larger investments such as the new API access pattern.

The skepticism I faced during platform development ultimately led me to find effective ways to communicate the value a platform provides. I had to ensure that as many people as possible understood the benefits our API platform provided, such as ease of use and flexibility. Once developers realized they could build products quickly, and enjoyed using the APIs, the value of the platform became clear.

Takeaways from platform product management

My experiences have taught me the following key lessons to successful platform product management:

  • Make everything easy to understand
  • Make everything easy to use
  • Instead of “locking down” the system, strive to make every internal capability available
  • Seek qualitative feedback, and then use the feedback in platform iterations

I’ve had to understand the capabilities the APIs needed to provide, as well as the ways developers would use the APIs. I’ve needed to find the balance between delivering short-term value and focusing on long-term strategy and stability. Achieving this balance and clearly communicating the often-ambiguous value of platforms have been the most challenging aspects of working as a product manager of a platform.

The rewards, however, more than make up for the challenges. With my platform focus, I’ve had a broad impact on Indeed and enabled many employer products you see on employers.indeed.com today. It’s also benefited me personally, giving me a unique perspective on how to take an idea and build a platform around it. I am excited to share these learnings and inspire you to apply platform thinking in your own endeavors.

--

--