How B2B and B2C Product Management Differ
Product management roles vary across companies as a function of many different aspects, for example company size, culture, or historical context. One important factor driving differences in the role of product managers is whether the product is B2B (with businesses as customers) or B2C (with consumers as main users / customers). This delineation is of course imperfect (technically Facebook is a B2B product...), but since it fundamentally impacts some of the responsibilities of product managers, I wanted to highlight some key differences, having worked in both contexts.
One big point up front: it used to be that B2B meant that user experience didn't matter as much. What mattered was that you convinced the person holding the purse strings to buy your software, even if the people who had to use the software groaned about the bad usability. In the last 10 years, this has changed with the trend of the “consumerization of IT”. Business users demand a great user experience, and with web and app based software that is easy to buy with a credit card and deploy independently of an IT department, a whole world of B2B software targeted at bottom-up adoption and viral growth has sprung up. Bottom-up adoption, of course, works only if people actually want to use the software, which requires a good user experience. In summary, usability and user experience is no longer a differentiating factor between B2B and B2C.
However, there are some important aspects that continue to be different—although over time, these may continue to blend more into each other.
Customer / user acquisition
One of the big differences between B2B and B2C tends to be user and customer acquisition. Although virally adopted self-service B2B software has started to blur these lines, by and large, B2B technology companies will have a sales team that is responsible for converting new customers and increasing revenue. Depending on the model, the sales team may focus more on inbound sales or outbound sales or account management. The marketing team in B2B companies is more about positioning, messaging, and producing collateral for sales (material used by the sales team in convincing potential customers to buy).
B2C companies, on the other hand, will often rely on paid user acquisition through performance marketing. This means that a performance marketing team buys and optimizes ads on Facebook, Google, and other platforms, driving new users to the product that are likely to convert to customers. Most B2C companies do not have a sales team, performance marketing is part of marketing (or a dedicated growth team).
One implication of this is that the role of stakeholders inside the company is different for B2B and B2C product managers. B2B product managers need to understand the sales process, how leads are generated and move through the pipeline, and what role the sales team plays. The sales team is also an invaluable source of information since they interact directly with potential customers and can help understand their needs and problems, thus highlighting potential for the product to improve. Of course, this should never be acted on without reflection. Sales teams might be quick to say “we would be able to sell to company X if we only had feature Y” but it is not guaranteed that that sale would happen, and even if it was, feature Y should only be built if it is in line with the product direction and not needlessly adding complexity. A better way to use sales input is to understand the underlying problems that the product isn't currently solving, and then decide whether a scalable solution to these unaddressed problems might be implemented in the product.
In B2C companies, the team responsible for user acquisition mostly does not have such a direct connection to customers. The marketing team might be conducting market research, but that is no better than the research that the product team could conduct.
Due to the reliance on performance marketing, B2C product managers will often have to have a deeper understanding of adtech and how data needs to be captured in the product and fed back to advertising platforms such as Google and Facebook in order to optimize advertising spend.
One interesting aspect of user acquisition that isn't so different between B2B and B2C is the increasing tendency to strive for viral adoption. Viral adoption means including features in the product that drive users to share and invite others into the experience. While viral growth was originally more of a consumer mechanism, it has made its way to B2B as well—for example, when a Zoom customer has a video call with someone from another company not yet using Zoom, or when someone adds external participants to a Slack group to coordinate with a partner or supplier.
Customer support, customer success, and professional services
The role that “after-sales” customer facing teams play also differs between B2B and B2C. For B2B products, the sales team may stay involved with the customer in the form of account management. In addition, there might be customer success and professional services teams that establish a relationship with the customer (either paid for separately in the case of professional services, or as part of the product contract in the case of customer success) to ensure that the customer gets the most value out of the product.
In B2C companies, customer support and CRM contacts to users tend to be much more transactional—outreach happens in the form of big automated campaigns, and the key goal of customer support tends to be to solve the customer's problem quickly and then move on. B2C companies have much less of a true, bi-directional “relationship” with their customers.
The reason for this difference is of course mainly the difference in contract value: consumer companies tend to generate far less revenue from each individual customer. B2B companies usually have fewer customers, each paying more. Of course, each customer might have many users. For example, the monthly pricing for an individual Google G Suite business user ($12) isn't so different from a standard Netflix subscription ($12.99), but each G Suite customer will have tens or hundreds or thousands of users.
An effect of this on product management is that in B2B companies, customer success and professional services teams can—like the sales team—help shed light on how customers are using the product, what specific pain points and unaddressed needs are, etc. In B2C, customer support often only has visibility on problems with the current product, including bugs. While that is of course relevant information, it has to be put in perspective. Due to the lack of a real relationship, many challenges that customers have with the product will go unnoticed and unreported—the customer will simply stop using the product and churn.
Feature requests, customization, and product roadmap
Another key difference is the role that feature and customization requests play in B2B. These can come from both the sales process (“we are not going to buy the product unless you build feature X / integrate with our existing tool Y”) and existing customers (“improve feature Z or we are canceling our contract”).
Now, of course, customers request features also for consumer products (just think of the edit feature on Twitter, or the long demands for a Facebook “dislike” button which led to the development of Reactions). The key difference is again that B2B products tend to have fewer customers, each with higher revenue. Therefore, any individual customer carries more weight. Some big customers might put the company at risk of going bankrupt it they were to churn. In addition, the fact that there is often a sales process in which the potential customer and the sales team talk and evaluate the product gives potential customers an inroad to making these requests.
As mentioned above, this can be beneficial in terms of keeping a pulse on customer pain points and needs, but it can also be really dangerous. Just building requested features will increase complexity and reduce capacity to follow the product vision. Even worse are customizations that are specific to one customer. These have the same drawbacks as other feature requests, but the benefit only accrues to one customer. In the early stages of a startup, agreeing to some of these customizations might be necessary to win marquee customers, but they should be avoided as much as possible (unless that is the business model, but in general, the trend in B2B software is away from these customized solutions).
Lastly, in B2B products, there is often an expectation on the side of customers and sales teams to have some level of visibility on the medium (or even long) term roadmap. Potential customers might want reassurance that a certain functionality they would like will be implemented by a certain date before they sign a contract. These kinds of commitments are difficult and dangerous for product teams that want to continuously discover the best way to deliver value to customers and business, but they can be unavoidable in the B2B context.
It is a key challenge for product managers in the B2B context to navigate the fine line between enough visibility for customers and sales teams on one hand and enough flexibility to be able to deliver the highest value product improvements and killing those ideas that fail to deliver value on the other hand. Most product improvement ideas fail, and the fact that you had put something on a publicly visible roadmap doesn't make it less likely to fail. You might have to kill or iterate on some features you had promised to customers if they turn out to not deliver the value you hoped.
Contact to customers
As mentioned above, B2B companies can use their sales channels as a means for the product team to talk to customers. Since customers are used to a more high-touch relationship with solution providers, this is a great way to build relationships that can be used in product discovery.
In the same vein, the entire field of customer development (popularized by Steve Blank in his book “The Four Steps to the Epiphany”) is much more readily applicable to B2B than B2C. The often-repeated advice for customer development is to find a set of potential customers who have the pain that the product is attempting to solve to such a degree that they've already “duct-taped together” a makeshift solution, and then use them as a set of core customers to develop the value proposition of the product. I find that advice to be much more applicable in the business context.
In B2C companies, you will far more often have to run dedicated efforts to recruit participants in user research, or use external services or agencies for this purpose.
Customer stakeholders and their requirements
By and large, for B2C products, you have one type of stakeholder to consider on the customer side: the user is also the buyer. There are small exceptions, like family subscriptions or parents buying products for their kids, but even those cases are relatively simple.
In B2B, it's far more complex. It used to be that the buyer was a decision maker in the IT organization and the users were different from the buyers. The above-mentioned consumerization of IT means that today, buyers are more often also users of the product (in the case of a department head buying software for their team), but there are still other stakeholders to consider. IT, even if they are not in the buyer role, might be concerned about security and integrations with existing application infrastructure. Legal might be concerned about compliance with industry-specific regulations. HR might be concerned about how employee personal information is handled. Senior management might wish to access summary information across their entire company. Finance might want to audit usage and have transparency on costs.
While the consumerization of IT has simplified initial adoption and thus lowered the barrier to entry, if your product is to be more deeply adopted especially in bigger companies, you will need to understand these stakeholders and their needs and possibly take them into account in product development (and trade them off against each other). It's not always easy to say whether it's better to improve the product for end users, increasing the value delivered, or build some enterprise features opening up a new segment of customers.
Willingness to pay
Another key difference in terms of business viability is customer willingness to pay. Firstly, from my perception, there is more of a general acceptance of paying for digital products in the B2B space than in the B2C space—consumers have come to expect a lot of digital services to be free, driven by the vast amount of free or ad-financed content on the internet.
Even where there is willingness to pay, in my opinion, businesses tend to evaluate prices more from a rational, benefits based point of view, and consumers more from an emotional, analogy based one.
What do I mean by that? For businesses, a software or technology buying decision comes down to a business case in the end (it might not be explicitly calculated but it is most of the time at the heart of the decision): do we expect to reap larger benefits (increased revenue or reduced cost through higher productivity) from this product than we pay (both payment to the vendor as well as integration, maintenance etc)? If so, we should buy the software.
For consumers, in the other hand, there often isn't a benefit that's measurable in monetary terms, so the decision is based more on whether or not the price “feels” right. Is this more or less expensive (and more or less valuable to me) than my Netflix subscription? Than my morning coffee? Than my gym subscription? In B2C products, it's often good to call out these comparisons explicitly to anchor the potential customer's perception of your price.
Empathy and the empathy trap
In B2C companies, it is often easier to empathize with customers. After all, your customers are ordinary people like you. For B2B products, customers and users are multi-faceted and with very different contexts in terms of the content of their work, their organizational structure and culture, the rules and regulations, etc. It generally requires a lot more conscious effort to build up empathy with customers and users in the B2B space.
On the other hand, this more natural empathy on the B2C side can lead to an empathy trap, where product teams forget that they are not their product's target audience. As an example, at 8fit we are building a fitness and nutrition app that aims to be accessible to a large audience, especially people who are not currently exercising or paying much attention to their nutrition. The people on the product team, however, tend to be passionate about fitness and nutrition and therefore have higher levels of fitness and knowledge about fitness and nutrition than our target customers. That's why it's a trap to think “I'm a consumer, so my own needs and pain points are a good proxy for our customers' needs and pain points".
Whether you are trying to break into a product management role or thinking about switching from B2B to B2C or vice versa, I think it's good to understand some of these difference. Even some of the product management content like books or articles is often best understood if you know whether the author is speaking from a B2B or B2C perspective. I hope this article was able to shed some light on a few of the practical implications.
I hope this article was helpful. If it was, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.