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.

  • 1
    I guess a good way to clear things up is, when you are asked a question, then give a clear answer, and when you are confused, then ask a question. Your response could as simple as "yes you are right / no that is not correct". If you feel what people say is stupid and wonder why they say it, then ask why. Usually I have a good faith with people I'm working with that they don't ask stupid question just because they are stupid (I believe they are not even if I don't know them much), and I should communicate with them to figure out the real "why". – user3528438 Jan 6 '17 at 22:00
  • 4
    Interesting that you find these questions absurd. I consider them great challenges. "we have to enter our data first (of course, you have to, we don't have your data)" This is actually a common problem and some of the big players are actually solving them. "I have to enter my contacts in LinkedIn"... no wait, you don't. That's one of the great things about LinkedIn! You don't spend any time editing contact info except for your own! Many IT systems end up mostly unused because entering data is a huge pain. Solve that problem and you will have a killer app. It can be done! – Stijn de Witt Jan 7 '17 at 20:19
  • 16
    This is a problem that is as old as computers. Literally. :-) – Martin Tournoij Jan 8 '17 at 7:35
  • 9
    When they say "we have to enter our data first", what's the emphasis on? Is it on "we" (as opposed to someone else? or a machine?), is it on "enter" (as opposed to copy/paste? or as opposed to migrating?), is it on "our" (as opposed to someone else's?), is it on "data" (as opposed to goals or something?)? There's so many ways that statement could be read, it'd be helpful for us to understand what you think they were actually asking. – Mehrdad Jan 8 '17 at 8:46
  • 3
    Why not just ask them how they wanted/expected it to work? – BSMP Jan 9 '17 at 14:17

