Selling Vs. Learning
I talk with product managers all the time, and always ask whether they are talking directly with end users and target customers. The most frequent response from enterprise product managers is “Of course! I’m on sales calls two or three times a week.”
That’s great, and helps push the current-quarter revenue needle, but is IMHO a terrible way to learn about general customer needs and broader market trends.
When an enterprise sales teams pulls a product manager into a customer meeting, it’s to address a very narrow issue on a specific deal. We’re brought in to remove blockers, suggest workarounds, or explain roadmaps. To help close. We’re not there to explore new use cases; or ask open-ended questions about future requirements; or have prospects compare us objectively to a long list of competitors; or build user journey maps; or solicit opinions about radical pricing changes. Sales teams shun product managers who slow down the selling process.
And (at least at enterprise companies), these meetings are not representative of our overall customer base. They tend to be the largest customers/prospects with the most complex use cases and most sophisticated requirements. If all we see are what our major account teams bring us when the standard solution doesn’t work, we get a deeply biased impression. We hear more about “security audits of multi-tier account permissioning” and less about “effortless end user onboarding.” That leads us to mis-prioritize the needs of the (big) few over the many mid-tier users and broader growth markets. Pushing us toward ever-more-custom solutions for ever-more-specialized fewer large buyers. (And custom development is an entirely different business than productized software.)
What’s the Alternative?
Great product teams make ongoing customer learning a core part of their mission. As UX folks have always known, we must reach out to an assortment of representative users/customers/prospects. We must understand their context, user case, price sensitivity, data preferences, workflows, etc. We can’t spot the outliers until we’ve talked with large numbers of core users. Along the way, we hope to discover that our product/market segments are made up of hundreds/thousands of customers who want the same thing.
Whenever I dive into a new market or product area, I set up a few dozen unstructured calls with seemingly-average users to get some grounding: Jobs To Be Done, terminology, likely segments, success criteria, etc. Non-directed listening and learning. (Here’s my interview guide from 2002.) Absorbing it all before trying to ask/answer specific questions.
There are lots of tools, techniques, and healthy arguments about the best way to do this. Tristan Kromer thoughtfully sorts open-ended learning from goal-directed experiments (technically called “generative” and “evaluative” research) in What Type of Lean Startup Experiment Should I Run? Or read Laura Klein’s When to Listen & When to Measure. Or Teresa Torres’ Introduction to Product Discovery. Take a page from these smart folks, try an approach, see what works. Regardless of your method, your customer discussions should be low pressure, exploratory, leisurely and humble. Do as little talking (i.e. as much listening and learning) as possible.
But over and over again, I see product teams that apply none of those… that are getting only second- and third-hand feedback from deeply biased sources. Remember that every departmental input stream is naturally biased:
- Tech support talks only with active users (not prospects) who report problems
- Online surveys oversample those who love us or hate us, and those with time on their hands.
- Marketing tends to echo what Gartner and Forrester say, which is a delayed reflection of the largest buyers
- Customer Advisory Boards (especially when organized by Sales) are more about relationship-building than learning. We invite executives (not end users), race through high-level roadmaps, and hope for a generic “looks good to me” reaction.
Interestingly, some of my least biased inputs comes from Inside Sales (which has to sell what we actually have, in volume); implementation teams (who have to make it work); and third party win/loss analysis.
Thoughts for Leaders
If you manage a team of product managers, getting them to talk (directly and often) with customers may be the most valuable, highest leverage, more powerful, least cost driver of success that you can orchestrate. Knowing what a broad range of customers want/need/think/say/love/hate/buy is core to everything that product management does. And without it, your products (and people) are likely to fail.
Your team isn’t deprioritizing customer learning out of spite, though. Every day, they are pulled in 20 other directions. Unless you create some structure, all of their time will be chopped up into (urgent but tactical) story writing, financial reporting, sales calls, retrospectives, sprint planning, roadmap reformatting, HR meetings, pricing templates, and angel-on-the-head-of-a-pin arguments about whether something is a product or a service. As the Head of Product, you must pick a few strategic activities to encourage, track, measure, justify and reinforce.
If frequent non-sales customer conversations are important enough, you should:
- Make these interviews an explicit objective/MBO. Every product manager (product owner) needs to talk directly with 15 customers/target users every quarter, including long-form verbatim notes and observations shared with the group.
- Demonstrate their importance, by having folks recap customer learning in your weekly team meeting. Inspect what you expect.
- Push back on less strategic demands for your product managers’ their time. (Their #1 objection to first-hand learning will be all of their other tasks.) You can decide that your product managers don’t go to trade shows unless they are speakers; don’t routinely jump onto sales calls without two days’ notice and solid briefing by the account team; let Support manage defect escalations; don’t write most tests or user documentation; aren’t responsible for generating raw P&L data that should come from Finance. If you want your team working strategically, help them make time for what matters.
- Address sales objections to product-led conversations and “who owns the relationship.”
- Insist that your team shares customer interviews with Engineering. Well-informed developers do better work, have higher morale, and appreciate your product managers more. Win-win-win.
As Director/VP of Product, you set priorities and expectations. If ongoing customer learning is essential to building the right things (and it is), then you need to drive your product managers there.