Tales from Sales Engineering: Customize vs. Configure

How many times have you heard this on a sales call?

Prospect: Is that feature customizable?

Sales Rep: Yes, it is. We can definitely customize that for you.

You (thinking): No, we can’t customize that. We would never do that. However, we can configure it in a way that suits the prospect’s need.

As a non-salesperson involved in the sales process, I’ve heard this type of thing time and again. While the sales rep is seldom being knowingly dishonest with the prospect, she is erroneously stating product functionality. She’s setting an incorrect expectation, one that the product as it is cannot meet. It seems to me the root of this issue is a misunderstanding of how software products are built and the underlying methodology of why they’re built that way.

Customizable vs. Configurable

What the sales rep is trying to relay to the prospect — and what the prospect is usually asking — is that a specific part of the product can be configured in a variety of ways. Say there’s a delay setting on an email notification feature. The setting can be changed to 1 day, 2 days, 7 days, etc., according to the customer’s needs. The setting will always exist, the email notification will always be sent at some point, but the number of days delay can be changed. This is an example of Configurable.

To contrast, a customer requests that the email notification not exist at all, and a product team re-writes code to remove that feature from that particular customer’s product instance. Whereas every other customer using the product sees the delay setting within the product and experience the email notification being sent, this one and only customer no longer does. This is an example of Customizable.

What’s the difference?

From a sales rep’s point-of-view, the difference may be — while clearly differentiated — completely inconsequential. What’s the real difference? What does it actually matter? The customer can get what she wants and our company closes the deal. End of story. Right?

Sort of. The key difference between Configurable and Customizable is that the former allows a customer to use a product as shipped, switching certain features on and certain features off according to her specific needs and workflow preferences. Since these on/off switches are already built into the product, the customer can make these changes themselves with little technology or customer success support. The latter, however, requires an enormous short-term investment of product and engineering time that often achieves little, if any, ROI and skews a company’s entire product strategy in the long-term.

I’ve worked for companies where the product was highly customized for specific customers. Historically, the customer had requested specific features and the product and engineering teams had developed and shipped them, but only for that specific customer’s instance. These features were not productized and pushed to all customers. (Lest we forget, as soon as you build and ship something, you have to maintain it. If you have a customer base of 10, and 6 of those customers have a unique, customized instance, when you release new code, you can’t do it in just a single release. You have to release 7 times: once for the 4 customers on the “standard” instance and 6 different times for each of the customized instances. As you can see, this gets to be a pain in the ass.) By bending to customer demands and building every little thing they request, technology teams are affected, customer support and account teams are affected, and eventually the entire business can be shifted off course.

The other, better option is to systematically request, collect, and synthesize customer feedback and write user stories that broadly solve customer challenges. This allows everyone to move more quickly, writing code and testing and releasing and communicating and iterating over and over again until the customer is satisfied with your product as well as your responsiveness to their feedback. In turn, everyone in your company deals with fewer customer complaints and accordingly enjoys her job that much more. Productizing features and not building one-off custom product instances for customers results in fewer headaches for everyone.

Now, back to the sales process…

It’s understandable that the average sales rep doesn’t know and doesn’t care about product methodology. Salespeople are good at sales and want to close deals. That’s what they signed up for. Product people are good at building and shipping product, and that’s what they signed up for. This is okay. This is how it should be.

As a Sales Engineer, Solutions Consultant, Product Specialist, whatever your title may be, it’s of utmost importance to be well-versed in both sales and product. (This duality is key to the job.) You are the expert, you are there to discover prospect needs and pains, map them to your solution, and ensure the product delivered will be what the prospect/customer expects to be delivered. That’s what you signed up for.

In order to achieve this, education and training are a vital part of your job. When the conversation at top occurs on your next sales call, it’s on you to pipe up and ensure the prospect understands the feature in question can be configured, benefiting them by being able to set it according to their special situation.

Later, you can educate the sales team on how certain parts of the product work, which key selling product areas, are configurable — and also reinforce that your company will likely never build custom features, resulting in Frankenstein’s monster products, for particular customers.

The challenge is to know as much as possible about how the various teams in your company work and how they think about their jobs. Get to know them, get in their heads, and you’ll be better at your job in turn. The root of success is the strength of your relationships both internally and externally.