Why Have a Platform Product Manager?

If the definition of the Platform is an internal developer facing platform (IDP), then read on, this post is for you.

However, as you probably can guess, there are different kinds of platforms and, therefore, different (but very similar) kinds of product managers.

This particular product manager, however, focuses on building the internal developer facing platform (IDP).

What is the business outcome of the IdP?

Before asking whether a Platform Product Manager needs to be involved, let's review whether your organizations needs an IdP in the first place?

This feels like a chicken-or-the-egg situation. I would argue that the Platform Product Manger would help make this case.

However, there is no product manager without the case.

I'll describe how I would approach making the business case, and why in this case, starting with a qualified contract-to-hire product manager could be the ideal scenario.

The executives and managers could self-organize to come up with the following.

Understanding the context

From a top-down view, evaluate the complexity of your current and future products.

On one end, the company is single product that has no PMF.

On the other extreme, the company already has a suite, and their business model and market opportunity is to ship more and more.

As companies ship more products, they build up more dependencies.

As the company ships more products, they have end up with larger engineering teams.

The increased dependencies and increased number of engineers can result in duplicate code or slower deployments.

Gauging how much of this is due to the lack of a common platform may not be immediately straightforward. But if the teams are growing and work well, at some point, the complexity of running the entire software development life cycle will introduce lags.

The strategic assessment by executives should be around potential operating leverage from building the developer platform.

What does operating leverage look like?

At its simplest, how much can the investment and maintenance of an internal platform yield business results?

A key vector for evaluating is to match business objectives against engineering velocity.

Engineering velocity has leverage when shipping products quickly yields business results.

For a company with no product-market fit, this may not be what's needed. Instead, they need ways to conduct fast experiments.

For a company that has strong initial product market fit, and a strategically validated roadmap of disruptive or adjacent products, then engineering velocity becomes the critical business advantage.

Especially in SaaS, every month of delay is a month of potential revenue that can never be recovered.

The tricky part is having enough confidence that a given product, if shipped, would in fact yield customers. This should be part of the conversation where product leaders and executives have an understanding of the market dynamics.

A company attacking a legacy industry in IT, for example, may simply need to reproduce the adjacent suite of tools that are on-prem and make them cloud-based. Depending on their positioning, shipping good-enough products with speed could be a growth flywheel.

A company attacking fragmented B2B point-solutions and goes to market with integration may benefit from quickly attacking the point-solutions.

A company in dynamic consumer space where a "super-app" capability of native features will beat the third-party marketplace may find building quickly on top of an existing competitive advantage may find massive operating leverage.

But it doesn't even need to be that dramatic.

The moment there are multiple customer-facing points to the product, these situations may invite the need for a platform product manager:

If the executive-level view and stage of the company's growth provides a strong business case on engineering velocity, operating leverage, and a bonus of customer-facing benefits, then a case for the product manager can be brought in at this point.

If still not, there's no going past Go.

But why not have a bottom's up assessment?

A counter point could be to work bottom's up, to find costs and efficiencies.

This will likely fail, because it means the IdP doesn't have strategic support from executives.

IdP is an operating leverage move and, as such, short-term calculations on cost-savings is not going to provide enough ROI. These bottom-up assessment swill not be accurate and it's a point in time guess to help prioritize the focus area. It likely will not provide a hard quantitative proof to create the conviction to go forward.

Does that mean the bottom's up assessment has no place?

No, it should. It should be a way of prioritizing, increasing conviction and momentum, building company-wide buy-in, and justifying increases in investment.

A simple framework to evaluate

While a deeper dive is worthwhile to build strategic clarity, I think IdP's are reaching a point where the company's maturity, business growth, and financial state can give enough to justify starting an initiative to build the use-case.

Here's how I would propose an initial self-assessment based on the three questions:

How important is operating leverage across engineering and product at this point?

Operating leverage isn't just a cost-savings. In fact, as noted above, it's not a good foundation.

What is helpful is understanding the company's external growth model or flywheel.

IF there's are NO new technologies that are deployed horizontally (AI/ML, Data, Messaging, Privacy, Pricing/Cross Selling for example), there's not much leverage. Getting consistency and speed of adding new internal services which have multiple dependencies would not speed execution.

