Befuddled

I've posted previously about being honest when you deal with prospective customers. When a customer describes a scenario to me that I know my company's product isn't a good fit for, I state that. The last thing I want is for people to think I've lead them on so we can make a sale. People won't want to do repeat business with us, and hurts both my reputation and the company's.

But I've encountered one particular scenario that I just can't wrap my head around. I was speaking with a test manager and his team. They outlined their scenario, and what they'd done with my product so far, and the issues they had encountered. I listened carefully, and based on what they wanted to achieve, I knew my app wasn't a good fit. I told them this, and stated my reasons why. Several of the team members voiced their agreement. And then the manager said something that flat out stunned me.

"I think we can make it work. We'll buy it."

I couldn't think of anything to say other than restate my previous concerns. The manager told me that his team would deal with it, and that they would purchase.

How would you handle this?

I Can Haz Demo?

It's funny how social media has changed our perception of language. We communicate much more informally via the emoticons and acronyms that we use in IM programs, Twitter and in-game chat programs. However, when communicating with first time customers, clients and prospects, this abbreivated means of communication strikes me as unacceptable. You're trying to portray yourself as professional, not show how hip you are. Additionally, if you are a customer requesting help, a demonstration, or requesting license information, your sales rep probably won't take you very seriously if you send in a message like the one I received last summer:

"Can u plz help in it?bcoz it is not clear from Demo how to test Web application. Waiting 4 ur reply."

While this person may have been genuinely interested in my company's product, this communication came across as unprofessional. My sales team sent off a canned email response along with links to some recorded demos. If this person had listed their questions in plain English, we definitely would've put a lot more effort into helping them.

I don't intend to come across as snobbish in this post. I use IM-speak a lot myself, and I abbreviate words when I'm on Twitter. But when I'm trying to solve a customer's problem, I'm not out to show what a l33t hax0r I am. And in the same vein, when someone approaches me with a problem to solve, I definitely prefer it to come in clear and concise language.

Am I being too old fashioned here? What do you folks think?

Honesty Is the Best Policy

My dad used to have a plaque that read "If you can't dazzle 'em with brilliance, baffle 'em with bullshit." I saw this employed quite frequently when I was evaluating test tools.

When I would setup demos from tool vendors, I was always up front about my needs and what I was looking for. Then I'd watch whatever they prepared and ask any questions that sprang to mind. Sometimes those questions would stump the presenter, and he or she would come up with some answer that was choc full of buzzwords that didn't mean anything. I never felt the need to call people on this - because in doing this, they answered a different question, which is how honest they are. I tend to avoid doing business with people who BS me, because I never know if I can trust what they're saying. It's hard to get work done when a trust issue is always nagging in the back of your head.

I have no problem with someone telling me "I don't know", so long as that is immediately followed by "But I'll find out and get back to you." I appreciate the honesty and I respect the person more as a result of it, and I think many people share that sentiment. I would much rather work with someone who didn't know an answer and found out for me, rather than someone who'd invented something that sounded good at the time, in order to turn a quick sale.

Now that I'm the one giving the demos, I always try to prepare well in advance so I can address any questions my client may have. And when they stump me, I don't follow the advice on dad's plaque.

Screenshots Need Accompanying Info

It's said that a picture is worth a thousand words, and quite frequently, testers attach screenshots to their bug reports to illustrate a particular issue. While this can provide additional information that's helpful to a developer, I've noticed a lot of people lately who just log screenshots as bugs, with no steps to reproduce. For example, I recently received an email saying "The tool doesn't work - see attached" The attached bitmap showed the application with a blank screen; there were no error messages, no data, nothing that told me what didn't work, nothing that told me how it had gotten into this state. The back-and-forth email chain that ensued could've been avoided completely if the person had given me the steps they were performing and what they were trying to achieve.

To encourage people to provide more information in their bug reports, try this at your next team meeting. Say "My car wouldn't start this morning. Why?" Before anyone can answer, quickly add "Oh, and here's a screenshot of it" and have a photo of your car. Hopefully this drives the point home.

