How Not to Sell Your Work…Talk Technology Not Pain Relief

We recently had a contractor come to our house to give us an estimate on replacing an old, metal, drafty patio door.  My impression was that he was extremely knowledgeable and capable contractor.  But after an hour, I didn’t feel like I had enough information to confidently make a good decision about which option to take, and we’ll probably not buy from him in the near term.

As I thought about the episode, I realized the contractor failed to sell me on his services in the same way that technology developers/designers fail to sell their clients on their work:

He did not ask us what problems we wanted to solve, or what goals we wanted to address.  Instead, he came in spouting off meaningless specifications about specific products.  I didn’t know anything about R factors or UV specs or double vs triple pane glass, so the fact that this product has a .2 or a .07 means nothing to me.  Is that good?  What’s the typical range?  How does that compare to what I have now?  And most importantly, how much might we expect to save on our energy bills going with the super-awesome door vs the middle-of-the-road door?

This is similar to software developers…I know we tend to get caught up in, “we should use this tool because it supports this new web standard” or “we should buy this because it has 1.21 gigawatts of power.”  Clients don’t care about any of these things.  They have a problem they want to fix, or an opportunity they want to attack.  All they care about is can you help them solve their problems.

Sell your work by focusing on the clients’ problems

  • Understand your clients, their pain and their goals. What’s hurting them or prompting them to make the change. What do they want to achieve as the result of the change (these two aren’t always the same).  The core of the discussion should be that you can alleviate some of their pain.  Once a client is on board with that, you can get into the details.
  • You may want to avoid, or at least postpone, discussing the quantitative specs of the tools or systems you’re proposing.  At best, your customer will gloss over this ‘irrelevant’ information and you will have wasted their time, and your opportunity to speak to them meaningfully.  At worst, you’ll have a customer like me that wants to make sense of the numbers, and you get stuck discussing minuscule details?  You want a 8 core processor?  What do people normally use?  Is that high end or low end?  Why can’t we make it work with 2 processors?  I read that Google uses lots of really cheap single processors in Wired…can we do that instead?  This leads to…
  • If you do need to get into the details, provide a frame of reference for your discussions. Instead of providing raw numbers like “the error rate on this page is 29%” give it a frame of reference, eg “On pages like this, we see error rates from 25-30%. The current page has an error rate of 33%; the suggested changes should reduce it to 27%”.
Advertisements