Feeding the Elephant: Building for Enterprise Customers
In my last post, I told you how to identify the real customers of your software. Now let's talk about what you do if that customer is a large enterprise.
Many development teams think that if they worked for a “real” product company, then they would build a cool product, with features that they knew everyone would want, and the world would beat a path to their door. “Real products predict what the market will want, they build it, and then everyone buys it,” they say. “Better yet, they disrupt the market by building things that no one even knew they needed! Why aren’t we doing that?”
Personally, I can think of one company that worked this way: Apple. And even Apple had the Lisa, an expensive mistake that illustrated the high risks of the “artistic savant” approach to product development. All other development teams have to actually talk to some customers, figure out what they need, and build it. To make things more complicated, the voices of those customers vary widely depending upon the kind of products you’re building. Specifically, there’s a big difference between enterprise software products and consumer products, and the wise product manager will learn how to serve each of them.
Enterprise Software: Serving Sandwiches to the Elephant in the Room
|"So, are we going to talk about me at some point?"|
Since enterprise software is designed to become a vital part of any customer’s business processes, then this large customer will probably tell you exactly what they want you to add to your product in order to make their lives easier. Usually, this request takes the form of, “On the inventory page, I need you to add three fields that are specific to my business, then put in a button that pops up another screen where we can capture inputs for the other system that only we integrate with. How soon can we have it?”
Here’s your challenge: how do you make your largest customer happy while building features that serve all of your customers? Now begins The Quest for the Unspoken Need.
The first step is to start asking questions:
- Where does this feature fit into the customer’s larger business process and environment?
- What are the users trying to accomplish with this feature and why can’t they do it currently?
- Why do they need this new information or functionality?
- What value do they need out of our product at this point in the process? Is it greater efficiency, deeper information, better decision-making, something else?
- Are there any other places where they need the same information or functionality, or is it just here?
- What are the other impacts of this change? Will we break something elsewhere if we do this?
- How would they solve this problem outside of our system? What does the simplest version of this process look like?
- Is this something that only this customer does, or do all customers have a similar need?
In the end, you’re really only answering one question: why is this feature valuable to the customer? Once you understand this, then you’re on your way to solving the problem, either for just the one customer or for everyone.
Hopefully, your deeper understanding of the request will help you design a feature that serves your large client as well as the general population. It probably won’t look like their original request, since you have a better understanding of your product’s capabilities and can design a more elegant solution, but you should also understand enough about your customer’s process to show them how it fits. Meanwhile, you can present the new feature to your other customers to illustrate your ongoing commitment to innovation.
If you decide that this request is only valuable to one customer, then you have to decide whether the benefit is worth the cost. This can be a difficult solution, especially when the elephant is still in the room, but there may be times when you have to say, “This doesn’t fit our product strategy. I’m sorry.” If you decide to go ahead, then it’s time to create a client-specific configuration strategy if you don’t already have one. Design this feature so that it meets the single customer’s needs, attach it to a configuration switch, and prepare yourself for a lifetime of explaining what that thing is doing there as each new developer joins your team. Sometimes you have to feed the elephant.
In my next post, I’ll talk about building for direct consumers.