However, if there are new capabilities, doing so well, especially the more cross-product dependencies there are, matters.

For example, if products need to leverage shared data-pipelines, logging, user-data capture -- changing schema or logging behaviors on one side could break things for others.

If the technologies are deployed by internal teams, something similar can happen. If there's an internal BI team, and there is no consistency in quering cross-product data, this not only results in slowness, but potentially incapacitates a team with incomplete or inaccurate data.

The other, more compelling flywheel, is if there are opportunities for cross-product functionality that can yield growth opportunities.

Your product, for example, targets HR, and the model touches invoicing and payments of contractors, so you roll out something for accounting. Ensuring that both teams can work independently without breaking dependencies and slowing releases can have strategic value.

What inflection points or initiatives are changing the arc where this matters?

This is another cut on some of the same ideas.

Right now, AI/ML is hot and IF there's strategic value, being able to empower all development teams to work with these horizontal services, which can be external or internal, may matter.

Let's say AI/ML does get introduced on customer data, that may create an inflection point around increasing privacy, data provenance, and geo-specific policies. This may affect individual developers unless there's a way the platform reduces the cognitive overhead and administrative headaches to support this initiative.

The most compelling inflection points are those that come from an external market and there needs to be an engineering and product led response, like the two examples above.

But it can also stem internally.

For example, if the company's brand is expanding, but wants to double-down on trust and safety to preserve the brand, this can introduce lots of new processes and dependencies that engineers need to incorporate into their workflow.

Where do the executives "feel the pain" right now and what would change if it were lessened?

This seems more "touchy feely" but can still be a good starting point.

Slowness in delivery across product lines is something that may lack hard metrics, but can definitely be "felt." Uncovering where the bottlenecks lie can help.

Are there hold ups in, say, introducing customer-facing metrics across products?

Are there inconsistency in accessing customer data or authentication-based meta data?

Could it be as basic as it takes a long time to have "weekly demos" because even internal staging pipelines are just...a mess?

These conversations can give a good canvas to identify potential returns to start the initiative.

What would the Product Manager do?

While there's much I would cover here, I think the first order business and value would be to help prioritize and perhaps identify supporting data to the executive decision (both quantitative and qualitative).

The highest initial value which does require a dedicated PM is to interview all the stakeholders, the primary ones being engineers!

This is probably better done via in-person interviews combined with survey data.

But why is this important?

Because engineers will all have different preferences, desires, beliefs, problems and workflows.

The product manager needs to be able to capture these and, while treating them as customers, figure out the right set of trade-offs that will result in "customer delight."

No one wants to force a change on developers. No one.

But, some kind of change will likely need to occur.

How to do so in a way that is easily adopted, if not embraced, is not an easy question. It takes time, empathy, strategic trade-offs, and influence.

An easy task, for example, would be to look at unused and unmaintained UI's for internal development.

Likely there was at one point initial value in doing so, even those these end up not being used by developers.

Harmonizing the actual value in a developer-friendly workflow could be one way to address it.

For example, it could be code-based declaratives on environments that still enforce a best practice.

It could be auto-generating service descriptions, either in a UI, IDE or CLI, that make sense.

It could be looking at a cluster of different third-party tools used by developers to understand the migration pain if consolidation did make sense.

Just as an external-facing product manager needs to understand the customer journey, experience, and the business impact with users and buyers, a platform product manager needs to apply these same principles to come up with a roadmap and features to build the internal tool.

What is a strategic benefit of a platform product manager?

Not many companies would have this opportunity to turn what they do internally for their own developers into something customer facing.

However, if there's a glimmer that this is possible, the platform product manager could bring that lens internally and start the conversation.

For example, if a company has an internal service which is valuable for building their product, and that service actually can attract developers of other customers, that could be a powerful way to introduce another growth vector.

If it allegedly worked for AWS, could it work for you?

This turns the internal developer platform into the beginning of another revenue line.

This isn't easy to do. But it does take a platform product manager who can think in this way if you believe there's a potential opportunity.

Action Steps

Why Have a Platform Product Manager?