I got a lot of good responses from this recent post about the need to frequently talk directly with real customers, especially at B2B/enterprise companies. More than a few folks raised an important concern: with so much to do as product managers, how do we consistently make time for customer interviews?  Scott Sehlhorst and Rob McGrorty shared some thoughts that I’ve extended here.

Challenges break into three buckets: (1) making authentic user validation a real priority alongside product planning, engineering partnership, sales support, and firefighting; (2) tools and processes; (3) building up interview techniques and research skills. Each of these is daunting for an individual product manager, so I’ll reframe and level up:

How can product leaders make interviews, customer research and validation an essential part of our weekly routine?   As heads of product, it’s our job to enable our product managers to work on what really matters – and provide air cover with the broader organization.

(1) Selling Executive Teams on the Value of Validation

Every company talks about being customer-driven or data-driven. But most enterprise leadership teams are convinced that they personally understand what customers want. That their product ideas are inherently good. That product/design/engineering teams should take detailed direction from them. That serious validation and user interviewing are just delays in getting to the hard business of building features. (Really. I’ve had this discussion with scores of software executives.)

This is partly based on a range of executive perceptual biases and attitudes: recency bias (“I was on a call with HSBC this morning, and everyone wants what they want”), simplification (“Halliburton just needs a user-configurable reporting engine. How hard could that be?”), selection bias (execs are hyper-aware of big pipeline opportunities and major customer support escalations), leadership bias (“I made all of the early product calls around my kitchen table, and that worked out fine”) and lack of recall about what’s actually on the current roadmap. I’m not throwing stones: being an exec at enterprise software companies is brutal and ADHD-inducing — but as the product leaders at the big kid’s table, we need to understand how our peers think.

Rather than accusing people of perceptual biases, I might:

  • Take every opportunity to remind execs teams of what’s currently being built, and the product/design work that front-ends important development efforts. (“Yes, we validate every major feature and design with customers before we spend $M’s building it.” “Skipping those steps has been very costly for us – remember Projects A and B that took a year and didn’t get any market traction?” “No, there’s no white space or unused capacity in the development organization.”) When other VPs start to repeat back my words, I know that I’m making an impression.
  • Be frustratingly slow-witted about newly brainstormed product ideas. (“Which customers have said that they want this?” “How much do we think we can charge?” “Is this important enough to postpone our 5.0 release?”)  When no one around the VP table has good answers, this gets added to the product team’s validation backlog… where it will compete against other good ideas for research time.
  • Frequently share and celebrate discoveries from the product team’s ongoing interviews and research. Show that our product homework has value. (“Wow! Here’s a market segment where we have some unusual opportunities.” “We uncovered some new competitive insights for Sales.” “Thanks for that Halliburton suggestion. Turns out they only need a simple data export, which dozens of other customers can also use.”)

This is about behavior modification, not philosophical argument.  Repetition for emphasis.  It’s hard to change how we think.

(2) Tools and Processes

Having every product manager talk live to one enterprise customer each week is a heavy lift. Handled individually, it could easily consume 5 hours/week/product manager. So we need to create a little infrastructure and political cover to smooth this out:

  • Get help selecting and scheduling interviews. Sales Ops provides lists/queries of current users by application and industry and geography; Marketing has $50 Amazon gift cards pre-approved for various campaigns; Support has call recording software in place; third party applications like Calendly let users pick open call slots. Pull together a step-by-step for picking audiences, emailing a common interview request, sharing a starter script, recording calls with permission.
  • Set up a shared folder for scripts, long-form notes, recordings, etc. Choose a file naming convention (“custname-product-date-prodmanager”).  Agree on immediately sharable outputs: 2-3 key bullets/learnings plus link to full notes and recordings – emailed/slacked to development/design team and selected leadership and relevant sales team that same day.  (After a while, developers and execs will start to notice that we talk with lots of customers!)
  • Pre-negotiate rules of engagement with the Sales VP. Perhaps we have free access to all end users, but will alert sales teams or do joint calls with buyers and decision-makers.  Or we avoid customers with P1 support escalations.  But product managers need direct access to lots of users outside the selling process.  (This can be a huge issue in sales-led companies, and can’t effectively be negotiated between individual product managers and account reps. As Head of Product, I need unambiguous top-down public commitment from my sales leadership peers for non-selling discussions with actual users.)

And so on. Our goal is to consume no more than two total hours/week to get one hour/week of live learning.

(3) Interview Techniques and Research Skills

Interviewing users or prospects is hard: listening; learning; setting aside our prejudices and preconceptions; politely digging for insights and underlying problems; being humble; avoiding jargon; meeting users where they are; not “selling” during research calls… and product managers often have little experience or coaching for doing good user/customer interviews.  I would:

  • Have more experienced interviewers pair with rookies: the newbie listens in on a couple of calls, then leads on a few with post-call feedback, then solos. Share starter scripts, standard open-ended questions, techniques. Often, we can pool some questions and have callers cover more than one issue. Build cross-product understanding.
  • Get some expert outside training in interviews and research: Teresa Torres, Steve Portigal, Noel Adams, Jeff Patton, Jen Berkley Jackson, Jeff Gothelf…  Skill up.
  • Look to Marketing or UX/Design for surveys and quantitative research, since a handful of interviews isn’t representative. Here’s some great thinking about qualitative and quantitative from Laura Klein and Tristan Kromer.
  • In the weekly product management team meeting, ask each product manager for their interview tally and one sharable insight. Applause for good learning, and offers of assistance for those not getting it done.
  • Schedule some time for small-group synthesis, where the team digs back into the month’s learning and notes to identify or uncover less obvious insights. Trends, new benefits or use cases, evolving Jobs To Be Done, emerging competitors. Collectively finding the impact on “our understanding of the market” and “our definition of the product / plan / roadmap.”  Maybe two hours/month in a remote conference room, with phones/laptops turned off.

One live interview per week per product manager is a big commitment. We can inch up to it: everyone does one or two, followed by a learnings/tools retrospective. Or we set an initial goal of every other week. But we must get started: the journey of a thousand user insights begins with the first call.

Sound Byte

It is hard to make time for critical strategic work, including live user/customer interviews. Today’s dumpster fires distract us from investments in tomorrow. But building the wrong thing is 100% waste, and picking product direction without objective research invites us to build the wrong things.