Pain Points

I hate buzzwords as much as the next geek, but as I live with someone with chronic pain, the concept of a "pain point" is way more than a PHB or marketroid buzzword.

Pain points are just that -- the points in a system which cause pain. Without pain, there's no desire for change. If you don't hurt somehow, there's no motivation to do anything differently.

As the recent discussions around e4 have shown, there's a lot of pain. Pain motivating a new approach to Eclipse 4.0, pain in how this new project has been perceived as closed, already fully-fledged, unopen to contribution, or too Blue.

Ed and Bjorn have recently blogged about the fact that perception is often more important than reality. Fact is, we perceive pain sometimes when there's nothing there. It could be a perceived slight, or it could the result of feeling someone's solving the wrong problem, or solving it in a way you didn't expect or want. I'm not trying to say that one's perception is necessarily wrong, only that it may not have been intended, or that in terms of the bigger picture, it may not be helpful.

Let me give you a recent example from my life. My dad attended a conference recently in Niagara Falls and at the end of it, came up to Toronto to spend a little time with my brother and I. When it was time to get him to the airport, I called the car service I've used for the past couple years and Sam came out -- arriving early as always -- and took him to airport. (They make a point of -- if possible -- always sending the same driver.) But when I told my father that instead of driving 45-60 mins to and from the airport I was putting him in a car and outsourcing the task, he was offended. Apparently, this was not the solution he'd been expecting.

Let's look at the pains here:

Pain Point #1: Dad needed to get to the airport.
Pain Point #2: I didn't want to waste 90-120 mins of my life driving across the 401 and back.
Pain Point #3: I hate driving, and avoid it as much as possible. I'm a cyclist/ hiker/ walker/ kayaker, not a driver.

And the expectations:

Expectation #1: Dad expected I'd drive him.
Expectation #2: I expected that the goal was to get him to the airport, method notwithstanding.
Expectation #3: I expected to pay for the transportation to the airport, either in time (90-120 mins) and money (gas), or else just in money (hiring a car). To my engineer's brain, assuming my time is worth $50/hr, the cost of driving him would be $75-100 and the time lost. Hiring a car would be $60-80, including tip, with no time lost. A no-brainer.

As Ed discussed in his post, sometimes even when you solve a problem, people feel it could have been handled in a better way.

What's the lesson here? Like it or not, we are all marketers. Everything we do colours reality, changes perception, and controls how our work is seen by the world. Even as geeks, it's sill not enough to build great products, solve unsurmountable problems, or right wrongs. You have to take away the pain and give your customer/user/colleague/manager/stockholder a buzz while you're at it. Like amputees experiencing phantom limb, you can take away the pain but the bad perception can linger on, so it's important to sell it right the first time.

And if you do screw up and need to spin a mistake into a success, do it like Coke did.