Building Platform Products: From Conviction to Maintenance

The five stages of creating and managing platform products the right way: opportunity, conviction, planning, focus, and maintenance.

👋 Hey, it’s András here! I write about all things product management: concepts, frameworks, career guidance, and hot takes to help you build better products. Subscribe for each article to be delivered when it’s out!

Platform product management requires different skills than a traditional consumer PM role. When a product team is building a platform, they need to consider the expectations of multiple internal teams and find ways to push the right things forward. Most platform teams only indirectly create customer value. Instead, they empower other teams to move faster and develop frameworks around common product needs.

There is a unique challenge with platform products: if you build the wrong thing or the wrong way, the team quickly becomes a bottleneck, delaying other teams’ progress. For example, just think about a data platform team that is busy fulfilling specific requests from other teams instead of building an actual platform capability.

Over the years, I participated in and observed different kinds of platform product work: a marketing automation engine, data reporting functionalities, and scaling a multi-million user booking system. In this article, I’m sharing my learnings on approaching the various phases of platform product teams.

And it starts with an adequate situation.

1. A situation arises

Most platform product teams I worked with were born out of a business challenge. Maybe the company realized that they built the same things over and over in the past, and it’s just not efficient. Or it could be that executives are not happy about the time-to-market speed. Or, in case of ambitious market expansion plans, the business might be just planning ahead to handle the growth.

In any case, there is a situation with untapped potential.

Experienced product professionals should recognize an opportunity when it makes sense to change things around and start investing in platform work. But before teams do that, a fair warning: platform capabilities are not always the solution.

There is a difference if something happens for the fifth time in two years with more to come. And another where the challenge is the second instance only, with no expected recurrence. In the latter, we don’t need a platform.

A good mental test of whether a company needs standardized capabilities is to consider how much duplicated work teams deliver. And we shouldn’t only think about the developers here. Are the product and design functions working on very similar problems in different groups? Do they create solutions that are oddly close to one another?

To identify whether you’re in the same situation yourself, ask the question: is the problem/solution you’re working on only relevant to your team?

If not, maybe it’s time to start discussing it.

2. Convincing top and bottom

Selling the idea of a platform product team is challenging.

First, measuring the opportunity in terms of revenue impact is almost impossible, and the value created is often indirect—enabling other teams to build faster.

Second, when trying to sell the need for the platform capability, we should not be just pitching the idea to leadership. But we should involve developers early on who would be counting on the work of such a team.

Telling it to developers is not only good for communication but can also be validation. If our subject matter experts don’t see value in platform capabilities, that’s a telling sign that we might have interpreted the signals wrong. But if they agree, they can be a powerful ally in convincing others.

Taking to engineering, product, and business leaders requires a different approach. We should focus less on the technical capability and more on the benefits of a platform product team for the business. What would a team like that enable in terms of efficiencies, time-to-market, and growth?

We should prove how the new team will be able to reduce product development resource needs in the long term. So, developing software faster or with fewer people. Ideally, both. This way, the organization can become leaner, or existing colleagues will be able to focus on more meaningful initiatives.

3. Planning the effort

If our initiative is built on solid grounds and we’ve received a leadership buy-in to proceed forward (at least an initial one), now it’s time to forge a more detailed plan.

First, document the high-level vision of what you want to achieve, including key milestones. The plan doesn’t need to be too detailed. While we want to provide a direction, we don’t want to spend too much time working out all the details—talented people will take care of that in time.

And speaking of people, the next logical choice is to assemble the team. Here, it’s either having extra headcounts at our disposal or making changes to existing teams—possibly, removing people from less important initiatives. For a platform product team, we need staff members who can navigate well within complex frameworks, as the team will eventually be building those frameworks for others.

Another important aspect of planning is keeping the timeframe in mind.

The scope will look vastly different when planning for one or three years ahead. Even when building a three-year plan, the focus should be on building the biggest value-adds first. And the longer the timeframe is, the more chances the project will have for disruptions. Periodically following up on milestones will have an immense effect.

