I’d like to take a moment to reflect on the basic differences between platform product management and customer-facing product management. I’ve noticed that ways of working and processes that make one successful, don’t always translate to the other. First I’ll start with definitions:

Definition of Platform Product Management: Any internal product or tool that is used by internal teams as opposed to external customers or teams.

Definition of Customer-facing Product Management: Any feature or experience that external customers leverage.

Let’s start with the key differences in order to dive into the pitfalls in Platform Product Management. These are by no means exhaustive, they represent some of the top challenges I have witnessed:

  1. Your Customer: Yes, customers can be internal!
  2. Your Value: Why are many platforms starved for resources?
  3. Change Management and Product Marketing: Who are your champions?

Your Platform Customer: Yes, customers can be internal!

One critical mistake that platform teams often make is how they define their customers versus their stakeholders. If an internal employee is using a tool that you have built/managed/maintained, they are your customer. The issue starts when you think of them as merely a “stakeholder” who has a say in the ultimate capabilities you are building when the are much more! When we shift our thinking to internal users as customers, we shift how close to their problems we get, how well we understand them, and how well we can empathize with them.

“What you want is to manage with outcomes: ask teams to create a specific customer behavior that drives business results.”

Outcomes over output by Josua Seiden

To manage your outcomes it is critical to define your customer, so you can properly define your measures of success.

Your Platform Value: Why are many platforms starved for resources?

The way you describe the value of your platform is often the difference be investment versus divestment. As a platform product manager it can be difficult to describe the value of a tool that is leveraged by an internal customer that in turn increases (insert metric here, e.g. revenue) generated by an external customer. This is why it’s so important to understand what you control and manage outcomes for your internal customer versus the outcomes that are unconnected to your customer. Defining success by claiming the value your customers are actually generating causes confusion, double-counting, and places the burden on product for an outcome they cannot control . Example: Platform team A has built a content management platform utilized by internal team B, Internal team B uses it to personalize content and sees an incremental $1M lift because of their new personalized content. It may be tempting for Platform team A to claim this revenue impact, but I would argue that making this claim leads to disconnected goals for your own team:

Instead, set your key results on internal customer outcomes and know how they ladder up to business goals without making those your own targets (unless your work can directly impact them).

Change Management and Product Marketing: Who are your champions?

Changing the behavior of internal customers (especially those who are in completely separate orgs) can be challenging. However, with regular communication, collaboration, training/documentation, and praise you can build a foothold of champions within your organization. These champions will be critical to adoption within other teams. In order to turn a proof of concept or piloting customer into a champion, you’ll need to include them in roadmap prioritization and demos. The more connected and heard they feel, the louder their voice will be in support of the platform. The top complaints I have typically heard from internal users are related to prioritization and intake:

  1. We don’t know who to go to when something breaks
  2. We don’t know how to prioritize feature work we need
  3. We don’t know who is building the feature work
  4. We feel disappointed when features go live that don’t meet our expectations

To that end, teams considering adoption of a platform tool should always be given a process for intake and complete transparency into who is working on their ask, if it falls above or below the line, and the reasoning for the decision.

Platform product management is certainly nuanced and mastery of this craft, like all things product management, requires flexibility and responsiveness in process and ways of working.

Leave a Reply

Your email address will not be published. Required fields are marked *

You May Also Like