What is the Product Mindset in a Platform Context?

Introduction

Before we continue talking about making the Platform into a Product, we should probably talk about the mindset and discipline. There could Engineering Leads who want to ensure the Platform is a Product, and that's fine, as well.

It's not about the title, it's about the function.

Key Product Mindsets

Notice that I'm referring to the mindset, not the role. This means, if someone has the bandwidth and intention, they can take it on.

Customer Obsession

Often, the "customers" are the internal stakeholders. And there's a role for that. I write later in the series why internally referring to the internal stakeholders as "customers" or letting those stakeholders refer to themselves as "customers" yields bad outcomes, and what the alternative is.

However, for this article, I'm saying that the Product person must take the mind of internal engineers as customers and, in that context, apply the same principles found in external facing product maangement.

These include:

• Defining the persona or personas
• Empathy for what the real problems are
• Letting customer input drive, but not dictate, the solution
• Comfort with falling short, but always striving, for customer delight

Intentional Communication

I spend much more time on this because communication is probably one of the areas overlooked, yet can be extremely valuable.

It is likely overlooked for internal teams because we associate such communication with marketing.

But intentional communication goes beyond just informing.

In fact, much of the role could be about communication which does the following:

• Surface potential risks and invite discussion
• Highlight customer feedback, bad and good
• Summarize across different levels to ensure engagement and awareness
• Message and encourage adoption
• Neutrally provide transparency which encourages accountability
• Energize without sugarcoating the entire company

It's easy to fall into the trap that communication is an "update" -- and this often makes sense within an engineering discipline. What happened, how does it work.

But intentional communication moves the needle in ways that may not be as tangible, yet is important for building the internal platform and treating it as a product.

Driving Decisions, Trade Offs and Outcomes Beyond Engineering

In the same way that an external-facing Product Manager is responsible for driving a non-engineering outcome, such as user engagement, revenue, customer satisfaction, or cost reduction, so does the Product Manager for the platform.

While an Engineering Leader has the skills to do this, the question (as with all of these mindsets and disciplines) is time: this often involves additional research, interviews, and "thinking time" to do this well.

Common areas a Platform Product Manager spends time on:

• Framing and facilitation priorization of impact goals for engineering initiatives
• Enabling and driving decisions on divergent engineering expectations of the platform
• Teaming with external PMs to anticipate platform requirements based on external customers
• Creating a platform vision and engaging all stakeholders for buy-in and feedback

While the Product Manager is responsible that a decision is made, he or she is not necessarily the decision-maker in the case of a platform. While in an external product or feature, that decision does rest with the product manager, this is different with an internal platform.

Why?

A decision that no one agrees with internally will fail. That isn't always true with an external product -- often times, the lack of internal consensus can still resut in wild success in the market.

The collisions, the differing goals, the ambiguity can make this decision-making process difficult and, for anyone, unpleasant.

However, it still needs to be done.

Why have a separate Product Manager?

This article outlines three common mindsets for the platform product manager -- mindsets which could be adopted by an engineering lead in a platform engineering team.

However, it's possible no one on the platform team wants to take on these functions. In which case, it might be worthwhile to have a dedicated Platform Product Manager.

Here are common reasons why to have one:

1. The lead engineer of the Platform has his or her plate full on the engineering execution already (bigger team, broader scope, than when the initiative started)
2. No one on engineering wants to take on the ambiguity, frequent communication, or understanding the different internal stakeholders needs
3. The Platform has strong business stakeholders, which can include direct link to revenue, cost management, or -- the strongest case -- the platform has potential to, itself, becoming an external product with its own P&L

The downsides of not doing enabling someone who has experience in the product approach and the bandwidth to support the platform team include:

1. Internal stakeholders, including the engineers on value streams, don't adopt or value the work of the Platform
2. Platform isn't widely used or adopted (or worse, receives complaints)
3. Platform experience feels disjointed and doesn't have a cohesive roadmap and vision
4. Business stakeholders question the benefits and roll-out of features feels slow
5. As a result, fewer resources are given to the Platform, which aggravates its inefficiencies and failure to deliver value to internal stakeholders and the market

Discussion

A common instinct is, even if there is value behind having the Platform, the Platform is not like a product where a Product Manager plays a role.

This article simplifies some of the key mindsets of a Product Manager to help engineering adopt this approach, if they want to.

1. Is something missing? Are there product mindsets that you think have been important to your success?
2. Do you disagree and feel a platform can be successful without these considerations? Please share!
3. Anyone experienced some of the downsides without a product approach to the platform. What was it like?