Configuration vs. Customization
Product managers who build B2B products have all faced the problem before: a large customer needs the product to work in a particular way that isn’t currently supported.
So, what should you do next?
Before we actually answer that question, let’s first look at the different general strategies available to you when a customer makes a feature request for a B2B product.
You have 4 strategies:
- Build globally
- Configure
- Customize
- Punt
Let’s talk through all 4 of the above strategies, noting their strengths and weaknesses. Then, we’ll dive into how to make the appropriate decision, based on your situation.
Building a Global Feature
In B2B, your customer knows how to run their business much better than you know how to run their business.
Therefore, much of the time, their feature requests will make lots of sense across your entire user base – especially if your customers are leaders in their industry.
In cases like these, where your customer brings you a fantastic idea that scales across your user base, you can implement the feature globally – that is, you build it to work a certain way, and expect that single way to work across all customers.
As an example – one of my customers was incredibly vocal about adding a new piece of information to the automated email notifications being sent out to their users.
As we dug deeper into the pain point they were trying to solve, we found that this pain affected all of our customers, and that their proposed solution really was the highest-impact and lowest-cost way to solve the pain.
Therefore, we added that new information to those email notifications, and released it across our customer base.
Pros of Building Globally
When you decide to build out a feature for global usage, you only ever need to build it once. That is, you don’t need to maintain multiple versions, and the test plan is quite clear since there is only one path available.
The other benefit of accepting a feature request as a global feature is that it demonstrates to customers that you’re actively learning from their needs and pain points.
Remember, in B2B, when customers buy your product, they’re not just buying the product as it stands today.
They’re also buying into the product roadmap and into the vision – and having a say in the roadmap is incredibly valuable for customers. It’s a key selling point.
Cons of Building Globally
If you don’t do the proper research and truly validate that your others customers need the same feature, you run the risk of building a “global” feature that will only be used by the one customer who asked for it.
That’s a huge risk to take on, for a couple of reasons.
First, you’ve sunk all of your time and resources into delivering a feature with low impact.
After all, impact is measured by “depth of pain solved” times “ of users affected” – if you’re only affecting one of your customers, you’re not making a large impact.
Second, if you release a global enhancement that only one customer will use, you will anger and disappoint your other customers.
That is, they will wonder why you decided to build for that particular customer instead of for them.
They will not appreciate the additional product complexity that you’ve introduced into their lives, and they will feel unappreciated and unheard.
Most dangerously, you may create an internal culture of “build everything that a customer asks for”, instead of “dive deep to solve for actual customer pains.”
Configuration
What is configuration?
Configuration is the creation of a feature with multiple options available.
Here’s a consumer-facing example – you can configure your Gmail inbox so that you can filter out emails into Social and Promotions tabs, or you can keep them all within your primary inbox.
A configuration requires some sort of interface for users to be able to actually set up the configuration to their liking.
Let’s dive into how building configurable features can be a winning strategy, and the caveats that come with building configurations.
Pros of Configuration
In B2B, you’ll work with customers who run different kinds of business models. In many cases, you won’t be able to find a one-size-fits-all solution, and so you can’t build out a global feature.
The key benefit of building configurable features is that you can support distinctly different kinds of customers and users.
For example, Salesforce has lots of user permission configuration available, which enables different kinds of businesses to grant access to their employees in the way that they choose. Some businesses give all employees all access, and others are much stricter with data access within Salesforce. Configuration enables this flexibility.
Furthermore, I can’t tell you how many times I’ve built a configuration for a particular purpose, just to find that it was then co-opted for a different but equally valid reason. Customers are creative, and they’ll figure out how to use your existing configurations to better suit their needs and processes.
Configuration is better than re-building the same feature each time for slightly different use cases, because you prevent duplication of code.
Remember that when you duplicate code, you wind up needing to keep all of the pieces of code in sync over months and years, and that it’ll likely breaking down.
Through configuration, you and your team can maintain all of the logic in one place in your code.
Cons of Configuration
Configurations are complex to build. That is, you need to consider all of the different options you will offer, and build each one of those out.
Then, on top of that, you need to consider how each of these options will impact the rest of your existing product suite.
As you can imagine, if you already have products with configurations, any additional configurations you introduce will quickly increase complexity and edge cases.
Furthermore, having lots of configurations means it’s hard to be able to sanity test, since there are now multiple happy paths to consider.
Each automated test will need to test for each of the possible combinations of configurations, and every new feature that ever gets added needs to consider the impact of the past configurations.
Join the PMHQ community to learn how the experts do it.
Customization
What is customization?
Customization is when you build out a feature for just the customer who requested it, and for no one else.
You build it to their specifications, and no one else is expected to use it.
Pros of Customization
Customization is “easy” because you just build what the customer asked for.
You don’t need to come up with your own solutions, and you don’t need to worry about offering different options to different kinds of business models.
Furthermore, the customer who requested the customization is less likely to complain about the feature because you built it exactly for them, with their specifications in mind.
On top of that, customization means that you can keep the rest of your customer base using your product as-is.
Because customizations are targeted at only a single customer, the rest of your customer base will continue to use your product as-is.
Customization is generally used for systems integrations, or for customized onboarding.
Cons of Customization
Customized code is not easy to maintain. That is, it’s nearly impossible to keep customized code up to date as the product evolves over the next few months, especially if there are new features that intersect with the customer’s customization.
This also sets a bad precedent, where you’ve taught the customer that they can force you into building exactly what they want.
As a reminder – just because a customer asks for a feature doesn’t mean that it will actually solve their pain.
Trust me – I’ve built out customizations before that wound up not solving the customer pain, even though it was built exactly to specifications.
Even worse, because you’re the one who built it, you’re now permanently on the hook to customize it further and further until you actually do solve the pain – or until you lose the customer.
Also, one of the things to keep in mind with B2B products: your customers talk to each other.
It’s highly likely that your other customers will find out that you’ve customized the product for one of them – and then they will feel entitled to push for their own set of customizations as well.
As you wind up building out each custom feature for each individual customer, your product loses focus, and your team loses their vision.
You wind up just being an outsourced development team, rather than being a true product team that builds for scalable solutions across a customer base.
Customization can help you quickly score a win with a critical customer, but you will pay for that strategic debt.
In other words, customization is first-order positive and second-order negative; you’re taking out a high-interest loan against the future scalability of your product.
Punting on a Feature Request
Sometimes, the right action to take is to punt on the request. That is, the customer’s request doesn’t make sense to do at this moment, given priorities and resources.
For example, say that you’re a product manager at Slack.
One of your customers tells you that they need Slack to recognize a new command called “/drive”. They need this “/drive” command to accept as parameters, because they want to use Slack to control their fleet of autonomous vehicles.
That simply isn’t on-strategy for Slack. Slack shouldn’t commit to any sort of solution for dealing with this sort of use case.
It doesn’t make sense to add in a global command, it doesn’t make sense to add in configurable Slack commands, and it doesn’t make sense to build a custom Slack command for the one customer.
Pros of Punting
When you reject a request, you maintain focus for the team. You enable your team to double down on the initiatives that are already in flight.
Here’s a fantastic quote from the late Steve Jobs:
“People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying ‘no’ to 1,000 things.”
Interestingly, saying “no” is also a great way to provide certainty and focus for the customer. Sometimes, customers need to hear “no” so that they can continue to focus on what really matters.
I’ve heard multiple times from customers that they were relieved when I told them that we don’t build particular kinds of features.
It cements our product identity and our product niche, and enables them to focus on running their business.
Remember, if you say yes to everything, your product becomes stretched too thin and loses its identity.
That lack of identity causes existing customers to become confused about what the product actually does, and causes prospects to look for more focused solutions.
Also, note that I used the verb “punt” – just because you say “no” now doesn’t mean that it’s a permanent “no”.
As your customer base changes over time, as the industry landscape changes, and as your product evolves, you may say “yes” to the feature request that you previously punted on.
Cons of Punting
When you punt on a feature request, you lose any of the revenue and product usage that you could have gained from building out that feature.
Also, if you’re not careful with how you say “no”, you’ll potentially damage the customer relationship – especially if you haven’t set strong expectations upfront.
Be tactful in how you say “no” – use objection handling to tackle the situation.
How to Decide What to Do
Your 4 options range from a spectrum of mass adoption to zero adoption. Therefore, use that that lens to decide which path to take.
If you want to push your entire user base towards a particular way of working, or if you fundamentally believe that the feature makes sense for all customers, then build it out globally.
If you fundamentally believe that different segments of your user base will need to use different kinds of setups, and you think that these different setups will last for the long term, then configure.
If you fundamentally need to keep this customer happy, and this customer has tight timelines, and you’re sure that no other customer is going to use it, then customize.
If you fundamentally don’t think it’s a good idea at the moment, then punt.
Configuration is the Dominant Strategy for B2B Products
Just about every successfully scaled B2B platform has deep configuration and very little customization.
For example, Salesforce has deep configuration. has deep configuration. Marketo has deep configuration. Google AdWords has deep configuration. Zoom has deep configuration.
When you configure, you have options that you can then use across different customers and across different use cases.
The brilliant thing about configurations is that they work together combinatorially – so as your customer base expands over time, you can support more and more kinds of product usage.
Of course, that strength is also a weakness – with too many configurations, it’s incredibly difficult to maintain test paths for them all. That’s why Salesforce only releases updates 3 times a year.
Here’s another thing to keep in mind: customization is actually really painful for customers as well. A customization is essentially providing a customer with infinite options, and infinite options are far worse than a single option.
When you provide infinite options, you create analysis paralysis. Your customer frets over trying to get the best possible solution, and forgets to think about diminishing returns or about prioritization with limited time and resources.
If you have only a limited set of options through configuration, you can give the customer some flexibility and control, while enabling them to push forward quickly in accelerating their business.
Of course, don’t configure for the sake of configuring.
If you wind up building a configuration that is only used by a single customer and none of the other options are used, that’s just customization.
Call a spade a spade. Don’t abstract a customization into a configuration if no one is going to use the other options, because that just creates so much complexity and confusion in the code.
Trust me – I’ve made this mistake in the past, where I configured a customization.
It created so many problems for internal developers and for external customer users, where no one could figure out why the other options existed.
Only create configurations if you’re sure there are at least 2 valid options, all of which will have significant usage.
Summary
When a customer asks you for a feature, you should be ecstatic! They trust you to solve a problem they face.
You have 4 strategies available:
- Build globally
- Configure
- Customize
- Punt
You should never rely on just one strategy all of the time. When you receive a customer request, dive deeper to understand the pain behind the request, and consider how broadly such a pain might impact your user base.
If it impacts everyone in the same way, build globally.
If it impacts many customers, but there are different options that you need to support, build configurations.
If it impacts only this one customer, and you absolutely need to give in, build customizations.
If it’s not the right time to tackle this request, push back on them and punt the request.
Have thoughts that you’d like to contribute around configuration vs. customization? Chat with other product managers around the world in our PMHQ Community!
