Random Ramblings about stuff I see going on in biotech, internet and the stuff I read.

Sunday, September 25, 2005

Application Scientist - Giving software Demo's

I thought in my Application Scientist discussion that I sort of brushed over giving software demo's to scientists. Having spent 3 years doing it, multiple times per day, and while looking for people to give us $1M and up, that I would share my thoughts on the matter. So, take these as you will. I don't know if these are also applicable to other software demo's, as I haven't given those, but I think a lot of it just makes sense.

  • Know your software. Seems kind of stupid, but really I mean it. Know it. Know where everything is. Know how everything works. Know how to do everything. Know what the screens mean and what QUESTION the screens are answering.
  • Know the subject matter. When someone asks you a question you have to know what they are talking about. this seems stupid, but I have seen any number of folks screw this up. This is the primary reason most sales reps can't give the demo's. The 'field' knowledge (i.e. all that useless information that you loaded in to your head during your Ph.D.) is what you have to have down. Otherwise you are wasting everyones time, and the sales rep could also have NOT understood. You wasted money by coming along. Go home and study.
    • NOTE: You will not know everything, and I don't mean to imply you should. I do mean to say that you should understand the question. Just as you probably ran in to at your thesis defense, you can say "I don't know" or ask for more detail or whatever. BUT you should have understood the general thing that is being asked!
So - those two points above are key. With them, you should be good to go...well except for the actual presentation and the data. I am going to assume here, because it is all I know, that you are demo'ing scientific software to scientists. This means that you are working with experimental data. Many companies have sample data that you work with, and I have done that. Others use data the customer gives you, and I have done that. Either works. It is just a matter of how you go about it.

