Twitter Facebook Linkedin

Feeding the Elephant: Building for Enterprise Customers – By Jason Cole

To share...Tweet about this on TwitterShare on FacebookEmail this to someoneShare on LinkedInShare on StumbleUpon

Author: Jason Cole, Senior Technology Executive

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

Enterprise software is designed to serve large customers, which naturally leads to customer concentration. Every enterprise or B2B software company that I’ve seen have a few large customers who drive a majority of revenue and therefore carry outsized influence in product decisions. While many companies try to diversify their customers to mitigate this risk, if you work in enterprise software then you’re likely to find yourself, notebook in hand, attending a catered lunch with the elephant in the room.

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 we begin 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.

To share...Tweet about this on TwitterShare on FacebookEmail this to someoneShare on LinkedInShare on StumbleUpon
Jason Cole

About Jason Cole

Jason Cole has spent the last 20 years helping software and technology startups scale and achieve rapid, sustainable growth while creating excellent work environments. He has a passion for building high-performing teams and great software products and for lifting up the next generation of entrepreneurs. He is a mentor at Boomtown Startup Accelerator in Boulder, where he helped design and run the product/CTO track in their 12-week program.

| View