How to Sell to Real People

(Dean and Gordon have been busy doing administrivia so they let me guest blog today.)

Microsoft’s new ad campaign is all about how Microsoft connects with real people. Bill Gates and Jerry Seinfield act out a mini-reality series about how they need to get in touch with real people. TechCrunch is not buying it, and I can see why.

Microsoft wants to show they understand real people. But like most big companies, they only understand the CIO, the CTO, and the head of IT because that is who they sell to.  They have long forgotten what helps me and my fellow workers.

Microsoft is not alone in this. Most companies forget what it’s like to be a worker bee. This is because the executives that make the decisions are removed from what their employees do.

I, for one, am drowning in email and PowerPoint and Word documents and meetings. I have no time to do my real job. I waste countless hours of my day looking for that document that Steve sent me… last week I think… is this the right version? No, this isn’t it. Maybe he didn’t email it. Maybe he stuck it on the share drive. I’m sure it’s on his machine somewhere, but Steve is in a meeting. I can’t find him… maybe Don has a copy?

Where’s the Microsoft product to help me, a real person, solve these mundane real-world problems? I need to re-find the things I have, share with my co-workers and managers without interupring my workfind the expert I need, work offline for a little bit, and focus on getting things done.

Once upon a time Microsoft did actually sell to the indivdual knowledge workers, and their software was leading edge. I bought a copy of Excel because it was better than Lotus 123. Many of us switched to Word because pasting images and slides into documents was cool. Multiple undo was a killer feature for real-world folks like me who ocasianally sometimes misspell stuff.

Microsoft are confessing they are a bit out of touch with these new ads. The reason for this is because long ago they stopped focusing on the end user, and started focusing on their (much more lucrative) OEM and Enterprise licensing customers. But the needs of enterprise customers rarely intersect with the needs of average consumers.

What sort of Xbox games would Microsoft make if it sold them to the local PTA?

Underestimating Openness

While browsing the feed from Content Management Connection, I noticed that Oscar Berg re-blogged David Wineberger’s notes on the nature of openness taken at a seminar given by James Boyle.

The gist of the talk (and the notes) is that people routinely overestimate the risks of transparency and undervalue the benefits of openness. It’s a hard habit to break. We assume that increased control will lead to increased security. But there are situations where the reverse is true.

Which is more secure from a group of second-graders: A cookie in plain view on the breakfast table or one in a ceramic jar on the kitchen counter?

Psychologists have done this experiment. The cookie lying out in the open is the most secure. Everyone can see if it’s missing or if someone took a bite out of it. If one of the kids takes it all the others will know — and at least one will probably tattle. Only if all the children work together can they get the cookie and get away with it. That requires the children to work together closely and divide the spoils fairly.

The cookie in the jar is actually less secure because any one of the children might be able to sneak it without the others knowing. (And now you know why most jars of candy are clear glass or plastic!)

Information is Brain Candy

The same logic that drives the cookie experiment is the logic that makes sunshine laws, open source software, and Wikipedia work.

Security is often the first concern raised by organizations implementing collaboration tools. But openness can actually lead to better security.

Taking Sides

Does your enterprise software have an opinion?

Or does it just provide you with a bunch of tools, and little insight into how to use them?

Jason Fried, at 37 Signals has a seminal post about Opinionated Software. He argues that the best applications “take sides” and provide direction to their users.

From an engineering perspective, the best way to build a flexible solution is to build an abstract one. “Hey look”, said the guy who built SharePoint. “Everything that people do on their intranet is just a list!”

“There are lists of contacts, and lists of documents, and lists of folders, and lists of tasks, and lists of goals… Let’s build a generic list engine, and they can all use that instead of their home-grown corporate intranet.”

But a  problem arises when the customer buys into the marketing hype — into the idea of having a central, flexible collaboration center — and then gleefully tears open the cereal box and discovers… an abstraction.

Everything is a list!

“What’s that?”

“It’s a list engine. You can use it to share lists of all kinds of things, with all kinds of people.”

“Oh. Well, I wanted something that was going to help manage my projects.”

“Oh, it can — your projects are all just made out of lists.”

“They are?”

“Sure! Here, we’ll hire a consultant to explain it all to you…”

If you are trying to delight your customers, you need to step out of the abstraction, and into actual problems. Apple make opinionated software. Steve Jobs doesn’t think you should be able to cut and paste on your iPhone. That’s an example of the design forcing users to behave a particular way.

Part of SharePoint’s success in current iterations has come from partners, and from Microsoft providing users with built in “templates” that allow the user to skip the abstractions, and get straight to work managing projects, or processing insurance claims, or whatever it is they they do.

Abstractions are very, very useful to engineers, but by themselves are not very useful to the people who need to apply them in the real world.

If your enterprise solution is forcing you to learn weird abstractions, chances are the developers don’t really know what you want to do with it.

The Clock is Always Ticking

Paul Graham posted a Fundraising Survival Guide for start ups to his website. It’s a subject that’s been on my mind a lot lately.

When we started Infovark, we had roughly enough money to get through the first year. We did a fairly good job of budgeting, all things considered. We’ll be able to stretch our initial round further than planned, basically because we hired a few specialists under contract rather than another full time employee. We were also pleasantly surprised at the number of high quality software development tools you can get for free or at reasonable cost. (Microsoft’s Empower for ISVs was a particular boost.)

But when you’re a startup, the clock is always ticking. I can hear it now: “Time is money is time is money….” This is the mantra of the founder. It’s what gives us sleepless nights. It leads to fear and indecision. The search for additional funding can obscure the real goal of starting the company: building something useful — and having fun while doing it.

Infovark has by far been the best work experience of my life. Not merely because the Burrow is conveniently located in my basement — though it’s nice not to fight traffic — but because I’ve finally gotten a chance to create a product from scratch. I’ve never had the chance to do that before, and I’ve been learning a lot in the process. (That’s entrepreneur shorthand for making more mistakes faster than ever before.)

I’m really excited about this stage of the project. We’ve gotten an initial round of feedback from our alpha testers, and we’re mapping out the plan to get us to beta. But I can also hear the clock ticking…

That means at some stage — probably sooner than we’d like — we’ll have to leave the Burrow in search of funding. It’s a scary prospect for introverted software engineers. We’ll have to explain what we’re building, why we’re building it, and why you ought to invest in it. That means we’ll have to define why people will want to buy it and how much it will cost for them to get a copy. These are yet more things to add to our long, growing list of things that aren’t writing code. Except that getting funding is far from trivial, as Paul Graham points out. It’s a matter of survival.