“What If Dev Doesn’t Think Product Mgmt Represents Customers?”

Richard Mironov -

Recently, I put up a small assessment tool for product management teams. This tool is intended to generate discussion and highlight areas for team improvement. Several PMs had follow-up comments and questions along the lines of “what should we do if we’re scored ourselves poorly on a specific item?”

There are no generic prescriptions for improvement, especially in product management. It’s worth drilling into an individual item or two, though, and imagining how we might analyze the situation and take corrective action.

For context, let’s pretend to be a Director of Product Management whose team has given itself a very low score on ”Development considers Product Management the primary proxy for customers.” There are a range of possible root causes such as…

[1] Development might be right. Product Management may lack real customer insight.

This is a tough diagnosis, but could be accurate. Some product managers are simply not tuned into their markets/customers/use cases. This is even more serious if it’s a systemic problem throughout an entire department, in which case we need to take decisive action including:

  • Getting PMs out into the field for extended listening time with customers (and no sales people in the room)
  • Win/loss calls and pipeline review
  • Fact-finding with channel partners
  • Sit-downs with Tech Support

Etc. If we’re not representing market needs and customers and prospects, we should hang up our cleats and go home. (Let’s hope our issue is something else.)

[2] Product Management has deep customer knowledge, but isn’t sharing.

Our job includes being perceived as market experts as well as being market experts. If we’re not merchandizing what we know, then developers can be forgiven for looking elsewhere. Check how often PMs are creating opportunities for sharing and active conversation, such as:

  • Emailing customer interviews to the extended team
  • Bringing (well-behaved) engineers along to customer briefings, or bringing customers in to meet the development team
  • Adding rich detail to user stories, personas, market maps
  • Bringing pizza in for PM-led lunch-and-learn sessions. (Food is a great attendance motivator.)

You know you’ve succeeded when engineers start forwarding your links and write-ups to others on the team.

[3] Engineers are confused about our target segments or customers.

It’s natural for technical folks to imagine customers just like themselves. If your target users are consumers, or non-expert corporate IT folks, your developers may discount your descriptions and requirements. (“Everyone knows how to write a simple SQL statement.” “Web services are always asynchronous. Users know not to hit SEND more than once.”)

Explain that revenue depends on a different kind of customer. Detailed personas and live meetings with a few users can help rest expectations.

And so on. Notice that our action plan depends on a clear root cause analysis. We can only address WHY our developers might consider us market lightweights once we identify their concerns. Don’t assume that technical teams understand product management (or care much about its finer details) until we’ve demonstrated value and competence.

Sound Byte

Dig deep for real root causes before you jump into solutions.