Last week, I did NOT upgrade my insurance policy.
That’s no surprise, as this statement is usually true for every other week of the year. But that specific week was different as I had a meeting with a representative of a large insurance agency. She was professional and eager to help. Yet, one small thing was missing – she just forgot to ask me what I needed and what was important to me.
It reminded me of a series of customer meetings we had, when we developed a large data analysis system. We demonstrated the system’s capabilities, described what we were planning to do next, invited the customer to join our Beta program and asked for his opinion. It was only after the third meeting ended with no results but some polite nods (hmmm…. very impressive… It’s really great, we should meet some time to get further into it), that we understood something had to change.
And then it hit us – just like the insurance representative, with all the excitement, instead of listening to what our customer wanted to say, we were focused on showing off what we had. It is so easy to miss the simplest things.
The next meeting was conducted in a very different way. As we did not do all the talking, we had the opportunity to understand what was missing: True, the system tracked the progress of the analysis process very well and managed to identify tricky performance bottlenecks, but that was not our customers’ first priority. Most of all, they wanted to get a clear picture of which processes failed, and why. Luckily, implementing such a modification did not take too long.
In this post, like in “Diamonds Are Forever”, I provide tools you can use to ensure your product answers the right needs of the customer, even before the development phase begins.
From that day on, the way I’ve approached customers meeting has completely changed. It taught me that the most important thing was to listen first and only then talk. Here are 6 points to remember:
- The right person at the right time – The meeting starts before you actually get there. Make sure the right people attend it. If the purpose of the meeting is to identify the needs or verify the product’s contents, find the people who would best represent the user’s or the buyer’s needs (with enterprise applications, it is usually not the same person. The user and the buyer are looking for different things. The consumers market is a different game. If your product aims for the consumers market, there is only one person – the end user). Without the right people, you won’t get much out of a meeting.
- Do your homework – Learn some history. Did anyone promised something to your customer and did not deliver it? Does the customer has urgent open tickets and is waiting for a solution? If so, the meeting might not go as you planned. It may still be important to meet, but for other purposes.
- The Opening – When the meeting starts, after the introduction, spend no more than a few minutes to describe what you and your company are doing. Then let the client take over.
- The Middle – Take as much time as you can to listen to the customer’s problems, concerns, what they are doing and what is most important for them. Learn of other solutions they are considering and why. That’s the time to write down notes and ask questions about any relevant details. This is also the time where you will understand how you could connect what you have with what your customer needs. It is also the time when you get new product ideas so you could verify them with other customers at a later time.
- The Closing – Only after you listen and ask questions, you can combine what you know with what you learned, identify the way in which your product could solve your customer’s problems – what is working well and what requires further verification. Now is the time to share your insights with the customer, get his feedback and (maybe) his buy-in.
- After party – when you get to the office, document the meeting, action items, and insights. Make it available for your colleagues in support, marketing, product and development. Having a “customer meetings database”, will allow you and your colleagues to “do their homework” like you did. It will also eliminate the situation where during the meeting, the customer would ask why he has to explain to you guys the same thing for the 3rd time (hint: it would not be a good time to tell him you are sorry because you were not aware of the previous two meetings he held with your colleagues, where these things were discussed).
Oh, one small note, this way, we managed to get many customers to help us through the development process. That’s because they knew we really cared about their needs. Many of them agreed to install a pre-BETA release, even before the QA was over. We got early and valuable feedback and they knew they will be getting a working product that answered their needs.
Good luck!
Ilan

June 26, 2013 at 18:33
Very valid commentary. This is something any particularly successful sales person learns early on. Hopefully. I have been to way too many presentations that were ‘all about us’ rather than paying attention to customer needs.
If you tend to lead by breaking out the laptop and doing a demo, consider leaving it in the car instead. There’s a time and place for presenting your wares. It’s generally after you understand the customer even needs them and/or which ones.
Cheers,
JT…
June 27, 2013 at 1:03
Yes, some people seem to have a fear that prospects will be bored or disappointed if we don’t wow them with product demos and instead concentrate on questions to understand their situations and challenges. But this fear is largely unfounded and concocted in the heads of people who have never tried a true “problem interview” (customer development and lean startup term). In my experience, problem interviews usually result in a more trusting prospect, and one that is more confident any solution we provide will address her unique situation.
September 12, 2014 at 9:19
There’s can be a need to try to impress via a demo – that’s just insecurity with the situation you’re in and a feeling of need to impress along with no-doubt management pressure to ‘deliver’.
Another aspect which is always over-looked is the fear to speak to technical people; quite often sales people are just selling with intent to put pressure the technical staf without liasing – as they feel that they’re are presenting a ‘wow’ factor so as to get bonus; impress their manager, think of othemself/ egoi etc and leave the consequences to the technical staff – best to invite a technical member to show laison amongst your towers (which will foster growth over the ‘bridge’ within).