14 Answers 14


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.

  • 86
    TL;DR: You only think their observations are absurd because you have not (yet) put yourself in their shoes. – Mindwin Jan 5 '17 at 22:31
  • 23
    Your last paragraph misses the point IMO. While having a slimey sales person in the drivers seat is bad, not having anyone with sales abilities is also a potentially catastrophic problem. If simple customer questions like these are enough to trip dllhell and his(?) colleague up, then their employer needs to expand the customer visit team to 3 people and add a good salesman to it. – Dan Neely Jan 6 '17 at 0:54
  • 2
    What is the conclusion here? I read 'make sure you tell them how it can make their life easier'. For example, it is now faster to add data. Once it is added it can be managed with simple tools, and now you can get nice reporting for your monthly report or annual audit. – Gusdor Jan 6 '17 at 11:11
  • 4
    @Gusdor I think the conclusion is "be sympathetic that there are aspects of this (proposed) change that will disrupt their current routine, and explain how the software tries to minimize that disruption." Now the actual response will still depend, maybe the answer to "will we have to enter our data first?" is "part of our implementation process involves a comprehensive data import from (existing system X)" or perhaps it is "in a moment we will be showing you how easy the data entry process really is" or whatever. – BradC Jan 6 '17 at 16:26
  • 4
    @DavidWallace Any reasonable salesperson with some domain knowledge would be able to answer these questions. Those are not technical questions, so there is no reason to assume that technical personnel is most qualified to handle them. – xLeitix Jan 8 '17 at 11:31

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.

  • 66
    If they have no system, then they have no concept of how it can benefit them. It sounds like you need sales people with you in the presentations. The sales staff should pitch the app, then bring you in for technical questions they can't answer. – Andrew Berry Jan 5 '17 at 9:01
  • 51
    @dllhell Don't worry about the details of my answer, which are made up as I know nothing about lab management systems - the point is that you need to be focusing on the customer's needs and how your solution is going to make their problems better, rather than saying their questions "aren't important". – Philip Kendall Jan 5 '17 at 9:14
  • 16
    @dllhell there's a difference between knowing a <reason> and immediately seeing a connection between it and the problem itself. Nothing to get annoyed about - sometimes people just need to be told the connection (or be reminded about it). – Daniel M. Jan 5 '17 at 9:33
  • 19
    @dllhell: For the problem with the gloves, a device with a touchpen might be able to solve it. – raznagul Jan 5 '17 at 12:47
  • 4
    @dllhell They might just be asking, despite knowing the reasons, because they hope you have some work-around solution to the problem that they don't know about. Or sometimes people just want confirmation that their problem is indeed common, and not some silly contrivance that their specific employer has. You as an outside party are the perfect sounding board for them. – Reaces Jan 5 '17 at 19:31

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.

  • 41
    @dllhell: At some point there will be a contract. And you will be held to the contract. "Nobody can say it doesn't work as promised"? Their lawyers can, and they will. – gnasher729 Jan 5 '17 at 11:16
  • 26
    @dll you're trying to shift blame to someone else. That's exactly the behavior you need to train yourself to unlearn if you want your business partners to feel more comfortable. – simbabque Jan 5 '17 at 12:10
  • 35
    @dllhell: You won't have contract problems if the potential customers don't sign the contract. But you might get cashflow problems. – gnasher729 Jan 5 '17 at 12:28
  • 4
    @gnasher729 I usually quell this with colleagues by asking them how they would expect to be treated by an auto mechanic. The looks of shock, horror, and embarrassment are a thing to behold. – Retired Codger Jan 5 '17 at 16:32
  • 4
    @JonH I'll go one further and say that often these 'dumb' questions are actually the best questions. The real problems with software are usually not the software itself, but the way it (doesn't) integrate in the larger process. Someone looking at the larger process only sees this on little tool in a huge complex solution and asks questions that seem absurd if you only look at that single tool but are actually key indicators of what is wrong with how the tool works in the larger context. Having to export and import data all the time is a drag. Fix that. – Stijn de Witt Jan 7 '17 at 20:32

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.)

  • Remember my colleague molecular biologist? This is lady with 20 years experience in laboratory. – dllhell Jan 5 '17 at 12:42
  • 22
    @dllhell I noticed that. But i tried to give a more generic answer that just for your very specific case. And frankly: You seem to prove my point here right away again: You seem VERY convinced you are right and everybody else is saying/asking stupid things: Try to keep an open mind. – Tonny Jan 5 '17 at 12:52
  • 20
    @dllhell those 20 years of experience are not in your customer's laboratory and since you don't sell the best software in your field, but the best software your client needs... – bolov Jan 5 '17 at 13:12
  • 2
    @dllhell Is she still in a laboratory while she's helping you develop this software? How much has changed since she last worked in one? She definitely has the background to help, and she'll be a great asset in building software that's useful for your customers. But that doesn't mean she knows everything about every lab's process, especially if she's not still active in the field. It really means she'll just be better at asking questions to find out about your customer's needs. – jpmc26 Jan 6 '17 at 10:16
  • 2
    @dllhell A research lab (or criminal forensics lab) is VERY different from a hospital lab. My sister worked at all 3 (hospital last) and says she got an enormous culture shock when moving to the hospital lab. Work pressure, dealing with privacy sensitive patient data, ad hoc test requests coming in from doctors. It all made for enormous differences in workflow/daily operations. – Tonny Jan 6 '17 at 12:33

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


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.

  • they aren't very happy about sending those data around because it contains patients data with their names IMO, I don't think being anonymous is going to help here... This issue could be solved with data being stored in house, or possibly using good encryption to store the data on a server which will allow piece of mind for those who are storing data. There are plenty of sites that store highly classified information such as SSNs. – XaolingBao Jan 5 '17 at 14:25
  • 7
    Of course they aren't happy about sending around patient data. In many countries there are laws about handling of patient information. If you are not aware of the relevant law, you need to be and you need to address their very valid concerns that the laws are being followed. – HLGEM Jan 5 '17 at 15:01
  • @XaolingBao I changed to ` to anonymise them or send equivalent test data` – Walfrat Jan 5 '17 at 15:10
  • @HLGEM That's not a job for software developer. This is a task for project manager and a lawyer to figure out. – Mołot Jan 8 '17 at 20:42
  • @Morlot, did you miss the part about this is the person who has to address the clients' concerns? Anyway, any developer working in healthcare cannot afford to not be knowledgeable able the relevant legal requirements. That is just plain incompetence. – HLGEM Jan 9 '17 at 14:51

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.

  • The op clearly stated that he got observations not questions. The way he wrote them down also indicate that they are observations. Lots of People voice observations to get confirmation instead of assuming something. A "Sales" presentation without any questions or observations would be worse in my opinion. – Raoul Mensink Jan 5 '17 at 12:51
  • 2
    @RaoulMensink An observation, used that way is implicitly a question. Every question is good, but because it can help make the product or presentation better: if they're failing to understand such simple parts of the process (of using the software), then there is most likely a defect with the presentation. Digging deeper is the way to go. – employee-X Jan 5 '17 at 14:59
  • 1
    @jpaugh just to be clear. Every question is good, but some are bad? Also the parts where the user actually has to do something is often if not always the hardest part for them. – Raoul Mensink Jan 5 '17 at 16:13
  • @RaoulMensink No question is bad. Every question is a sign of a misunderstanding, or of knowledge which has not yet been shared. Every question is good, especially the ones that show that the user is not on the same page as the developer. I did not mean to emphasize "using the software," merely to show which process I'm talking about. Part of using new software is always hard. But part should be obvious from the presentation. – employee-X Jan 7 '17 at 0:46

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.


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)


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.

  • This is a great answer, but it could use some formatting to make it easier to read. Splitting it into sections with #headerings, and bullet points or numbered paragraphs would help. – employee-X Jan 5 '17 at 15:05
  • 1
    I did not know those were a thing. I'll look into that – Valthek Jan 6 '17 at 7:37
  • +1 for giving an example script! There is definitely a learning curve for translating between customer-speak and developer-speak. – user812786 Jan 6 '17 at 13:40

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.

  • 2
    I absolutely agree with that last paragraph. I used to work as a "sales engineer": I was a software engineer who went along with a sales representative. The sales rep. gave the presentation and fielded all questions. My job was to stand there, look intelligent, and occasionally answer those specific questions the sales rep. couldn't... and to pay attention to what we might do as future features, given feedback. It seemed to work just fine. – Ghotir Jan 5 '17 at 16:42

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.


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.


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.


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.


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?


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)


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?"


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.



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.

  • 1
    I like this answer and all I would add to it is that whenever a customer is asking these questions, they're basically thinking through things out loud rather than silently. – Rudolf Olah Jan 8 '17 at 16:58

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.

  • Adding on to that, these questions are a great opportunity to look good and showcase your product's functionality. The person asking perceives a problem, but look at you! You've already anticipated it and have a great solution built in. You can agree with them that they've raised a very important issue and then show them just how you take care of it. – octern Jan 8 '17 at 3:19

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

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...

Your Answer

