These might sounds like generalizations because they ARE! Not all of them might apply to your product and you will probably find at least one counter example. I think for people looking into the different skills to move from role to role, this is a good reminder why you might not necessarily be a great fit even if you think you are the best possible candidate. It always is interesting to read Product Manager descriptions and see that most of the skills are summarized to such a point that you might not be realizing there is so much behind each part of product management. I was one of those people that believed that B2B was the same as B2C but now that I have had experience in both, I can tell you for sure how different they can be. Here is my take on this (with credits to Pragmatic Marketing and Rich Mironov)
- Industry Knowledge: B2B product managers need to understand the language of their product and industry first and foremost and this can be quite a large undertaking that takes time that B2B companies don’t want to have to wait for. Industry knowledge is essential to get the trust of the people inside the organization specially dev and sales. Product managers are expected to be the face of the product, lead innovation and leapfrog the competition. This usually involves being though leaders by talking in industry conferences, user conferences and Gartner/Forrester events. For B2C product management, you can wing it with enough usability/behavioral science aided by some analytics to know your customers. In B2B you have different people playing a part in the sales process, while in B2C the same people who uses is the one that pays, so its simpler in that way.
2. # of Users: for a B2C company to make money it probably needs a lot of users, whereas in B2B, the list of customers can be quite small, and the number of users quite low in comparison to B2C software. in B2B, product managers know and have direct access to users of your software, whereas in B2C the ideal user is harder to pin down from thousands of users. You can have a sample of users which may not be 100% representative of your target customer. I think now however, with user research and usability testing being popularized both in enterprise and consumer settings, the two worlds of B2B and B2C product management are converging.
3. Sales: in B2B sales can exert a considerable influence in the product roadmap. Even if they don’t, dealing with Sales people is not something B2C product managers do that often because the distribution is often done online and/or the sales cycle is a short one. When the sales cycle is long and cumbersome and obviously with larger monetary implications to the salesperson, these folks are often vocal about missing features and things that made them lost that “deal”.
4. Features vs Usability: most B2B companies are concerned about features more than usability. This doesn’t mean they don’t care about usability but I think that given the option, buyers of B2B software are willing to pay to solve a problem or an issue first and then worry if it looks pretty. Of course the tide is changing on this respect because bad experiences can lead to poor adoption but I still think that if a software doesn’t do the basic stuff a company needs, it is unlikely to get picked. On the other hand, the need for specific features often leads to customization for specific clients. In B2C, this is not likely to happen since product managers aim to keep the product simple and have one version for all customers. This customization issues is basically 2 mini issues: figure out when to do one, and when you do it, figure out how to keep this complexity from impacting architecture, releases and the code itself.
5. Price and Power of Volume: alluded to this before, but the price of contracts of B2B even when done on a by month/user basis is still significantly larger than a single B2C transaction. This means that certain buyers or customers have leverage because of the size of the deal. The PM in this case needs to be able to manage and handle this types of relationships, by saying no, by negotiating, by compromising, by playing carrot and sticks, etc so that the product roadmap isn’t reflecting the needs and wants of one customer.
6. Release Cycles and Enablement: I was in a chat with an enterprise software company that talked about the time development decided to go agile releasing every month without letting everyone know. The other people were not happy about and there was a scrambling to get training, documentation and support to learn of the latest stuff and rinse and repeat every month. There is a significantly larger overhead to the company that is releasing enterprise software often. In B2B software, customers do not want change that often, since every release is probably tested in-house before being released to the organization. With SaaS, B2B companies are not getting an option so they take in new releases quite frequently which again implies a larger overhead for them. For customer software this is quite the opposite , frequent, small and sometimes invisible changes are welcomed thereby moving the user in a continuum much like Google and Indeed do.