The importance of understanding use cases for feature adoption in B2B software
Businesses are inherently risk averse - find use cases that solve their challenges
In B2B software, your users are operating their own businesses. They are using your product to help them make an aspect of their jobs easier. They are incredibly busy. Even with the best marketing campaigns and a perfect product, adoption of a new feature might not happen overnight simply because these users are busy and are comfortable with their existing workflows for getting tasks done.
With B2C products, network effects can kick in as a new product goes viral. The cost of trying a new feature — especially if it is free — is low and not risky. But with B2B software, getting a user to change how they are used to doing something is a barrier in and of itself. A mistake can hurt a customer’s business. Businesses are generally risk averse and want to be absolutely certain that a new product or feature will help them.
Where does product management come into play to solve this challenge? When I speak with customers, I do a lot of listening. Overall, I’m looking to really understand where our product currently falls short and how our existing product can help the customer right now. Here are some things I’m listening for:
What about the product overall is really helping customers? What could they not live without?
What is missing in the product that would make them — and lots of other customers — happy and increase their willingness to pay for your product?
Are there any feature requests that are “low lifts” and wouldn’t require a lot of engineering effort, yet add a lot of value.
Is the customer bringing up an issue that an existing feature can directly solve?
This week, I had a call with a customer who is certainly part of the target audience of a feature that was released in Q1, but they have not yet used it. As a PM who worked hard on it, this bothered me!
On the call, I brought up the feature and then just listened as the customer had a realization: there was a particular use case that our feature was designed for. The use case is one that our team had in mind when building the product, but again, adoption does not always occur overnight. The customer plans on becoming a core user of the feature in the coming weeks. Had I not gotten on this call, this realization likely might have only occurred many months from now. Maybe it never would occur at all!
What to plot on the long-term roadmap — and how to design features — ultimately rests on the underlying assumption that customers would love to be able to perform a a certain task using your product so they can accomplish something important to them.
The central point here is that PMs should always speak to their customers and realize that feature adoption is dependent on good product marketing, but also won’t occur at all if the use case isn’t there. The process of understanding all the use cases of a new feature is integral to the product development process.