The Endowment Effect

I recently met with some local software business leaders to discuss how the economy is affecting us. Driving to the meeting, I tried to think up a course of action that makes sense during these times. Best I could come up with were:

• Focus - Remove distractions and concentrate on the narrowest scope of business that has the greatest chance of success. This is an opportunity to make some hard decisions about what you're doing and what you're willing to concentrate on.
  
• Leverage existing success - Go back to your existing installed base and make sure they're happy, and upsell them as much as possible. Do this with existing products rather than the newer, riskier products.
  
• Plan for the future - Assuming your ability to focus and leverage existing success allows you to weather the storm, this will be a unique opportunity to exploit the ensuing landgrab that happens after the weak have been eliminated from the competitive landscape. Don't sacrifice this future investment for some short-term gain.
  

The interesting point is the second, "Leverage existing success." Something about this felt right, but I couldn't really explain why. This morning I was reminded of a psychological phenomenon called the Endowment Effect. This tells me that my existing customers value our relationship and the products I've sold them more than new customers value that same potential relationship and my new products. I'm going to have much better luck leveraging existing customers more than I am acquiring new ones.

We all know that it costs much more to gain a new customer than to service an existing customer. The Endowment Effect underscores the importance of the asset that is an existing, happy installed customer base.

Another point of validation for the third point, to plan for the future, came yesterday by a Harvard Business Review's blogger entitled Prepare Your People for the Upturn. Good advice.

Stakeholders

Rob was complaining this morning on Twitter about how much he hates the company's time tracking system. I think about HR applications from time-to-time, mainly as an example of how *not* to develop an application.

Every HR time tracking application I've ever seen or used has the following problems:

• It is antiquated. Probably designed between five and ten years ago and purchased at a ridiculously high cost, the business cannot justify the ROI to upgrade or replace the system.
  
• It has amazing usability problems. I imagine these systems being built to some spec by an overseas sweatshop under contract. While technically they work, they rarely work well.
  
• It frustrates the crap out of thousands of users every day, but then again, who asked them?
  

The trouble with these systems is that the end-user, as a stakeholder, is rarely considered in the design or purchasing decision.

These applications tend to be the perfect storm of poor design. They are sold to CEO's, HR execs or Finance execs who see them as a necessary evil. These execs know little about the underlying technology, and are ill equipped to do the requirements analysis necessary to clearly articulate their needs to the vendor. They maybe consult their IT people, but then those guys have their own agenda (deployment and operations). They definitely ask the Accountants what they need--since they're the only part of the business that actually has anything to gain from the data the system will collect.

In any system there's a bunch of stakeholders in the mix. In this case the role that will make the purchasing decision, and a few stakeholders who will directly or indirectly use the system (i.e, finance, IT, and the employee). The irony of HR systems in particular is that the user who is most affected by the system in their day-to-day life is rarely consulted or studied in the design or purchase of the system.

Let's say you have a company of 2000 employees. Let's say these employees only need to enter their time once a week, and it only takes them 4 minutes to do it. That's 6933 hours of labor time that's going to be spent in your company each year--just entering time. One would think that those employees would be considered as the single most important stakeholder in the design and purchasing decision of such a system.

So what tends to make these systems so miserable, isn't so much the specifics of their design as much as the fact that the stakeholder who's life is impacted *most* by that design is rarely consulted.

In our business we have a number of stakeholders who need to be considered when designing our products. Not the least of which is ourselves (how will this advance our goals?). We also need to consider our sales channels (what allows them to compete?), our target purchasing decision maker (who's often not the end user), and the end user themselves (whose entire waking life is going to be spent using our product).

What's disastrous is when any of the stakeholders are left out of the design process--or when the priority is wrong. HR systems get this wrong all the time, and it's a shame because it makes Rob's life miserable.

Half

I wrote an article recently that I thought was pretty good. Perfect, in fact. Then I was told that it would need to be reduced by 400 words to fit the company's publication. It was 906 words. Cutting 400 worlds would eliminate half.

I went through every section, paragraph and sentence and figured out how to reduce their respective lengths by half without losing anything important or meaningful. Of course, it was better for the reduction. Clear, concise, to the point. It was exorcized of any passive language. The elimination of adverbs shortened and made it easier to read.

I feared that such a reduction would destroy the piece. Instead it made it better. This lesson reminded me of a previous post on Simplification. Taking my own advice was a healthy exercise.

Using "half" as a complexity reduction target simply feels right. It's aggressive and challenging. When you come out the other side and realize that it's possible, you wonder why it wasn't obvious in the first place.

I recall some advice on travel: when packing for a trip, pack what you think you need, then take half the clothes and twice the money. So true for the scope of software projects as well.

Blogs Are MarCom Without The Cat

See this excellent article from a Cisco blogger on Naked Conversations: Blogging in Global Corporations.

I've heard this before. "We asked MarCom to set up a blog for our company but they can't/won't/didn't because they don't have the budget, don't know how, their dog ate their homework.." Whatever.

Here's the deal. Marketing Communications isn't going to initiate or operate a corporate blog because in most companies MarCom is responsible for the production of communication, not for the communication with customers. Blogs are about communication with customers, with very little to zero production skills required.

Who's responsible for making the phone system work? The phone company. Who's responsible for me calling my wife to let her know I'm going to be late for dinner? Me.

What’s different about blogs is the democratization of mass communication. Years ago if you wanted to get a message out to millions of people you had to engage marketing communications folks because they were the only people with the production and distribution capabilities. But now anybody with an internet connection is capable of publishing content that can reach millions.

Consider the story of Einstein attempting to explain radio:

"You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat."

Blogs are just like marketing communications, the only difference is that there is no cat.

So who's going to run corporate blogs? The people who need to communicate with customers. The CEO, the sales guys, the support guys, the product managers, the engineers, whoever. Who's not going to run corporate blogs? Marketing Communications--because they're the cat.