How to Avoid the Per-Customer Feature Trap
Imagine a vehicle that can haul 2 tons, seats nine comfortably, gets excellent gas mileage, costs about $19K, and does 0–60 in under 4 seconds. Sounds impossible, right?
That’s because it is.
Each of these features is trying to serve a different customer.
As product managers — especially when creating business products — it’s tempting to build features requested by customers. We sometimes even call this being “customer-obsessed.”
It’s easier to justify a feature when you can attach an impressive customer name. “The big fruit company in Cupertino requested this feature for our networking software — we have to build it.”
Maybe you need a quick win to hit your adoption targets. We’ve all been there.
But ultimately, building features on a per-customer basis is a trap.
Because now you have features with low cross-customer usage. If you have to build custom features for every new customer, you will have to dedicate resources to each. The product maintenance will be very high as you have to keep each of these capabilities working, even as you extend the product to satisfy more customers.
These costs can’t be amortized across multiple customers and thus becomes intractable over time.
You begin to wonder if you actually built a “product” at all.
What to do instead?
First of all, make sure you are building a product. It may seem obvious, but perhaps in truth, you are building custom solutions. There is nothing wrong with this. However, you must ensure your business model follows this approach.
Custom solutions should be charged in a very different way because you are not building for a large future market. You are creating something for a “market” of one, or perhaps a few at best.
Think about the broader market you wish to sell into in the future. What features apply to the vast majority of buyers? What capabilities are “table stakes” and required to sell anything at all?
Which broader market need can you address with the least investment that will give you a starting basis upon which you can build your product?
If you were to survey all these buyers, you would likely see a relatively small core set of capabilities and a long tail of needs that apply uniquely to a particular set of customers.
So the goal is to 1) build the minimum set of features and give you 2) access to the largest pool of adoption.
To address the long tail, we can think of our product as a “core” with “extensions.” The core becomes the essential capabilities universal to the buyers, and the extensions become long-tail requirements that need more customized solutions.
Going back to our vehicle example, we never defined the core. We know it’s a vehicle with an engine, wheels, steering, and hopefully brakes. The specific use cases of hauling, people-moving, economy, and racing, all require extensions to the design that allow it to serve these purposes better.
Thinking through your design and by understanding the core and extensions will allow you to design a “platform” upon which extensions can stand. Perhaps this even creates an opportunity for an ecosystem to form around your product. Customers may be able to build custom extensions or purchase them from a third party.
Your product cannot ignore the long tail, however. Doing this will not be a product either, but a useless core-shell that has all the commonalities, but no one can use.
Find a niche you can serve completely. The niche should be broad enough to have multiple buyers. But small enough that the tail of customization is tractable with reasonable effort.
Building a feature per niche is not the same as a feature per customer.
Once you’ve established your product into this niche, you can look for additional narrow sub-markets to serve, building on your core capabilities. Once the core is strong enough and designed for an extension, you can tackle multiple niches simultaneously.
Perhaps one of the hardest parts of keeping the product focused on the broader market is having to say “no” to customers. It’s never easy. Ideally, you find places you can say “yes” by sharing your product roadmap transparently and allowing them to upvote features. Setting up expectations on how you build your roadmap and how you handle feedback is important too.
When customers tell you what they want, listen. But don’t stop there. Look for patterns and commonalities before you commit. Don’t associate product features with specific customers, no matter how impressive. Evaluate them based on their long term potential to build your business.
One caveat worth mentioning. Here in the real world, you may not have the luxury of saying “no” to every customer.
Sometimes it’s a make or break situation, and the pressure is too real. Or you need the exposure of a great new logo on your website. There are always exceptions, and they should be considered and taken when it makes sense.
Just don’t make it the rule.
Defining products that appeal to a mass audience is not easy. It’s tempting to build features that you know someone wants instead of searching for less apparent capabilities that lots of people might wish to.
Ultimately avoiding building features per customer means looking at the bigger picture and staying true to the broader needs and your vision for the product.