Three Reasons Product Planning for Enterprise Needs to Be Different from Consumer
Hint: It’s all about the buyer
Experience is a great teacher and I’ve picked up a few pointers over the last two decades, leading enterprise product teams at every stage of development from early startup phase to the $100 million revenue mark. When it comes to product planning for enterprise products (ones typically sold through field sales), one of the key lessons I’ve learned is to respect the distinctions that make enterprise different from consumer. I’ve watched too many enterprise product teams get into trouble by ignoring those differences. Here are 3 ways you can avoid making that same costly mistake.
1. Listen to your buyer, not just your user
What’s different: Your user doesn’t write the check
This can’t be stressed enough as it is central to what makes selling into the enterprise different. For consumer products, success is typically all about getting users to love your product. For enterprise products, success is about getting your users to deliver more value to their business by using your software. That is why buyers write the check. Enterprise users can love the product without the buyer ever writing a check.
What to do: Opportunity discovery with your buyer
I’ve found that enterprise product teams often don’t really listen to buyers. That’s not because they don’t know they should, but because its hard. Here’s why
- Buyers are hard to access. We’re typically talking about execs who are way over scheduled and just don’t have time to talk with you.
- They are quicker to recommend solutions than explain their problems (You don’t learn much when someone says, “I need AI.”)
- Their solutions are typically wrong (AI may have nothing to do with their real problem)
- You wind up flooded with feedback from users who say they are speaking for your buyers (Perhaps they do, but they often propose the wrong solutions).
At Lithium, we hosted what we called opportunity discovery workshops with buyers. We got execs to attend because they wanted to to have a say in driving our larger strategy for improving their business as well as network with their peers. At Tealeaf (where I worked, prior to Lithium) we often invited outside speakers to talk about topics of interest. Whenever possible, we would include prospects as well. Our sales teams initially resisted the workshops, but they soon realized these conversations strengthened our relationships with customers. They also provided a forum where our buyers could share key insights and surface problems.
The focus of the discussion would be around understanding the challenges in their business (not around the solutions). Sometimes the discussion would pick up on topics that came up at earlier sessions or from win/loss analysis. Other times, it would be about something new. Some of the best conversations arose during coffee breaks when customers buttonholed each other in the corridors. We would do our best to try and understand why other solutions had not worked and how we might overcome their challenges. Ideally, we would come out with an understanding of potential use cases needed to address these problems — not necessarily solutions, mind you, but approaches to kick off the process of product discovery.
An example: Pain storming workshop
At Lithium, we would do workshops with our buyers who were leaders in customer service departments and spend a full day doing “pain storming exercises”. Through exercises that helped them clarify their pain points, we learned that their priorities were very different from those of our users. The latter were pushing for features that helped them better manage all the customer service questions coming in through our product. But the buyers were more concerned that their consumers were shifting channels (from asking support questions on communities to channels like Facebook messenger) and that triggered worries about scaling. They wanted those new channels to scale without problems and wanted us to help them. With this extra context in hand, our product discovery sessions with users completely changed. While the sessions still focused on what was needed to deliver great products they would love, the conversations were closely aligned to our buyer’s business priorities (the channel shift).
2. Focus on demonstrating value, not user experience
What’s different: Software is purchased before it’s really used
The enterprise software buying process is very different from consumer. It typically involves higher switching costs — involving myriad considerations touching on configuration, integration, training staff, process changes, etc — and added business risk; to put it bluntly: business goals are dependent on your software and if it fails, they fail. These challenges make it hard to really use the software in advance of purchase.
Instead, enterprise customers often require long due diligence processes to evaluate and decide on enterprise software (trials, pilots, RFPs, references, analysts, etc). Business models like freemium and “land & expand” can help address these challenges. But they are not always available — or available in only a limited way for many enterprise offerings. What’s more, this due diligence process can put too much focus on features and you risk winding up in situations where sales teams are pushing for just one more feature to win a big deal.
What to do: Demonstrate value with reference customers
References validate your use cases and demonstrate how your product delivers value to the business buyer instead of focusing on features. These use cases should be central to your selling motion including how customers trial your software or how you demo it. I place the importance of these references over almost everything else — consider basing part of your product team bonuses on them.
When use cases become the focus of how you sell, you can set the buying criteria and ideally define your customer’s RFPs. They put in context what features are needed to deliver value as well as which are not. They also help you get ahead of one-off feature requests to win deals by setting the context. Remember this: buyers care less about features and more about delivering the value from your product with minimal risk to their business.
An example: The lighthouse program
At Lithium we created what we called a lighthouse program. We signed up over 10 representative customers with the buyers heavily involved with a real commitment to the program. It started with opportunity discovery (way before development) and then kept them involved until we could demonstrate value (often beyond a product’s release). The buyers defined our objectives for showing value and signed their teams up to work with us throughout the development process to meet those objectives. This hands-on approach helped generate more visibility around the larger goals and enabled us to continue to adjust features to meet these goals. Best of all, we were set up to have references when we met this objective.
3. Partner with customers on objectives, not features
What’s different: Your customers expect you to partner with them
Switching vendors can be costly and destabilizing and most enterprise customers would prefer to stick with a provider, but it comes with a price. They need to see that you will be a good solution for them in the long term as well as the short term. They need to understand where you are going.
Customers also want to know your plans because they can not move that quickly and need to be prepared for what is coming. For example, Lithium’s support of additional social channels (such as adding wechat) had implications for their staffing plans, while adding support for new European privacy regulations had implications on their compliance plans.
What to do: Communicate priorities and objectives, not features
You can find a lot of good material on the benefits of outcome-oriented roadmaps to communicate priorities instead of just providing long lists of features. This is critical in the enterprise where you need to communicate to your buyer, and your buyer cares about outcomes, not features. Use outcome-based roadmaps to do this.
Communicate your priorities and where you are looking to invest, such as how much you’re investing in improving your existing use cases (also being clear about how to measure improvement and what to expect), versus going after new opportunities (like international expansion). Remember, your buyer cares more about an objective of “reducing down time by 30%” than the features needed to get there such as by “adding a new failover layer”.
An example: Communicating support for a new buyer
Become buyer-centric in enterprise product planning
If you want to deliver a great product that wins its market, then focus on becoming buyer-centric in your approach to enterprise product planning. This approach has served me well and has helped my team deliver some great and successful products over the years.
These three key differences will help you to navigate that transition: You need to understand your buyer; you need to sell to them by providing value; and you need to partner with them to retain them for the long term. If you keep these points in mind as you look to apply best practices around product planning to your product, you can’t help but become more buyer-centric.