Being Empathetic

Richard Mironov -

In the middle of a CPO coaching session last week, I recalled the passing of Daniel Kahneman, the Nobelist who created behavioral economics.  My well-thumbed copy of his “Thinking Fast and Slow” taught me that none of us are as logical or unemotional as we believe – that we’re all subject to recency bias, availability bias, pervasive optimism, sunk cost fallacies, prospect theory, etc.  My Kahneman learnings: I’m often blind to my own biases;  different people think differently; my logic isn’t the perfect universal tool to overpower everyone else; I don't listen enough; and I’m probably not the smartest person in the room.  (If you didn’t catch a whiff of late-in-life empathy and humility, please re-read.) 

The context: like this recent post, my coachee and I were talking about every product leader’s frustration that our go-to-market-side partners (GTM) and stakeholders have rampant “roadmap amnesia” and assume their next request is easy and are always trying to push 100 pounds more into our 5-pound R&D process.  Which makes us want to sit them down for yet another 2-hour lecture on limited capacity, agile, the need for validation, technical debt, architecture, or the physics of building software.

But we reframed this into the need for empathy and a deeper understanding of what’s actually important to our GTM colleagues.  (Hint: it’s not backlog algorithms or scalability charts, and no customer ever paid us for story points.)  Putting our product discovery hats back on, we should start where we would for outside audiences: what’s important to them?  What do they need (want) from our maker teams?  Why does our weekly recap of the now/next/later roadmap not stick in their heads? 

When the CRO and CEO tell us they want more “transparency” from development, is that really what they want… or is it really about delivering 25x more of what they ask for, as soon as they ask for it, exactly as half-spec’d by an end customer, without a complex review against strategic priorities or product/engineering objections? 

Here's a thought: as enthralled as we (product/ engineering/ design folks) are by our R&D process, it’s not what GTM folks obsess about:

  • They (mostly) aren’t fascinated by what we’re fascinated by
  • They are under different pressures and metrics/goals.  Sales needs to deliver revenue this quarter, not next year.  Marketing needs large numbers of prospects to be excited about our products now – especially on the AI topic of the minute – with fewer fussy discussions about what our actual product actually does for actual end users.  Implementation teams want our locked-down, unified, single-code-line platform to be more easily extended in unique ways for each enterprise installation.
  • As much as we talk about company-level alignment, every functional group sees a different subset of shortcomings in our products and processes.  Each group will naturally put its own list of technical improvements ahead of the other groups.  Support’s pain/priority list won’t match Finance’s list or Marketing’s list.

Turning this around, consider how enthused most product/engineering/design folks would feel about spending an hour:

  • Learning from Finance the intricacies of rules for capitalizing versus expensing R&D costs, and how that might boost earnings per share
  • Digging in with Marketing about how Google’s latest search algorithm changes crushed our SEO strategy, and what we might do to repair it
  • Mastering the advantages/disadvantages of account-based selling versus the challenger sales model or other consultative selling techniques

So it’s no surprise that our long-winded explanations of development processes, backlog prioritization algorithms, and uncertain product timelines leave them frustrated.

Things we could do less of

  • Be angry at folks for doing the jobs they were hired for
  • Smugly assume that we are the smartest people in the room
  • Expect that if folks understand why we rejected a request, they will be satisfied and go away
  • Try to offload discovery or business cases onto groups that aren’t staffed/trained/assigned to that, and have strong incentives to write down whatever they think we need to hear (so that we'll approve their asks) 

Things we could do more of

  • Recap the top few major roadmap items (again and again, without rolling our eyes), emphasizing how in-plan items map back to company strategy and revenue before telling people that their new items aren't important enough
  • Talk about the customer benefits of new features (“this will let users do X and speed up Y and save money on Z”).  Then ask if folks want to hear about the cool underlying tech.
  • Continually merchandize maker-team wins and accomplishments (tied to revenue where possible) to subliminally reinforce that we’re contributing to the greater good
  • Don’t accidentally say anything that can’t be unsaid
  • Bring our most generous selves to work.  Learn a bit about what other groups do. Take a moment to listen before we respond.  Appreciate that other jobs and departments are tough in ways that we may not see.  Don't become caricatures of self-importance.

Sound Byte

Empathy is a core strength of good product folks.  Let’s apply it in internally, with our colleagues, just as we do with our end customers.