Is there a difference between developing an enterprise and a consumer product?
In both cases your software product is used by humans, but an enterprise is a legal entity, while a consumer is a person. And the fact that an enterprise is a legal entity makes product management for enterprise products a little different.
It is true that enterprise products are becoming more consumerised as competition and user expectations increase – Slack is a great example of this. The design process for Slack was very similar to the design process for a consumer app: start with the premise that your problem is also a problem for many people, design the app to meet your need, and then figure out how to market it. The key thing here is that Slack is a simple product solving a simple, well-defined, and well-understood problem for a user who has needs which are very similar to the personal needs of the design and development team.
But take another class of enterprise software product – for example, server log analysis for high-volume unstructured data flowing from mission critical cloud-based applications. Here, there is tremendous space for variation in user context and user needs. An IT administrator in the CIO’s organisation would use such a tool very differently from a developer who reports to a VP of engineering. Each audience would need to have their needs (both feature needs as well as UI design/consumability needs) met, or ignored, as a strategic decision by the firm building and marketing the product.
Let’s look at some of the factors you need to consider when planning for enterprise software products rather than consumer products.
Buyer vs User
For consumer products, success is typically about getting users to love your product.
But in an enterprise setting, the buyer and user are often different personas.
For enterprise products, success is about enabling your users to deliver more value to their business by using your software. In an enterprise setting, the buyer writes the cheques, and enterprise users can love the product without ever writing a cheque. Within B2B, there are nearly always multiple buyer personas to be considered – decision-maker, influencer, champion, etc. They will want reassurances around privacy, security, and data management. They may need (or wish for) integration with existing systems, single sign-on and so on. In most cases, B2B products need to be designed from the ground up to support end-user and buyer needs.
Value vs User Experience
As a consumer product manager, you’re focused on building a product that resonates emotionally with users.
In enterprise space, often the primary focus is on improving workflow efficiency with the emotional appeal a secondary consideration. Building new features almost always takes priority over improving the existing user experience. Paying customers constantly ask for new capabilities and additions. 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 worry if it looks pretty later. Although the tide is changing on this respect – because bad experiences can lead to poor adoption – I think if software doesn’t do the basic stuff that a company needs, then it won’t be chosen.
I’m not saying that user experience isn’t an important consideration for an enterprise product manager. With enterprise software you typically deal with large data sets, complex workflows, and interfaces that adapt based on user roles. All of this makes designing a good experience imperative as well as challenging.
Know Your Customers
Getting an enterprise product customer on board is a challenge because typically it involves high switching costs for the enterprise – involving considerations such as configuration, integration, training staff, and process changes – and added business risk.
However once enterprises are on board, product managers have a great opportunity to get speedy customer feedback and validations on features as well as the roadmap – which can be a little tricky in the consumer space. In the B2B world your customer is not a name and number that looks the same as any other. Often, knowing your customers implies having a direct relationship with them and this helps in uncovering the small but critical problems you can solve for them.
In a B2B setting, some buyers or customers may have more leverage than others because of the size of their deal. But you don’t want the product roadmap to reflect the needs and wants of just a handful of customers, so product managers shouldn’t be afraid to say no to a feature request, even if it’s from an important customer with a large budget.
I believe that when prioritizing feature requests from customers and deciding what to build, product managers should ensure that what they build provides a positive ROI for the customer’s business, rather than simply building what customers say they want.
In a successful B2C product, you have (hopefully) millions of customers.
In B2B, you operate with a dramatically different order of magnitude of customer numbers. You might get 1,000 new users a day for a consumer mobile app but 10 new customers a week for an enterprise productivity tool. Product managers have to recalibrate how they study user behaviour, balancing what they can get from user data against user anecdotes. Good relationships with customer success and support teams are a great way for B2B product managers to take the pulse of their customers and get customer insights.
Release Cycles and Enablement
B2B software customers don’t want frequent change, since every release is probably tested in-house before being released to the organisation. Enterprise product managers also need to consider the set of tools / artefacts used as part of the product and manage these too. They need to make sure data migration is well thought out and that new features account for existing functionality. There may be cross-sell/up-sell opportunities post release, needing knowledge transfer to the sales and customer success teams.
Relationship With Sales Teams
Often in B2C, there isn’t a large direct sales team.
An enterprise sales team spends all day talking to customers – they should know the customer perspective inside out, which can be hugely helpful to a product manager. Success in B2B product management is nearly impossible without a good relationship with sales throughout the product lifecycle. But when sales returns to the office with a new client and a list of contractual features to implement, they become the ones leading product development – not the product managers. This can result in a backlog so congested and long that teams struggle to keep up and satisfy requirements quarter after quarter.
To avoid this, I think product managers need to think about sales as another customer – if the sales team’s goal is to make more money, how can product managers help them towards that goal? Are they providing the information that sales needs or are they just repeating the value proposition that someone else thinks sounds good? If product managers take active steps to care for and “feed” their sales teams, they’ll build a much better relationship with them. This relationship opens doors to higher-quality information delivered from the field, and an expectation and understanding that it’s “okay” to defer customers to the product manager since they know their stuff and want the same things as the sales team.
There are a variety of revenue models in both enterprise and consumer products – but the most usual are that enterprise explicitly pays you for a product, and a consumer uses your core product for free while you generate revenue from ads, in-app purchases, or a transaction/marketplace take rate. This has profound implications for product design.
For example, there are enterprise products, such as workflow tools, where your goal may be to minimise the amount of time people spend with your product; you’re trying to help them accomplish a task as efficiently as possible, and you are being paid directly for this. This makes it very different from a product where your effective success metric is the number of ads they see.
If you’re trying to apply product management best practice to your role, or you’re looking to make a switch between B2B and B2C products, then you should keep these differences in mind. However never forget that your users are people, whatever they’re doing. Keep the differences between enterprise and consumer in mind when it comes to product lifecycles or roadmapping, but never stop striving for a great user experience that relieves your customers’ frustrations and adds value to their day.
In the end, good product is good product. It should be intuitive, straightforward, and highly usable. The reality is you’re dealing with living, breathing human beings in both cases so you need to have a product that is actually usable. Good software gets designed in similar ways regardless of who is buying it, or using it. You talk to users, talk to buyers (maybe the same, maybe not) make prototypes, you test your ideas, you prioritise features and try to focus on the needs of your audience.