One fundamental goal of platform capabilities is to provide value early to other teams. Therefore, it’s unwise to waste time on nice-to-have functionalities that look good on the surface but solve tiny aspects of the core problem.

In addition, if an organization had teams building similar solutions before in silos, it’s likely that the new functionality won’t be immediately on par with those previous capabilities. And that’s totally fine! Instead, take learnings from earlier attempts to avoid repeated mistakes. And put the focus on where it matters.

4. Keeping the focus

As with all software projects, there will be roadblocks and challenges on the way. We should be wary of our time and resources to ensure spending efforts smartly.

Keeping focus is crucial when building initial platform capabilities.

It’s easy to allocate two days to something that’ll look nice, especially when working on a three-year project. But the more often that happens, the more delay will be piled up.

Ruthless prioritization is required when building platform solutions. There are always more ideas than capacity, so we should be mindful of what to say “yes” to. Choosing one priority over another doesn’t only mean spending an amount of time building something. It also blocks us from doing anything else that is potentially more rewarding.

The question is: does it worth it?

As with any product, a platform product team will also need to say “no” to many good ideas that are just not worth building for others at a given moment. It’s not that a suggestion would be irrelevant; it just means that right now, there are initiatives with a bigger impact.

5. Maintaining the solution

Once platform products reach a mature phase, teams building them shift focus to maintenance. Instead of quickly adding new capabilities without too much of a risk, teams will need to balance scalability, reliability, compatibility, and future needs.

At this point, at least a few internal teams rely on the platform. Scaling the service to their needs is essential, especially if the utilization is continuously increasing.

Think of additional registered users, new documents created, or new bookings in a reservation system. Any of these would mean that a service not only needs to manage existing items but must also handle the additional load.

In terms of reliability, the platform product should be constantly available. The team must prepare additional safeguards for peak load times, malicious attacks, or any major internal mistakes that can bring the service down. If the product is a data platform facilitating requests for other teams, an outage is critical.

Efforts around compatibility should also not be ignored. Developing a mature platform product means that, over time, different teams might have integrated with the solution in different ways. Any change to existing APIs, endpoints, or other capabilities has to be aligned with other internal teams using those. We could win a lot here if the team enforced tight control of those interfaces in the past, preventing faulty or overly outdated integrations.

And last but not least: handling new requests. This task can already sound daunting in addition to the points above, but if a team wants to stay afloat, they need to invest reasonable time into three things:

• Building new things for others: To continue better enabling other teams, the platform product team will need to create new capabilities. What are the functionalities that would make the most impact? Again, building any product involves saying “no” to many good things, and this is especially true when maintaining a framework. On top of this, new requests can also increase the overall product complexity, making future developments more challenging.

• Building new things for themselves: Creating tools that enable supporting the existing platform product—better reporting, improved alerting, or a quicker way to achieve a recurring task. Writing documentation and organizing internal knowledge-share sessions is also part of this effort, as the team wants to be prepared to provide the best support.

• Deprecating underutilized functionalities: Maintaining functionalities, fixing bugs, and just dealing with the increasing complexity have a bigger cost than developing any single feature. No team can carry the weight of an ever-increasing product. Platform teams need to invest in reviewing parts of their offering and make wise choices about what not to support in the future. Removing an underutilized feature can make space for something new.

Keeping a platform product healthy and prospering over long periods of time is the true test of any product manager. Success requires strategic thinking, being constantly connected to other teams, and making informed choices.

Takeaway

When managing a platform product team, identifying the correct stage can help us make better decisions, resulting in better business outcomes. All teams start with an opportunity that turns into conviction, planning, focus, and then finally, maintenance.

It’s a bit like building a feature, just bigger.

If you’re in a similar role, remember to focus on key use cases, not edge cases or single-team requests. What are the opportunities with the biggest impact? And how can you enable the team focus on those with minimal disruptions?