The seven Eskimo rules of designing icebergs

Blogs consisting solely of bullet points seem to be popular these days, if Guy Kawasaki's rather lazy blog is anything to go by. This morning, Microsoft's Don Dodge detailed venture capital firm Kleiner Perkins' list of seven rules for software startups, as told by KP partner Ajit Nazre at a recent conference.

1. Instant Value to customers -- solve a problem or create value with the first use
2. Viral adoption -- pull, not push. No direct sales force required
3. Minimum IT footprint, preferably none. Hosted SaaS (software-as-a-service) is best.
4. Simple, intuitive user experience -- no training required.
5. Personalised user experience -- customisable
6. Easy configuration based on application or usage templates
7. Context aware -- adjust to location, groups, preferences, devices, etc.

Applying this kind of thinking to enterprise 2.0 software projects is instructive. #1 is a no-brainer, as is #4, but outside that you start getting into contested territory. Customisability and configurability are the enemy of locked down desktops in standard operating environments, although as long as user preferences and data are stored exclusively at the server and delivered via Web technologies then that shouldn't be a problem. (As an aside, SOEs militate against Dave Winer's vision of desktop mirroring of Web app data.)

Context awareness is also something which would have to be aligned with a SOE strategy to ensure that the two issues did not conflict. Not that the two concepts are diametrically opposed: if your projects are all completely Web-based while being eminently customisable, that makes SOEs far easier to implement and maintain without taking anything away from the user experience. This also applies to the rule about minimum IT footprint, of course.

Viral adoption is an idea not foreign to large companies, but it would be a rare company where that method of encouraging employees to use a new system is the norm. To those who don't drink the 2.0 red cordial, it doesn't look good for ROI on an expensive project if you have to hope that employees take it up just because it's "cool" or "fun".

Ben Barren's discussion of these rules got onto the topic of the amount of time you have to spend on building admin code that the user never sees, as opposed to interface and design. This discovery is also one I have made in the course of coding for my sites, but I'm sure IT managers reading this would be yawning, not only because they've been up late watching Australia v Brazil but because they know the shape of the development iceberg and how much time they have to spend building the bits under the waterline.

However, the 2.0 way of "instant value to customers" is also positive the other way, since the programmers get to find out very early in the project what the users want. One implication of this method is that users get to give feedback before the project is finished, or possibly before it is fully designed. This allows the possibility of the users contributing to the design. In effect, you could let the Eskimos help design the iceberg. To mangle another Winerism, it would be like Eskimos and ice sculptors partying together.