Delegation for Product Leaders

A topic that’s come up several times recently in my product leader coaching sessions: how much to delegate to the (individual contributor) product managers on our teams – including different ways of building product skills and balancing personal empowerment against good results. Said another way, if you’re running a team of 4 or 11 or 23 product managers, you have a lot to do that’s different from their direct work so you’ll need to delegate decision-making as well as execution. That means planning some nuanced mentoring. Let’s unpack…

What’s Our Goal for Delegation?

Different execs have different POVs, so I should share my bias. My stated goal as a product leader is to delegate as much direct product management work as possible to my team, both operational and strategic, so that I can do the organizational and process work to make my overall team more successful.  If my essential tasks are hiring, mentoring, aligning strategies, building cross-functional collaboration, driving sensible OKRs/goals, lobbying the executive team for more development-side talent, and preempting the next enterprise sales escalation then I can’t also be second-guessing each of my folks or doing their work for them. We need to build up enough trust and skills and hands-on experience that I shift from “doing” to “showing” to “critiquing” to “inspecting when appropriate.”

But we need good results, not just less work for me. So putting this into outcome language, successful delegation means my product managers make defensibly strong choices even if those choices are not exactly the ones I might have made. This is about creating some authority for them to apply their good judgment – rather than “I would have done this slightly differently, so let me be the final decider on everything.”

Your team’s composition will drive delegation decisions:

• A group of first-timers with boundless enthusiasm but limited product experience tends to focus on transactional activities (tickets, stories, backlogs, presentations) but will be weak on strategy, unpacking poorly conceived customer demands, and political horse-trading. So you’ll spent more time “doing” and “showing” and helping them match their transactional work to real-world outcomes. Plan on two hours per week per person for a few quarters sharing what you know and critiquing product artifacts.
• If your team is mostly seasoned senior product managers, they bring battle scars and mental models and experience with different approaches and higher salaries. But they may be overly biased toward “that didn’t work at Company X” or want junior PMs to pick up their transactional work. Expect to spend time adjudicating among senior team members who each push for their product to be most important and best-funded.

If you’ve staffed up with subject experts who are new to product, you’ll probably need to coach them past “smart users won’t make that mistake” and “no need for end user interviews, since I know exactly what should be in the product” and “let me show each customer individually how to configure that.” I find it hard to convince experts that their own personal user-side experience isn’t universally true.

My preference is for a mixed team of senior and junior folks, with a very occasional new-to-product subject expert.

But we can also sort through delegation based on tasks and activities. Which activities are suited to “show you once and you’re ready to go” and which are complex, less frequent, or have profound implications? As you plan out a coaching agenda for your team (which I encourage!), consider which product areas they will find easy to learn and where you’ll need ongoing or intensive mentoring. Here are three categories:

[1] Frequent, Transactional, Team-Level Contextual Work

Some product work happens almost continuously and depends on deep team-level knowledge. Sprint planning, story writing/ticket creation, acceptance criteria and fine-grained prioritization may look generic from the outside, but aren’t.  I can see that a user story is grammatically correct (“As a product manager, I want to build cool features so that end users will shower me with praise and dinner invitations”), but as a non-participant I lack the endless specifics to know if the story is ‘right’. Product managers and their development teams have shortcuts, code names, hard-fought trade-offs.  Long discussions boiled down to short phrases. Implicit shared understanding. Dozens of customer conversations captured in one sentence.

My acceptance test for delegating team-level contextual work is “do I trust my product manager and development team enough to mostly make good decisions and poke me when they need help?”

[2] Strategic Portfolio Trade-Offs and Corporate Initiatives

Some product choices span more than one team or one product. The PMs in my group may lack visibility or context into big issues, and will naturally favor their own team-level work. Top-down initiatives are viewed as an intrusion; common UX and technical architecture don’t exactly fit what any individual team might choose. (“A shared API is great, but let’s do it the way my developers want.” “Fixing this hot security bug is much more important company-wide multi-language support.”)

So delegation and coaching on these is a mix of skills plus strategic alignment plus broader portfolio-level visibility. As product leaders, we might compel all of our teams to work more on scalability than they’d prefer. Or harmonize SKUs/part numbers so that ordering is easier. Or negotiate common data definitions for customer profiles.
Leaders play dual roles here: pushing for specific choices on important issues while also coaching our product managers to make better shared decisions without us.

My acceptance test for the right amount of portfolio-level delegation is “are we making reasonable progress on cross-team initiatives while maintaining adequate team-level autonomy?” Too much top-down pressure turns each team into disempowered order takers; pure bottom-up prioritization encourages unrelated or incoherent bits of product.

[3] Subtle, Infrequent, Complex Work

Some product problems appear rarely – years apart. For instance, repricing/repackaging an entire product line is uncommon: some product managers may only do that once in their careers. Likewise formally retiring a product.  Or mapping out a complete migration from on-premise to cloud. These tend to be complicated, chock-full of customer challenges, politically sensitive, communication-heavy, and hard to unwind if things go badly.

So it’s likely that no one on your product team has pushed late-adopter customers to replace an ancient-but-still-in-use product with a new-but-suspiciously-viewed replacement. Or repositioned an entire portfolio for a different market segment. As the product leader, you may need to take a very active role in framing the problem, choosing mental models, persuading stakeholders, drafting content or communications, and rallying other functional groups to support this work.

If you haven’t been through that particular battle yourself, consider some short-term outside expertise. Is there a specialist in product discovery, pricing, OKRs, system security, or win/loss analysis who could guide you and your team toward a positive outcome?

Acceptance criteria might be “Has anyone on my team solved this before? Can I coach them through it myself? Or do we need a specialist?”

Player-Coaches

A lot of product leaders are “player-coaches:” formally supervising other members of the product team while also directly responsible for a specific piece of the portfolio. This is usually a transitional role: as the company grows or our teams get more experienced, this role should transition into a leadership-only job. IMO, the player/coach combination is very hard to do well, with a tendency to focus on the urgent work at hand instead of hiring/mentoring/organizing a team that gets us out of this bind. In other words, I strongly encourage people to decide if they want to be a product manager or a product leader, and replace themselves in the other job.

Product Leaders Who Are New to Product

All this demands a detailed understanding of what product managers do, how they develop, and their inevitable daily conflicts with internal stakeholders. We can’t “do” or “show” or “critique” or “inspect” well if we haven’t done direct product work ourselves. Which means this is an enormous challenge for executives from other functional areas picking up product management for the first time. It’s hard to guide newly-minted product managers without firsthand experience with their specific challenges.

In the same way, teaching solution selling to salespeople implies deep sales knowledge. And mentoring software developers on technical architecture demands real engineering experience. And real agile transformations need battle-hardened agile veterans to drive empowerment and organizational change rather than “just going agile” by mechanically following a scrum book and gluing new processes on top of existing command-and-control models.

IMO, new-to-product leaders need their own intensive coaching before they are ready to grow the next generation of product managers.  So I discourage companies from putting them in charge of unseasoned product teams.

Sound Byte

Successful product leaders need to delegate most hands-on product work, focusing instead on leader-level activities. That means understanding what each team member can handle, having an upskilling plan, and building trust.