How should I respond to absurd observations from customers during software product demos?

Question

I'm not sure if this question is placed in the right site but this is my workplace, and this site often discusses diplomacy in the workplace.

I'm a software developer and I'm not very skilled in this type of communication. My colleague is a molecular biologist with a similar problem, but (unfortunately) we cannot be replaced with a skilled sales representative because we need to answer very specific questions.

Our company developed a web application for biobanking and laboratory management. During software presentations to our potential customers, lab managers and decision makers attend and from time to time we get observations we don't know how to respond to:

It's nice but...

• we have to physically access your application (of course you have to)
• we have to keep our data updated (of course, you have to if you want to have order in your lab)
• we have to enter our data first (of course, you have to, we don't have your data)

and so on.

I don't believe these statements are very important, because most of the attendees understand what they have to do in order to efficiently run their labs but I think (I may be wrong) our response to such statements is important.

So, how do I avoid appearing annoyed when answering questions I consider absurd?

p.s. I am very grateful for all these opinions and your contributions to understand my position.

EDIT: Okay, I see that some clarification is needed... I asked ONLY what I asked, no more, no less. I didn't say we have problem with sales or with software usability or with customer's lawyers. I asked how to deal with observations I described as said above that I encounter occasionally. I just want to be prepared in the best way for our demos. You obviously know much more than me about such topics so I can read here only useful thoughts. Anyway, I have read a lot of your thoughts I didn't ask for but they are still valuable for me because I'm a technical guy, I got more than I thought and this is great.

Answer 1

As somebody who is also in the business of writing biobank-related software: You have not understood your customers.

You are not selling these people a picture, to be hung on their wall and left there. You are selling them the tool around which they will have to build a whole process (the process of data management): A big, expensive and difficult process, which requires skills they do not have, and which will come on top of their existing responsibilities, with no additional funding for more personnel. They don't need a solution to a technical problem; they need a solution to an organizational problem.

If you stay stuck in your narrow, technical point of view, their remarks may appear absurd to you. Of course a data management application assumes that the data will come from outside as an input. It sits on the receiving side of the interface and is not responsible for what happens on the other side. But the person you are talking to is responsible for that. And because he has not spent hours thinking about the best information architecture for the biobank, he probably has never before stumbled across the (obvious for you) thought that he will have to somehow produce the data.

So, in the best case, this is a mild expression of surprise, a sign that wheels are starting to turn in his head—"This is going to be difficult, I have to start a solution hunt." In the worst case, he realizes that his organizational reality is so much stacked against him that he will not be able to pull that off. Have you ever bought an expensive unitasker, maybe that thing which peels, cores and slices an apple in one turn of the handle? And a year later come across it in a drawer to realize you have continued to use a knife on your apples, because you could not be bothered to learn that weird tool and "pay" its overhead? While you are presenting your tool to a manager, he is designing the whole business process in his head, and evaluating the risk that next year he will find himself in a "I bought a million dollar apple corer" situation.

Appropriate Reaction:

The appropriate reply is the same as the one for any human who just had an unpleasant surprise: Show respect, understanding, validate his feelings, and signal your willingness to offer support as needed (which is not the same thing as trying to jump in with a technical solution.) If you do not know how to do this, the surprising place to learn how is to read good parenting books like this one. Forget that it is written for parents, it will help you immensely to communicate with adults.

Your "willingness to offer support" should be meant in earnest. In principle, it is not your job to also reorganize the customer business process; it is the customer's job. But most customers you meet will be overwhelmed by that task. If you don't give the impression that you understand his concerns and are willing to work with him to overcome them, you will lose the sale to the competitor who does. And if you give that impression but don't follow up, you will 1) Have a very difficult and frustrating working relationship with that customer down the road, and 2) Lose your reputation and your market. The biobank community is tiny—basically all biobank managers in Germany are on a first name basis, for example. They meet, talk about their biobanks, and talk about their IT. If you start meeting your customer IT process problems with, "Not my problem, I only deliver the software," their peers will hear about it.

By the way, in your position you have an advantage over a typical sales person. Salespeople tend to work under perverse incentive systems, which often results in them making bad promises. You have a different set of incentives, and can use this to build good long-term relationships in which your customers value you as, "The person who listens to me and helps me to have a working data management." Just start listening, and helping.

Answer 2

I know it's trite, but "there are no bad questions". The people asking these questions obviously have a concern about using your product - they may not be expressing their concern very well, but the important thing is to find out what the real problem is.

For example: if they're saying "we have to physically access your application", try and get to the root of what the problem is - is it that they have to go from the lab back to their desk to use the application? If so, point out that you have a mobile app which allows them to use the application. Similarly, "we have to enter our data first", you can discuss the import tools you have available which make migrating data from their current system to your system easy.

Of course, if you don't have a mobile app, an import system or whatever the customer needs, then these really weren't absurd questions as they've pointed out a missing feature in your product.

Answer 3

As an anecdote: My brother once was on the other side of this. A vendor coming in, signing a big contract, and their developers showed clearly that any questions asked where absurd and the people asking them (including my brother) were stupid.

Then came the day of the product delivery. Everything got installed, my brother and his colleagues tried the new product, and two minutes later said "does not work as specified in the contract. The product is unusable for its purpose and delivery is not accepted. Please fix it as quick as possible, and take note of the contract clause that specifies a huge penalty for every day that delivery is delayed".

By thinking that questions were absurd these people missed the opportunity of avoiding huge cost to their company. By making it clear that they believed the questioners to be stupid, they destroyed any goodwill, so these people let them run straight into a contract trap. There was also no goodwill later for the acceptance of the product which stopped the late delivery penalties; instead any little problem was found, reported, and stopped acceptance.

So be careful. Most people don't ask "absurd" questions. If you think they do, there is likely something that you are not getting. Not finding out what they are actually wanting to say can be costly. And giving them the impression that you don't care what they say can be very, very costly. And as a software developer, I have met plenty of people who are very, very smart but don't care about developing software. If you think people are stupid, that's a dangerous trap. If you show them that you think they are stupid, that will cost you.

And please read Wolfrat's answer which shows how you might be trapping yourself.

Answer 4

I have been in similar situations myself.

I find that 9 out of 10 cases the customer really has a valid issue/point of concern, but at the same time the customer has a really hard time to formulate that in a clear question.

So don't dismiss a (in your view) obvious question. For the customer it ISN'T obvious or they wouldn't have asked about it.

And don't EVER assume that you understand exactly how the customers normal daily routine works and where your product fits in their workflow. You could be VERY wrong about that.
(I get a sense of that reasoning in your question and some of your comments...)

Ask the customer for more details. Ask him/her to elaborate, ask for an example from their day-to-day operation where they (the customer) think the issue will arise.
There is nothing wrong with admitting to the customer "I'm not quite sure what you mean by ...." and then follow up by "Could you elaborate on that? Maybe give me an example of how that would impact on/interfere with your day to day operation?"

Based on that you can maybe take away their worries with some more explanation how it is supposed to work. Or explain that your application provides tools X, Y and Z to help in the transition to the new product.
And who knows... Maybe you realize that your product lacks a feature... Could be an idea for the next version. Some of the best features got into products by customer demand.

And I have to admit: Sometimes this just leads to the conclusion your product isn't suited to the customers needs at all.
How to deal with that is probably best suited for another question on this site. (Most likely already asked and answered.)

Answer 5

Well if we take your sample questions, those are very far to be stupid when you think about huge systems :

we have to physically access your application (of course you have to)

This very likely refer to the ability to printing some selection of datas on (a lot of ?) various cases.

we have to keep our data updated (of course you have to if you want have an order in your lab)

If the system is composed of multiple databases instances, this means you have to synchronise between them. If there are other external systems that use those data, that means you will need to interface with those to push the updates. This can be a lot of work. Even if your system will replace the old one, there will be definitively a time when the two will live both together.

we have to enter our data first (of course you have to, we don't have your data)

Imports are known to be a hell, this is far from being absurd.

they aren't very happy about sending those data around because it contains patients data with their names

They need to make the job to anonymise them or send equivalent test data. Remove every column that contains such datas, replace them with a numeric identifier.

If you don't see the point of them being asked, you may aks for more information.Sometimes, there are definitively some questions you just wan't see any values (UI specifically).

Since you're software developer, you may let your project manager answers for those cases. You are only be needed to know the feasability on the thing, you're not the one which decide if you'll do it or not.

Answer 6

Every question you are asked points to a defect.

• It could be a defect in your presentation.
• It could be a defect in your documentation.
• It could be a defect in your sales team.
• It could be a defect in your product.

After every sales call or presentation you need to review what happened to see where you can make your process better.

The three questions you quote as absurd (access the software, update the data, load the data) would be the first three questions I would have before you even started your presentation. If I can't see from your presentation/demo how these are answered I will be asking them at some point.

Answer 7

There's a few things going wrong here that might be the cause of your problem. They're common problems, simple miscommunication between you and your audience.

Presentation Content

First of all, be conscious of what you're doing when presenting. You and your presentation are often the first real interaction between your product and your customers. Assume these people want to use your product and want to use it in the most convenient way possible. To that end, they'll be asking you questions with a specific kind of answer in mind. Also be aware of the fact that these people are not just there to waste time. These are your customers, not people with an hour to kill. If someone asks a question, that means there's a piece of information missing that's important to them. Sure, your definition of important and theirs might differ (see every version of "Can we change this colour") but they care.

Questions and Answers

And that brings us to the second point: People are terrible at asking questions. Usually, when someone asks you a question, they're only asking half of the question, the rest being implied by the context, what they have in mind as an answer and a whole load of other implicit things. Often, much of the implicit question is lost if there's a knowledge gap between the person asking the question and the speaker. When someone asks you about having to enter their data first, they're not asking you: "Do we have to enter our data into your application". They know this and you know this. What they might really be asking is: "How much time does it take to enter our data?" or "Can we import our existing data?" or "How much data-entry overhead should we be taking into account?" or "In what ways can we enter our data?" and a dozen more questions that aren't obvious to you.

Which brings us to our third point: People are terrible at answering questions. Often when you answer a question, you don't quite answer the question but you answer the question that you think is being asked. Take the question above: "Do we have to enter our data into the system". You can answer this question a dozen different ways but if none of them answer the question that was being asked, all you've done is wasted time.

Solutions

So, solutions. First of all, be aware of your presentation's content. It can be helpful to either have a test audience, preferably someone with little to no knowledge of the subject. If that's not available, either a recording or just reading it over a few days after preparing it can help. This way you can get a better idea of exactly what is being presented. Your mind often fills in blanks based on your knowledge and it's important to know if there are any major ones in the system. This is the same reason you (should) do usability testing. If you've worked on something for weeks/months/years, you know how it works and why. Someone without that knowledge might not see it and ask questions that seem obvious. Also be aware of how different your priorities may be. You as a software engineer are going to care about different things than someone working in a lab or their IT director or their marketing guy or whoever. But since they're the customer, what they care about is important because you want to make that sale. And perhaps more importantly, their questions can point to features that you've missed. That guy asking about changing the text colour from green to blue might sound like he just likes to pick nits, but there's likely a good reason for it. (Maybe two of his co-workers have some form of colour-blindness)

For the other two points, practice asking questions back. Sure, it's annoying if someone answers a question with a question but it's worse if someone doesn't answer a question you asked but instead talks about something unrelated. Try to give a brief answer to the question while at the same time angling for clarification.
Also important here, since it sounds like you're pitching your product to people, is appearing interested in their concerns. Active listening is important here. Try to use their questions, or part of their questions in your answer but use your own words. That lets them know you are hearing their questions but rephrasing it might make them realise they weren't very clear in what they were asking.

Q: "Do we have to enter our data into your application?"

A: "Entering the data into our database works via a simple interface, almost like an excel spreadsheet. We can pre-populate some of the database for you, but to really get the most out of it, you'll have to use accurate data for your environment"

Q: "Like an excel spreadsheet? Can we import our existing spreadsheet?" (There's the real question)

etc...

Long answer short: treat these observation with the seriousness they deserve because often the posed question isn't the real question but the real observation is important to you and them.

Answer 8

You are viewing the questions in the wrong way and need to either learn to handle them, or get someone else to

As other answers have stated the fact you consider these absurd shows that you're not doing a good job of understanding your users or their needs. Consider that if you're developing software for scientists that your clients are highly unlikely to be stupid and thus unlikely to be asking questions as stupid as you interpret them.

The task is to respond in a manner that allows you to understand and address their concerns. This may not be a skill you currently possess or have much interest in learning but you do need it if you're going to continue these presentations. The alternative is to get someone with these skills to step up and take the lead on handling these questions.

You state "we cannot be replaced with skilled sales representative because we need to answer very specific questions" but replacement is not what is required. What is required is to supplement your skills with people who possess the skills you lack. I would suggest that the best way forward, in the short to medium term, is to have the presentation given and questions fielded by a sales representative who can then defer questions to you, and your colleague, where they need to call on your particular expertise.

Answer 9

None of these questions are absurd. They are supposed to lead to a conversation about the practicality of your product in everyday work situations. Personally I love it when my audience gives me such trivial questions. They show that they are paying attention. Also, me and my product look good when I can answer them immediately. They also can give me a hook to show another strength of my product.

•we have to physically access your application (of course you have to)

Show them how physical access works and how it doesn't interfere with the function of your product.

•we have to keep our data updated (of course you have to if you want have order in your lab)

They want to know how the update process works. Show them how it works and how your product assists them in doing so.

•we have to enter our data first (of course you have to, we don't have your data)

Show them how data entry works. Lead them through a back-of-the-envelope calculation how much it will take them to enter the data or propose a way how their data could be migrated automatically from their current solution.

Answer 10

When you're trying to sell software to someone, you shouldn't consider any of their questions absurd. Even if the actual issue is outside your control, you need to address them and explain the underlying reason why your software works that way and why it is necessary to do it this way.

Your examples don't seem very absurd to me, they seem to represent real concerns. For example, "we have to keep our data updated" is a very real concern for your kind of software. Of course it is obvious that the data has to be updated somehow, but the real concerns here are how to ensure compliance and make sure that people actually update the data when necessary, and whether you're really making the updates as easy as they could be.

The software I'm developing is in a similar field targeted towards scientists, and what we found was that making it as easy as possible to get data into the software is very important. Fetching some data automatically help a lot, and sometimes it is important to make sure that the scientists can enter the data at the right place and point in time to avoid that they have to remember doing it later.

You need to address the underlying concern behind those questions. Those seem to be real issues that you might need to address, either by explaining the issue properly or making appropriate changes to your software.

Answer 11

I've spent most of my career as a Sales Engineer, being the technical expert in the room prepared to answer basically any question about our solution.

These kinds of questions are pretty normal, and you're already on the right track by recognizing that they come from a place of well intended ignorance. They want to ensure they're getting the right stuff, they just don't have the technical understanding to know all that you know.

The best way to answer these kinds of questions is by understanding the core concern and addressing it. That might involve asking several follow-up questions to dig in and understand what they're really worried about.

How do I address this kind of question?

• we have to physically access your application (of course you have to)

Our service agreement includes on-site installation, so the system will be stored here on site and you and your team will have access to it. (or whatever is actually true for your system)

• we have to keep our data updated (of course, you have to if you want to have order in your lab)

I completely agree, that's why we've provided this great update page that allows you to keep your information up to date. We also have this customizable dashboard so you can see what data is up to date and what data still needs to be updated. (or whatever is actually true for your system)

here I'm using a bit of a shotgun approach and talking to what I guess is another related concern - "how do I know if my data is out of date?"

• we have to enter our data first (of course, you have to, we don't have your data)

Data population is extremely important. We are able to import data from your current solution, solution, via our XYZ mechanism and we've successfully transferred data from N customers who formerly used solution.(or whatever is actually true for your system)

---

When you run into technical questions/objections that you can't answer, that's often a product enhancement. For example, if your data transfer solution is manual entry, but the data is already installed in some existing solution, you want to communicate back up the chain the some kind of customer accessible import tool, or professional service for converting data is something your prospective customers value.

--

we cannot be replaced with a skilled sales representative because we need to answer very specific questions

This comment scares me because it makes me think you're there on your own. You should certainly have a skilled sales rep in the room with you. Your sales/demonstration team should include the Sales/Account Rep who got the meeting and is responsible for building the relationship and closing the deal. And the technical people (you and your molecular biologist coworker) to answer the hard questions and maybe drive 90% of the presentation.

Answer 12

There's a great Star Trek (TNG) Episode where a teen-aged girl is forced into a difficult negotiation with a much older gentleman over some land. Another teenager, who up until this point was portrayed as a bit of a villain, tells her that "If someone wants something from you, it's not a problem, it's an opportunity." These questions that you see as absurd are probably opportunities in disguise - you could charge a fee to build and support an api, or charge a fee to have a data entry contractor import that data for you client, or charge a fee to adapt your tool so that it can work as a plugin for another tool. If you get these questions often, you should explore the cost and possible profit margin of these additional features and services.

There will be times when people ask questions just to ask questions. Work on answering those questions in a way that lets you just re-iterate the value of the product. "Can you rephrase the question in a different way?" is a neutral way to get people to re-think what their asking.

Remember that you are a bit like a teacher, and the people in your presentation are essentially students. Not all of them are going to be great students, so you may have to repeat yourself a bit. But repeating yourself should be worth it if you make the sale. Make the sale enough times and you'll be able to hire a sales person who's smart enough to take care of this task for you.

Answer 13

I used to do sales support and it was not even a very technical application. You do get stupid observations and questions and unfortunately those are are often decision makers.

Take control of the presentation. Beat them to the obvious observations.

• You should have a sales person there to introduce the presentation.
  The sales person needs to follow up to close sales.
• Start with an outline of what you are going to cover.
  If someone has anxiety about security and they know it will be covered they will (typically) wait.
• Beat them to stupid
  • Raw data must be entered
  • Workers need ready access to workstations
  • Data must be maintained
• Benefits of the application
• What it does (not how)
• Technical aspects of the application (how)
  I suspect you are starting here
• Implementation
  This helps separate implementation issues from product issues
• Questions and Answers
  Take questions from the floor as you go but if it is too much to cover then politely tell them that is something best covered Q&A as you will cover background material

Answer 14

A wise quote I always live by:

there are no stupid questions, only stupid answers

Understand that a lot of people you work for don't have the same knowledge you do. What might be obvious for you might be rocket science for your customer. That's why they're paying you instead of doing it themselves...