I’m often asked by B2C product managers how B2B companies are different, or about switching between the two. Here are some thoughts on company-wide structural differences and how we product managers get our work done. It’s a more precise, if less emotional, version of a May talk for Lean Product/UX SV meetup.
What’s B2B? What’s Enterprise?
Broadly, business-to-business (B2B) means building and selling products primarily for corporations and organizations. Business-to-consumer (B2C) targets individuals and families. A useful – if not perfect – distinction, since businesses are collections of people who also buy things for themselves, and some businesses are sole proprietorships or family-run.
Another fuzzy line divides SMB (small/medium businesses) from enterprises. I arbitrarily designate products under $500 as consumables or low-involvement purchases; products between $500/year and $5000/year as departmental or SMB or high involvement for single corporate purchasers. Enterprise generally starts around $20k/year, and really gets going at $50k/year. Understanding where you fit is essential, since it sets up basic revenue math for your product/company.
Christoph Janz has a great post and visual tying a company’s pricing, volume and target audience to its marketing and lead generation models along a continuum. Borrowing his math, there are lots of ways to hit a $5M revenue target:
$50/year/user * 100,000 users = $5M/year $500/year/user * 10,000 users = $5M/year $5000/year/buyer * 1000 buyer = $5M/year $50,000/year/buyer * 100 buyer = $5M/year $500,000/year /buyer * 10 buyer = $5M/year
When sketching out your company, it’s important to guess at your price point, marketing and selling models. $50/year suggests social media and online promotion; $5000/year suggests SMB-style lead gen and teleselling; $100k deals probably need wingtips-on-the-ground to motivate long-cycle enterprise buyers.
Said another way, the shape of your entire company depends on your target audience and price point. B2C, SMB and Enterprise companies not only behave differently, they are structured differently.
Unstated B2C Assumptions
When working on mass consumer products (think FitBit or Facebook or teach-your-kid-to-code toys), we will have large numbers of small purchases — too many customers to know each by name. Some core assumptions:
- The typical B2C buyer is the user. Clothes, apps, binge-worthy streamed dramas and açaí blueberry granola smoothies are (mostly) bought by the person who consumes them – or a relative/close friend with detailed knowledge of the user’s preferences. Product are sized and priced and packaged for easy purchase.
- Enterprises buyers are usually not the actual users, but managers or committees or purchasing organizations or ADHD executives. Buyers tend to have goals/needs (for “safe” decisions, spreadsheet-based ROI, minimizing complaints, or satisfying political stakeholders) that are distinct from the actual end users. No one wants to be called out for mis-spending $125k.
- We can find and interview lots of B2C prospects. If the market for a new home audio speaker or IoT household plant status is big enough to address, there must tens of thousands of potential customers. So we should be able to recruit 40 or 50 willing to share their preferences in return for a $35 Amazon gift card. No matter how lame our paper prototypes, we know that only a tiny fraction of our audience will see them. (And will soon forget us.)
- Enterprise audiences are orders of magnitude smaller, and research candidates are likely to become sales prospects. If my company builds $8M proton therapy cancer machines, there might only be 120 major treatment centers in North America. Talking with 10 Heads of Oncology will be time-consuming, expensive, and could shape their individual impressions of us before our products are ready.
- Rigorous A/B testing is a favorite tool in our B2C kit. Design a change to our new customer signup flow or product-level messaging; deploy to 0.5% of site/app visitors for a few hours; see if those 8000 shoppers behaved as we hoped. Risks are very low, OKRs tie directly to transactional revenue, and the data speak unambiguously.
- A 9-18-month enterprise sales cycle with dozens of touch points (online, offline, demos, colleague referrals, golf outings) makes attribution of any one change very difficult. And 10,000x lower interaction rates means that statistical significance on the pre-sale side of marketing is exceedingly rare. So we need to define quantitative success criteria ahead of experiments to keep ourselves honest.
- Consumers can “buy” before our product is ready. We have lots of techniques to estimate purchasing behavior early in the discovery cycle: sign-ups, pre-orders/crowdfunding, clicks through to fake fulfillment pages, hand-testing a concierge service. If early demand is underwhelming, we can return prepays and move on to our next concept.
- Most enterprise customers have measurable financial or operational goals for our products. So a prospect might agree that “if your tech support chatbot will really cut our live support calls by 25%, I’ll buy it,” but there’s probably a pilot production phase where we have to demonstrate effectiveness. Our stuff has to work before much money flows. And expressions of interest usually include contingencies, technical assumptions, and bizarre bits of buying-committee politics. “I’m very interested” is more nuanced than we’d like.
So I see a distinct set of challenges and (therefore) required skills for enterprise product managers that are less important for B2C and low-end SMB product managers.
1. Long Sales Cycles, Weak Attribution, Few Data Points
As noted above, enterprise sales may take 9-18 month to close, with dozens of interactions through many channels: social media, webinars, in-person meetings, drip email campaigns, peer references, Gartner/Forrester reports, business press coverage. With only a few dozen new sales per quarter, we can’t definitively isolate the contribution of each touch.
Vignettes and third-hand comments dominate discussions, with a heavy dose of recency bias. This is reinforced by each functional group’s natural tendency to celebrate its own work. (From social team: “4500 likes and retweets of our latest post!” From analyst relations: “We’re Visionaries in the latest Magic Quadrant!”)
What to do?
- Personally talk with a lot of customers: face-to-face or screen-to-screen. As product managers we need to talk directly with enough customers/users/prospects to identify mainstreamers vs. outliers. (“If I hear very similar needs from 6 or more people…”) And in enough depth that we truly understand market needs better than anyone else in the company. (Not just from surveys, or non-product researchers, or industry gurus, or data sheet copy.) Every indirect source is inherently biased and somewhat self-serving. I push my enterprise product managers to do 2 or 3 interviews per week, excluding sales calls: frequent enough to form our own semi-quantitative sense of what’s really happening. This may consume 7-10 hours/week, so I need to make this an ongoing top priority.
- Dig deep with interviewees on their problems, motivations, how they quantify value or success, buying processes, alternatives they’ve explored and discarded. 45 minutes of (mostly) listening, rather than 10 minutes of checklist questions and pitching. Fishing for fresh insights and surprises. We need to uncover the truth, rather than prove to ourselves how smart we are or that all of our products are above average.
- Sort customers into useful segments based on observable criteria, and share those segment definitions widely. Product managers deal in segments, not accounts, so we need clear qualification criteria. (“Prospects wanting operational savings need our whole feature set, so are much more likely to buy than those just looking at our security features.” “Our Silver package is the best fit for mid-sized manufacturers using these two CAD/CAM systems…”) Sales teams love when we point them toward the right customers.
- Use current customers as a proxy for new ones. While data on prospects may be skimpy, we have tons of insights into current users and buyers. What can we learn about how our most successful users behave, and can we encourage that with prospects or unengaged users? If retention is highest among dashboard users, can we make sure trial users see that feature? Which industries bring in the most revenue per seat (and why?), so we can evaluate new deals based on likely outcomes? Which of last year’s yuge deals never closed, and look suspiciously like this year’s funnel zombies?
- Hire outside experts for win/loss and churn analysis. Sales organizations want to do their own win/loss interviews, but customers are naturally hesitant to tell rejected salespeople the unvarnished truth. Plus, reviews of our sales process reflect badly on individual account teams, so self-evaluations highlight pricing or product/feature problems. Objective outsiders are paid to uncover the ugly truth.
2. Buyers Are (Mostly) Not Users
The bigger the sale, the more complex a corporation’s buying process. Think committees and objective selection criteria and formal justification and CYA. Where users want great applications and intuitive interfaces, buyers want clear ROI and minimal integration effort.
What to do?
- Say ‘buyer’ or ‘user’ instead of ‘customer.’ Words matter, and more specific words reduce confusion in sales kits, user stories, pricing docs and user journey discussions. For hospital software vendors, we might say ‘patient’ and ‘doctor’ and ‘member of software purchasing committee’ instead of ‘customer.’ For airline reservation systems, perhaps ‘traveler’ and ‘booking agent’ and ‘airline CFO.’ Not having some specific group in mind suggests that we’re confused – or wasting our time.
- Interview both users and buyers. We can’t position or sell or intelligently prioritize a backlog without knowing what each audience wants. And then we have to balance two independent – or opposing – sets of preferences.
- Plan on two sets of benefits/features/success criteria. Bank tellers and bank branch managers care about the efficiency of our branch software; bank finance committees want an ROI based on staff reductions. Software developers want tools that provide lots of freedom; VPs of Engineering may want to enforce common processes across teams. So we partner with Product Marketing to produce separate user-side evaluation guides (emphasizing joy and productivity) and buyer-side scoresheets (computing ROI).
- Don’t obsess over titles. One company’s ‘budget approval team’ is another’s ‘capital allocation committee.’ Some Directors of Manufacturing manage 10 employees while others manage 10,000. Expect that roles, titles and responsibilities are elastic.
3. Understand the Organizational Incentive for Sales Escalations
The pipeline at enterprise tech companies is lumpy: five big deals might make up 20% of this quarter’s revenue. So your CEO knows every one of those big deals by name, and often asks your VP of Sales how to help close them.
And enterprise tech companies hire high-powered sales teams. These are expensive, talented, self-assured, highly competitive folks who make double what senior product managers make. We hire and train and promote and reward them to close individual deals, not to ponder whole markets. Key skills are persistence; identifying the real buyers/approvers at a company; reframing benefits to match selection criteria; hypnotic persuasiveness; and escalating above anyone who’s not helpful in the sales cycle. Successful salespeople go to President’s Club in Fiji; unsuccessful ones get to work at another company. Coffee is for closers.
And every enterprise customer has just a few special requests. So we expect good sales teams to bring those requests to product management, then quickly escalate when we (always) decline or defer. Yet somehow, we’re surprised when they apply their core skills (persistence, focus on closing, identifying decision-makers, escalation)to take the issue over our heads to the C-Suite.
What to do?
- Don’t be offended or surprised. We love our sales team, which is responsible for bringing revenue in each quarter, even when they frustrate us personally. Most product managers would fail in sales roles, just as most reps aren’t well suited for product management.
- Prepare, prepare, prepare, prepare, prepare. Escalations happen every few days, so have a plan. Immediately warn your boss, Head of Product and VP Engineering of likely incomings. Include a bit of background and rationale, since most sales-side escalations are context-free. (“BigCorp needs X.”) Train your execs to laugh when they hear “How hard could it be? Probably only 10 lines of code.”
- Frame all requests as EXCLUSIVE OR trade-offs, and identify which executives own the pain of those trade-offs. There are never any free development resources, so every new item delays something already committed. (“If the team builds a custom API for BigCorp, we risk slipping v6.0 which is slated to drive $35M in new revenue and fix a bug that closes 420 support tickets.”)
- Build trust and working relationships with Sales. Sometimes they are right, sometimes we’re right. Have a drink, talk about kids or sports or movies, and discover that neither of us is evil. (Sales has bigger expense accounts, so let them buy.)