whac-a-mole

There’s an infinitely long list of things that product managers ‘should do.’  Take a look at any product management framework, job description, or post-launch product post mortem. (“Tech support and EMEA field marketing weren’t well-enough informed, so product management should have communicated more often and more clearly.”) We rarely say, but clearly know, that it all can’t get done.

In the real world, we play a game of organizational whac-a-mole: deciding where to spend our limited time and attention, split between strategic bits (key benefits, segmentation, pricing, competitive analysis) and keeping dozens of functional groups on course. By implication (or by subtraction), some things are going to happen mostly on their own. We depend on our various functional teams to deliver their parts of the whole… to contribute to the spirit of the product, not just isolated formulaic bits of user stories or data sheet entries.

Hint: this is a discussion about people and trust. Not development lifecycles or formal organization charts. Not blame or CYA.

Some of your partners-in-product are insightful, responsible, and know what makes customers happy. You know exactly who they are. How do you acknowledge and compliment and utilize them, while shifting scant attention elsewhere?

Delegate, trust, verify. For instance:

Your test/QA lead is a godsend. She has an intuitive ability to guess which incoming bug reports are serious, which are small-but-oh-so-frustrating-to-users, and which don’t really matter. Your company’s five-volume SDLC manual specifies that every incoming defect must be prioritized by a product manager and inserted into the infinite bug backlog. (Nowhere does the SDLC specify that a product manager’s hair is always on fire.) Which gets us to this conversation:

“Sherry: you’ve been doing a terrific job keeping the bug backlog groomed, especially when I’ve been working our UI issues. And I know you’ve been looking for ways to demonstrate more of your leadership skills. [Insert additional effusive-yet-true praise here.]
I’d like to make the process more formal: you do first-pass prioritization, kick any confusing or politically complicated items to me, and we’ll go through it together weekly. I’m still officially responsible, so I’ll take any heat/complaints. Can we try that for a few weeks? We can fall back to the standard process any time. And BTW, I’m cc’ing you and your team on a great-job-well-done email to the head of Test/Automation for Release 6.4…”

Delegate. Trust. Verify. And protect, since you she’s stepping up to handle shared responsibility, which means you provide the safety net.

Give away as much control as you comfortably can, knowing that you’re responsible for the result.

Or on the product marketing side, where the veteran really knows his vertical segments but the newbie doesn’t:

Steve: I owe you solution examples for Publishing, but you have that segment down cold. I also need to build out some scenarios for Retail Banking, which Larry isn’t as familiar with. Could you take the first cut on Publishing while Larry and I get on the phone with our NYC field team to find some solid banking examples?”

This lets you collectively deliver the goods, but also help train the new kid.  You don’t want to be pushing work onto others, but should focus your energy where it matters most. And keep a few cycles for strategic thinking.

Sound Byte

Build trust, and set some lightweight rules of engagement. Your good/strong partners will appreciate the autonomy and trust. Those who can’t work that way need closer supervision and more formal interactions.