You Have Control

How many times have you walked out of a meeting, grinding your teeth because someone said something that upset you? I've seen this scenario happen a lot over the course of my career, and it usually ends up with the upset person venting to a friend or co-worker who had nothing to do with the situation. Nothing ever changes between the upset-ee and the upset-er, because they don't communicate with each other.

I experienced this earlier this week. I left a meeting and was steaming mad at one particular participant. While this person had valuable things to say, they were rude and condescending, and their behavior really insulted me. I ranted to my family for a while, but it didn't help. So I sat down and wrote a very polite email to this person. I explained that I valued their input, and that I wanted to work with them, but that they had been condescending.

I didn't demand an apology, I didn't use any harsh language. I sincerely thanked them for their comments (which I really did appreciate), and stated my issue with their behavior. Once I clicked the Send button for that email, it felt like a huge weight lifted off me, and my mood improved dramatically.

So remember, you can't control other people, but you can control yourself. I tried to handle the situation with diplomacy, and while the jury's still out on what the outcome will be, I felt better because I actively did something. So next time someone gets you riled up during a meeting, step back and think about what you can do to take a measure of control in the situation.

Free Presentation Helper Tools

When I'm giving presentations & demos, there are a handful of tools that make things go much smoother. The best part is that all these tools are free.

ZoomIt - this is a magnification and annotation tool. I use it to zoom in on areas of interest within my application, and to draw callout arrows on various bits of the app I'm demonstrating.

Keyboard Jedi - this app displays any keyboard shortcuts you've pressed. For example, if you press Ctrl+Space in Visual Studio to open a code completion window, KeyboardJedi displayes Ctrl+Space. This keeps you from needing to repeat a bunch of keyboard commands to your audience as you're going through your presentation.

CoolTimer - This is a simple timer application. I set it up as a count down timer to show when a presentation will begin. This is nice because my audience knows exactly when things will be starting.

QRes - This is a command line application that changes your screen resolution. I have a batch file set up to change my resolution from high - 1680 x 1050 to something easier to read (1280x1024). I just run this batch file before my presentation and I don't need to worry about monkeying around with display settings.

Going Virtual

Virtual machines are a great way to try out new apps without fear of completely hosing your system. I frequently use them both when I do testing, and when I give demonstrations. I use both VMWare and VirtualPC, depending on the scenario I'm working on.

One thing I've found is that Microsoft has several prebuilt virtual machines that show off some of their applications. The Visual Studio 2010 CTP is available as a VM, and there's a complete working TFS system as well.

For demonstration purposes, these are perfect because they're already set up and configured properly. That means you can spend your time on developing a worthwhile presentation for your client, rather than monkeying around with setting a system up.

So before you build a VM, run a quick search on Google to see if there's a pre-built one out there. It can save you lots of time and effort.

Dead Air

When you give lots of presentations, sooner or later something bad will happen while you're in the middle of a demo. Either your machine will crash, or the app you're demo-ing will freeze, or one of any number of things. In times like this, you don't want to be standing in front of your audience just looking goofy. That's why it's always good to have a handful of canned conversation pieces at the ready.

I typically will use the opportunity to gather more information from my audience about what they've done in the past for test automation, or what their biggest challenges are. (Normally you should learn these before you give a presentation, but sometimes that doesn't work out. If you have learned what their challenges are, this gives the audience a great chance to further elaborate on their situation.)

Alternatively, you can use the time to mention certain "side notes" that may be relevant to the audience. These include things like user conferences, training resources, or books & blogs that may help them.

Some folks like to fill this time with jokes, or anecdotes about their kids. Do this with caution. Gauge your audience and decide if that sort of filler is appropriate. I've found that the more I can keep the discussion focused on the audience and their needs the better.

What sort of things have you done to help combat dead air? Drop me a note in the comments