There are going to be times when the answer to the customer’s question lies just beyond what you know. Should you 'stretch' to land the deal? Or is stark honesty the better way ​to go? Or does gaining customer trust require a more nuanced approach? 

We've all done it. It happens at the peak of our demos when the customer is completely in sync with us, and at the nadir moments, when we're dealing with a person who asks more questions than we can answer. It happens at the worst of times, and the best of times. We s-t-r-e-t-c-h the truth. Just a smidge. We color a little bit outside the lines. We play the guessing game with the functionality we aren't sure of. We promise the moon, or maybe a star or two. 

It's never intentional. We feel that flutter in the belly, and before we know it, our mouths have run away with themselves. Personally, I blame our fight or flight response. It's almost biological. We know when we've done it. And we know what it's going to cost us. 

Overcommitment: Cost to the company

The first casualty is the product team. With each overcommitment, we disrupt product roadmaps. People who should be focused on developing new (and in demand) features are redirected to work on customizations, bells, and whistles we've promised the customer. More visible than that though, is the disruption to the team's work-life balance. If your organizations are anything like mine, the product teams are usually working on stretch targets as is. Unplanned customizations and product features tip the work-life balance further in the direction of working Saturdays and WFH Sundays. And they love you for it. 

The second casualty is the erosion of customer trust. This usually happens when you go back and 'explain' why a particular feature or functionality won't be available on Day 1. Consequence? They don't believe you anymore. They don't believe your colleagues. Now they question everything - they want to double (or triple) check everything you say with your supervisor. And he/she loves you for it. Cross-selling opportunities? Nah, that ship has sailed. And your supervisor loves you for it. 

The third casualty is the poor operations team. These are the people who have to maintain a long-term relationship with a now irate customer, while also delivering on a promise they can't keep (and weren't responsible for). The client treats them as 'untrustworthy' even before they have a chance at establishing a new relationship. What's more, they don't get the chance to make honest mistakes (which will happen) and are forced to play on the defensive from Day 1. And they love you for it. 

Overcommitment: Cost To You 

Simply put, it hurts YOUR reputation. You know what they're saying about you. 

How can you pivot? 

Of course, prevention is better than cure. You can recover from missteps of this nature, but that's a harder road to travel. Instead, let's look at practical things you can do, to ensure that you don't end up overcommitting in the first place, accidentally, or otherwise. 

First: Build product knowledge. Not just about what the features are, but what customizations are possible (and at what cost). Understand the product development lifecycle by spending time with product teams, to get a sense of the amount of work that goes into different types of changes/customizations/developments and the general timelines. Now, you're in a position to make a real 'guess'. But don't, still. 

Bring your sales engineer into the room while you build on your product knowledge. Observe how this person relates the various product features to business value. Make copious notes. Work with them to understand how different features can be leveraged out-of-the-box to provide value to various use cases for different industries and customer sizes. More importantly, understand the parts where your product misses the mark, and make it a point to learn if a roadmap exists to address these concerns. Adapt what you're going to say accordingly. 

Learn to say "I don't know". It's not a reflection on who you are. Even if you buddy up with your sales engineer at every meeting for a year, you won't know everything. You will hit the limit of what you know, at some point. Worse, you'll probably hit the "I don't know what I don't know" limit pretty often too. So learn to identify that discomfort in your belly for what it is. It can be freeing. 

There is, of course, a way to say 'I don't know' that is more effective. For me, it lay in documenting the customers' ask in as much detail as possible. I preferred asking the stupid questions at that point and getting them out of the way, rather than looking foolish at the next meeting. I would then come back with a well-researched response, and preferably, back that up with a discussion that involved my sales engineer and someone from the product team whenever possible. 

This way, when I came back prepared, both the customer and I knew they could trust what I had to say. It wasn't a glib little response that arose from a momentary flash of (not) brilliance, but instead from elbow grease and the right research. 

Building customer trust doesn't need to be an uphill task 

This is a lesson that requires a little soul searching on our part. For me, it involved dismantling my uber-confident, I-know-how-all-of-this-works, gung-ho self-image, and replacing it with a humbler, softer version that didn't need to be the sparkliest sales rep in the bunch. I needed to become the guy who cared about my customer the most, rather than the guy who put up the biggest numbers. 

Once I made that mindset shift though, I did become the guy who put up the biggest numbers, and it was easy (in hindsight) to see how that happened. I listened better, and I took notes. My sales engineer and I got to the point where we could finish each other's sentences. Product people actually took my calls and answered questions in ways I could understand, because we both understood the limits of each other's knowledge and skills. I made the sales because I was championing the customer. I was "their" guy, and they saw it, sensed it, and trusted it. 

And to think, it all began with me sweating it out in a demo, nervously saying, "I don't know, but I'll find out!"