Top Three Guidelines for Releasing an B2B Product or Feature
Welcome to the world of enterprise products where there are more dollars per customer and more risk per feature than in the B2C world, and your customer base is typically a fraction of the size compared to that of a retail or social consumer focused product.
As I’ve ramped up in my product manager role at PROS, I’ve spent easily over 100 hours of enterprise product research I’ve realized that successful enterprise products and product feature releases tend to follow the same three guidelines to ensure success for the product, business, and last but definitely not least, the customer.
I will be sharing those top three findings and discussing in detail how you can successful ensure that your product or feature follows these guidelines.
Backwards compatibility
Will my feature break anything that my customers are currently using because of the need for newer technology or parts? B2B customers are much more sensitive to feature or product changes than a mass consumer (B2C) based application. This is because an enterprise product is a very large investment, and in the eyes of the purchaser or customer, every single one of your features affects their company directly and sometimes are tied to revenue and income metrics that could be in the millions, so in terms of cost per feature or cost per change, the impact is much greater.
The more convenient a product organization can make changes for their customers, the more likely a customer can focus on what really matters (the problem they bought your product to solve) and the better they will be off.
Between Comfort-ability
How comfortable will my customer be with using this new feature given the context of the overall product and it’s current experience?
When there is a new feature being introduced to a new application, it should be done so with a very agile and iterative process. For example, let’s use the idea of improving a search mechanism for FAQ and support documents within an enterprise product. Let us further assume that the end goal is where this search mechanism is powered by a very complex Deep Learning NLP (Natural Language Processing) type of model leveraging conversational AI to help users discover content that is relevant to their search by almost talking to the website.
If a search mechanism is going to do suggestions, then you might want to start off by using a simple search algorithm that prescribes search results having the greatest matching key words score or percentage and producing that matching score to the user. Once that has been introduced, then it’s time to gauge customer feedback and iterate further towards the end goal.
The next iteration could be improving the search mechanism further by improving the matching algorithm, and doing some A/B testing between user search journeys.
Eventually you can introduce the likes of a ‘Smart AI’ assistance. We’ll call this AI bot Thomson for now. Introducing Thomson to users might be as simple as swapping out the header ‘Search Results’ with ‘Thomson Recommendations’ and placing a robot emoji next to ‘Thomson’.
Finally, this search bar can turn into a conversation search bubble and progress in an example manner such as:
Thomson Bot: Hi this is Thomson, and I’m here to help you find help.
Customer: Great, Thomson, I am getting an error code when I try to update some settings
Thomson Bot: Ah, I see, could you tell me exactly what settings you’re trying to update?
Customer: Refresh frequency and Error Acceptance Threshold
Thomson Bot: Okay, let me take a look at the last error your application received from settings related to those ones, and I’ll give you some suggestions.
Forward causality
This is an important step that enterprise B2B products leave out due to the nature of the feature requests or customer-revenue model. Typically when a feature request comes in, it may span across a few large customers that make up a significant portion of the companies revenue. When this type of feature request is put through the hoops of flames for approval, it’s typically already met with a head nod from top executives and leadership. My suggestion is to go for a CI/CD approach to product.
Once the feature is launched, since there were so many dollars and highly paid executive sponsorship that the measure and monitor portion of a feature release is never done. To ensure that the feature was truly enhancing and beneficial to a customer, we can start off by ensuring that we understand their ‘why’. Once we have that and we build and release the feature, we need to understand if the ‘how’ is sufficient and truly solves the problem, but at the same time helps us achieve business and financial goals. Metricizing and implementing ‘SMART’ goals will help product teams better understand the impact that they have on the product, the customer, and the business overall.
As behind-the-scenes measurement takes place, there should be some customer and user outreach to determine feedback on such a released feature, and understand if the customer truly feels that the feature or enhancement has made their lives easier and added a spark to their usage. Splitting feedback requests between high touch users of the new feature, and low touch users will give you an overall feel of what your customers/users really think.