My steps of going in to presentations:
  • Have a prepared "path" through the software that is going to show off why it will help you analyze your data and get you the answer either more quickly or by showing you something that you wouldn't have been able to see some other way.
    • NOTE: I did not say "Show every screen" or "Show every menu" or really talk at all about showing everything. Showing everything is a "feature dump" and is really boring to sit through. Also, most people won't use most of the features. They really only care about getting answers to their questions....
  • Which leads to ASK QUESTIONS OF THEM
    • Ask "What are you looking for" or "What are you working on" or "What stage are you at" or "what are you using now and how are you using it?". All of these will tell you what kind of questions they are trying to answer. You should immediatly ditch point 1 above and focus on showing them how to answer their questions.
      • Note that it doesn't matter if you are using their data or your data, as becuase you know the field and your software, you can move through this....
    • With the questions in hand, and showing them how to answer their questions, you need to focus on why your solution is better than whatever they are doing now. If it isn't, don't say it is. People aren't that stupid. If your solution isn't either easier, faster, or have more power, then you shouldn't be trying to sell this and I can't help you. I didn't take that job...
    • In the process of showing them the above things, weave it in to a story. Way up top I said "know the field". that means you need to know the workflow that they are likely to be going through. If you don't, Ask them. Do the workflow. Where your software adds something, point that out.
      • the way I did this was to have little "stories" about every screen that I could end up at. Each story was a little way of using the screen that answered a question, or how the screen showed you some bit of information that fit the workflow, or something. A LOT of this is determined by what they have asked for.
  • Don't take more than 45 minutes.
    • NO ONE CARES that much. If they have alloted more time (and you should have asked) then they may sit longer, but you better read the crowd and notice that. People that are doodling, sleeping, or passing notes = bad. laughing, interuppting you to ask questions = good. You can't count on the good points though, as in different countries people behave differently. The japanese won't interrupt to ask a question and probably won't laugh. I didn't waste time trying to sort out the German sense of humor as it was alien to my sense of humor. When English is a third language, you are far more likely to make an ass of yourself than you are to entertain them. Be enthusiastic, but humore is dangerous. I broke this rule A LOT, and sometimes got away with it...but I know I was playing with fire....
  • I will repeat
      • Some call this mirroring or reflecting or whatever. The point is that they want to see something so you should endevour to give them that.
      • This really really really means that prepared demo's = BAD. While I am sure that you think you are showing people what they want to see, the only real way to know that is to actually ask them. Most of the time, they will tell you. There are some cultural caveats here, but lets assume that your not in Japan.
  • FOCUS on HOW it helps them do their jobs
    • In a pharma, it is all about getting the drug out. In academia it is all about the paper. Focus on how your software helps the person/people do their job better/faster and how that will translate to them being succesfull. If you don't know how to do that, then you haven't paid attention to the points above about knowing, and you should instead just ask. "How is success measured?" or "What are you looking for our software to be able to help with?" or "What are your critical problems that you think our software can help with?". The follow ups to these questions is normally more questions along the lines or "if we do that, what is the next step"
  • Answer their questions when they are asked.
    • DO NOT ever (with the exception I will talk about in a minute...) NOT answer a question.
      • "I don't know but I will get back to you tomarrow with an answer" is a totally acceptable answer, provided that you do get back to them with an answer.
      • You can defer a question to a couple of minutes later with a statement of "Good question, the next step of the analysis will show that" or "Actually, I will get to that in a minute - Are there any more questions on this step/screen before we move on?" -or- "excellent segue - hopefully what I will show you in a minute will answer tha" -> this HAS to be followed up with (after you have done whatever) "Did this answer your question from a minute ago?"
      • Answer what they asked, not what you want to answer.
        • no really....Don't just ramble off some prepared BS. Answer the damn question. This is absolutly critical. If you pull this crap in Germany expect them to snort at you, call you a name, and then point out that you were full of crap and haven't answered the question. Trust me on this, I tried it....
        • There are, however ways to answer questions and ways to answer questions.
          • The answer is ALWAYS Yes (except when it is categorically no)
            • This means you always start "Yes" but sometimes it is "Yes, but there are a few limitations....."
            • A categoric NO, when it is true, is fine. If there is any flavor of Yes possible, then answer Yes. "Sort of" is really bad phrasing of an answer. Don't say that.
      • Long Rambling answers waste time and make you look stupid.
      • Don't answer more than they asked.
      • Wait until they ask the entire question before answering.
        • You haven't heard it all before. Trust me. Your being rude and you will probably not answer what they want you to and you may in fact even say something that points out a flaw or raises a question they haven't thought of.
          • I will repeat this again. LET THEM FINISH TALKING BEFORE YOU START. I suck at this, and authorized sales reps to kick me under the table when I started to interupt.
        • to repeat : RUDE and YOU DON'T KNOW (but yeah, your probably right that they will ask the same stupid question everyone does....)
        • As a bonus on this, by letting them finish and saying "good question" you make them feel good. By cutting them off you make them feel like another of those dumb morons. Good=Money. Moron feeling = No Money.
  • Dress appropriatly.
    • This varies by industry, but jeans are right out. Business casual is what we were always in
  • Don't get rattled.
    • You will be insulted. Your software will be insulted. Whatever....
    • if people say things that are grossly inaccurate as a way of typing your software, then you are in judgement territory...
      • If it is critical, then you may want to politely correct them
        • "My understanding is that...."
        • "I think I wasn't clear on a point here, so... sorry about that but lets step back a second as this is important"
      • If it doesn't matter, then letting it go may be better. Just be certain it doesn't matter.
        • The customer is always right, unless they are wrong in a way that will cost you money
  • From leaving the car to getting back in the car, assume that you are being listened to.
    • Game on from start to finish. Once you are in the car you can laugh about how stupid that guy was or whatever. Before then, and on the walk out to the car this is critical, you are still on display. You have no idea who will hear or see, so assume that the worst possible thing could happen.
  • No really -
    • Don't talk politics
      • Hard if you are an american working in Europe, but worth staying out of even more because of that.
    • Don't talk religion
      • Can't think of a time to break this rule....
    • Not too many personal details
      • enought to be human, but a story of cleaning a dirty toilet is probably too far...
      • Your divorce is also out of bounds...
      • as is your most recent conquest...
      • and any bodily function....
    • I have seen/heard all of these rules being violated. I was blown away every time....It never goes well.

This all boils down to
  • Listen to the customer
  • Know what you are talking about
  • Be polite
  • Know your shit.

1 comment:

Sai Sreenivas Vemu said...


Thank you for the post. I am appearing for an "Field Application Scientist" job position interview and I think I have the necessary input.