Theory vs. Practice: When does a PM Determine the Work?

I love to regularly participate in mentorship with other PMs (if you are interested, I'm happy to help mentor or set up times to chat with any internal developer PM -- free of charge!). In a recent session, the PM I was talking to voiced a concern:

"I do a lot of work on discoveries. The most recent one I brought to the team, and they said they don't want to work on it and have other priorities."

When asked why they chose to work on discovery, they answered that a PM's job is to create a focus for their team, and that's what they were doing. But, the team had priorities already. Why work on something that isn't a problem for the team?

First Error: Not Working as a Team

The first error is that they didn't behave as a teammate. As a PM, we are team members, and good team members listen to their team and flex with what the team needs. Sometimes that aligns well with theoretical PM responsibilities, and sometimes that means we are on-call, reviewing PRs, or writing tickets. If a great team is flexible, then the team members must also be flexible. Think of yourself first as a teammate, then as a PM.

Second Error: Outputs over Outcomes

The second is that the PM adhered to a theoretical idea of what the role should do. A PM implements discoveries to produce focus, but why? What value is that supposed to deliver for the team? Is that different than external product management?

For Internal Developer Platforms, High-Level Priorities Need Less PM Involvement

The rate of determining priorities without a PM is higher for internal developer tools than for external products. In traditional products, the PM is the voice of the customer, and the team hears what the customer cares about through their PM. The engineers have limited exposure to customers, so the team relies more heavily on the PM to represent what's important.  

But internally, the engineers often come from customer teams, interact with them via support, and have a much deeper understanding of who they serve because they are them. So the boundary between the customer and implementer is very porous.

This results in some teams saying they don't need a PM. They may be right – I've experienced teams that don't need a dedicated, full-time PM. PMs that execute too rigidly and cause friction have burned many teams, which also feeds the "we don't need a PM" narrative. Indeed, a game of Russian roulette for an engineering team when a new PM joins them.

As we saw with the PM above, a typical team response is to freeze out the PM. Including them causes problems, and asking management to remove them causes issues, so the easiest thing is to disconnect the PM from the team politely.

But every team loves a great teammate. And suppose the PM focuses on delivering value vs. theoretical behaviors. In that case, you can show the team the value a PM can provide by solving some of their problems with the customers.

The Value an Internal Developer Tool PM Provides

In a previous post, I talked about the benefits an internal dev tool PM provides:

• Feeding product requirements to facilitate the team's flow

• Gaining adoption and feedback

• Aligning the work into shared goals and shared offerings

• Gathering data for visual communication on impact

These are worth reviewing – not as a list of actions but as a list of outcomes. I advised the PM I referred to earlier to talk to the team's Engineering Manager and Tech Lead. Work with them as a teammate to understand their worries and the problems they'd like help on. Interview them like customers.  

I've added value by refining the work that has already been committed to by a team and helped the team shine by communicating the importance of it beyond the technicals to management and customers on the fence about adoption. While engineers on a team may organically collect feedback from support or personal relationships, I've added value by aggregating it and showing common threads of pain, how it fits into the more extensive process, and having those help form requirements, as well as identifying new teams that would benefit from the adoption of the work. I've bragged about the team's impact by sharing positive feedback from customers using the product.

It can be frustrating and ego-challenging to be a PM for Internal Developer Platforms. But, part of a PM's role is finding creative ways to get results. Stay flexible and adapt to the team you work with since each is different and stay focused on the outcomes that make a great PM indispensable.