This article was originally published on mironov.com by product leadership guru Rich Mironov in August 2017.
revenue issues. A seasoned tech executive and serial entrepreneur, Rich has been the “product guy” at six startups including as CEO and VP Product Management. He is a relentless blogger, speaker, teacher and mentor on software strategy, product management, and aligning “what-we-can-build” with “what-markets-will-pay-for.” Rich has consulted to more than 100 tech companies on organizing the product organizations; product leadership; scaling up, and company-specific strategy issues. Unofficially, Rich is a sounding board for various CPOs/VPs of Product. Rich founded the first Product Camp and guest-lectures at business schools around the world. He’s been blogging about product management and product strategy since 2002. You can contact him at [email protected], or visit his website: www.mironov.com.
In a well-run organization, each role has a single orientation; they either support individual customers or they support the market. — Peter Drucker (or Steve Johnson)*Drucker* makes a key insight that I think is essential for product managers: especially in B2B markets, some customer-facing groups deal with the world one account at a time, while product folks and development organizations deal with customer segments as a whole. Understanding this dynamic helps us unpack discussions between product managers and B2B sales/support teams about feature requests (i.e. demands). Major account sales teams, by definition, work only a few large accounts – often assigned from a “named account” list. (An educational software company might assign 30 large East Coast private universities to its Boston-based sales rep.) At enterprise software companies, there may be entire teams assigned long-term to a single customer. (Microsoft’s team covering Deloitte or Royal Dutch Shell may have dozens of individuals.) They aren’t just customer-focused, they are single-account-focused. And we want these salespeople to be narrowly account-focused. We pay them handsomely to bring in revenue, customer by customer. But while we may sell products one account at a time, we don’t want to build products one account at a time. As product managers, we must be market-focused if success means satisfying dozens/hundreds/thousands of distinct customers. No single deal is enough to meet revenue targets, so we have to position and build for entire segments (i.e. large groups of customers with the same problem and interested in the same solution). Giving our Citibank account team everything that they ask for short-changes hundreds of other large accounts with varying needs, and starts us down the road to custom development. Yet some of Citibank’s demands are, indeed, of broad value to our entire customer base. How to sort wheat from chaff?
The Sales ConversationPerceptive product managers appreciate this critical distinction between single-account-focused and market-focused. And we understand an account team’s urgency – even though we rarely meet most of their needs. Unpacking the spoken and unspoken parts of a typical conversation…
- Major account exec says: “Citibank needs us to implement MCBSP-2017 by December 30th.” (Referencing an imagined new banking regulation called Money Center Bank Security Protocol.)
- Major account exec thinks: “#$%&! We never get what we need from Product, but I have to ask before escalating.”
- Product Manager says: “Hmmm. That’s interesting. Tell me more.
- “Product Manager thinks: “#$%&! We’re overcommitted through 2019, and this team’s last few items were of little interest to the rest of the segment.”
- Major account exec says: “This is really important, and I’m hearing about this from all of my accounts. We could lose the entire banking sector if competitors get there first”
- Major account exec thinks: “How can I communicate real urgency? I need a win here, as my key buyer is questioning whether we’re committed to their success.”
- Product Manager says: “Which other banks are asking us about this? I thought the regulators are still discussing it.”
- Product Manager thinks: “I need to validate myself this with several other account teams in this space.”
- Is this regulation real, which banks will have to comply, and when?
- Will this be a “checkbox item” or strong differentiation for us and our customers?
- Would we really lose a lot of deals (or a few huge deals) for lack of this?
- Could banks implement it themselves, or with non-competitive third-party development partners?
- If we move this into the feature backlog, what does it go ahead of? There’s no white space in the development calendar, so something else gets delayed if we make room for this new item.
- What would success for this project look like? Should this lead to more short-term revenue, or fewer support calls, or increased customer joy, or more effective development processes? This must fit into our product investment portfolio. Because the needs of the many outweigh the needs of the few… or the one.
What About Multi-Account Teams?There’s much less friction with inside sales reps, telesales teams and business development groups who work in volume – handling many smaller opportunities in parallel. These groups typically cover small business customers or the early-stage sales funnel for dozens of mid-sized prospects. They spend a lot of time qualifying accounts – trying to decide if that prospect is a good fit for what we sell, and a likely buyer with approved budget. Great inside sales reps develop keen ears for interest in the product as it exists today, and are ruthless about dropping folks who are unlikely to buy. (“I need to close 12 new SMB accounts this week, and the current caller isn’t one of them. Been a pleasure to talk with him, but moving on.”) This gives them a broad, high-volume view of the market – and a crisp sense of which fundamental benefits/value stories catch the attention of their segment. As a product manager, my decision criteria are closer to theirs and I assign them more segment-wide credibility.
Same Observation about Support TeamsI see the same split among customer success/support teams. Dedicated teams (e.g. 2 folks assigned full-time to onboard and assist Boeing) will naturally generalize Boeing’s problems to the entire market. But pooled tech support reps who take calls from the larger user community will see more representative patterns. How we listen is partly shaped by how these teams are organized. Recency bias is also a challenge. Most support organizations track activity and characterize tickets, so product managers can depersonalize and quantify requests from Support:
- How often does is problem reported? What (average) severity has Support assigned
- What are the three most common implementation or deployment blockers?
- Which help pages or knowledge base articles are end users accessing the most?
- What workarounds are so frequent or frustrating that we train new support reps on them?
- Are some UX/workflow problems costing us so much in support time that we can directly justify a fix based?