Agile Poses the Boss-Level PM Challenge

While there might not be a single correct formula for fitting product management into an Agile setting, there's one inescapable rule: Prepare to have your PM skills put to the test.

Recently, I was speaking with Barry Paquet of Quantum Whisper, a small firm that has a tool designed to help PMs with these Agile-related challenges. To the right, you'll see one of the slides from Barry's presentation. The message is pretty self-evident: if your company is going to take the "voice of the customer" part of Agile seriously, PM must keep a lot of plates spinning. Feedback loops in Agile development don't run themselves—someone has to be on top of the collection, analysis, validation, communication, and review. With Agile, these activities are happening nearly constantly.

While any PM who has a passion for building good products should welcome this change, it also can be a little scary. In my own research and advisory work on Agile adoption in tech industry companies, I've heard some PMs express no small anxiety about this new model. In part, they're worried that the company might not support or even understand this process fully. However, they also experience some dark nights of the soul about whether the have the skills and experiences needed to play that sort of role. Here are a few common concerns:

  • How good am I at collecting customer and market intelligence? A PM who has been used to listening to customers infrequently and somewhat randomly—say, through customer advisory board meetings and on-site customer visits—may not know how to collect customer feedback as quickly as Agile demands.
  • How good am I at translating between Development and the customer? Moving at an Agile pace, teams cannot afford to keep asking the question, "What does this customer really want?" PMs need to be conversant in both the customer's language (projects, problems, solution architecures) and Development's (releases, features, application architectures), and quickly explain one in terms of the other.
  • How good am I at keeping the roadmap on track? So far, we're talking about staying on top of tactical decisions, such as, "Should we build this feature?" However, the PM is also supposed to keep products and services on their proper roadmap. PMs are also supposed to be mindful of how an individual product fits into the larger portfolio. Keeping a strategic mindse while buried in tactical details is a challenge for anyone, whether or not they work in an Agile organization.
  • How good am I at saying no? To do what the Quantum Whisper slide suggests, PMs are going to be very busy people—so busy, in fact, that other tasks will have to fall off their to-do lists. Obviously, that reality won't be welcome news to everyone.

While the picture I'm painting might look a bit scary, PMs do successfully make the Agile transition. You'll raise the odds significantly if you do a bit of introspection first, and if necessary, ask your management with help. For example, the power of No increases when it comes from our boss, too.

Comments

Think Product Management vs. Product Managers

Tom,

For the last four questions, I think they would be better phrased if instead of "I" or "PMs" those were replaced with "Product Management".

i.e.

1. How good is Product Management at collecting customer and market intelligence?
2. How good is Product Management at translating between Development and the customer?
3. How good is Product Management at keeping the roadmap on track?
4. How good is Product Management at saying "no"?

Actually the final question is better phrased: How good is Product Management at ensuring their "go/no go" or "yes/no" decisions related to the product are seen by others as in the best interests of the business?"

We need to look at Product Management as a critical business function made up of team members and not simply as individuals who have product management responsibilities.

For question 2 above, if Agile adoption requires a much more intensive level of communication with Engineering, then the PM team should be equipped with (additional) people who could address that. e.g. create pair-teams of PM/TPM (technical PM). The PM can focus more on the business/market/strategic issues, the TPM can focus more on the technical/Engineering/tactical issues.

Together they would be a formidable team that has skills, domain knowledge AND bandwidth to adequately put focus where it is needed.

Saeed