Havoc's Blog

I went out and bought the December issue of Harvard Business Review to
check out the Christensen article I mentioned earlier;
it’s really a good one. While it’s titled Marketing Malpractice, it
applies equally to Engineering Malpractice and General Business
Malpractice.

It has a literal example of the tagline we’ve been using around
the office for this general line of thinking, “Design vs. Megapixel”:

Kodak scored another purpose-branding victory with its disruptive
EasyShare digital camera. The company initially had struggled for
differentiation and market share in the head-on megapixel and megazoom
race against Japanese digital camera makers (all of whom aggressively
advertised their corporate brands but had no purpose brands). Kodak
then adopted a disruptive strategy that was focused on a job – sharing
fun. It made an inexpensive digital camera that customers could slip
into a cradle, click “attach” in their computer’s email program, and
share photos effortlessly with friends and relatives. Sharing fun, not
preserving the highest resolution images for posterity, is the job –
and Kodak’s EasyShare purpose brand guides customers to a product
tailored to do that job. Kodak is now the market share leader in
digital cameras in the United States.

Lots of other great examples in the article, my favorite one is about
milkshakes. This is how both open source companies and open
source projects need to think about what they’re building.

What does the business or project do, for whom, in what context? How
will someone find the product when they need to do that job? Can you
walk through all the steps to do the job, not only the steps involving
your product?

Because software is infinitely flexible it’s even easier to fall into
the trap of the generic all-things-to-all-people than it is with the
consumer products in Christensen’s article. But ironically, the more
people we think could use our stuff, most likely the fewer
people really will. That’s why you
want to be both loved and hated: when the right people use your
product for the right job, they should love it; but if your stuff is really
good at that job it probably sucks at other jobs. One of the roles of
marketing is to set the right expectations for when and who should try
the product.

Christensen argues that a focused design with a “purpose brand” builds
the most customer goodwill, because you design the product to do a
particular thing for particular people, then guide those people (and
only those people) to try it out. Since they’re using the right
product for their needs, they have a good experience.

Christensen also makes the “experience design” point: it’s not
just about the physical widget or the software bits, it’s about how
you find out about it, how you obtain it, the intangible visual and
emotional design, surrounding services and community, …

This message should be great news for any open source business. If a
complete experience and solution involves a lot more than just the
bits, there’s plenty of business model to be had.

For example, despite all the stumbling about in the early days, Red
Hat Enterprise Linux turns out to be a pretty
complete experience design for solving a particular problem for
a particular audience (a UNIX substitute on commodity hardware for
enterprise customers). Engineering and marketing aligned in making
the product right for that job and selling it to the intended
customers for the intended purpose. (Don’t get me wrong, I don’t
think Red Hat is a shining example of agreeing with me on this
overall rant – not yet anyway! – but RHEL’s marketshare
with its intended audience is not an accident IMHO.)

All this seems like common sense, and it probably is. But in real life
it’s very very easy to get caught up in the corner cases, whether
you’re in marketing or in engineering. We need “corner cases don’t
matter” conditioning I think:

• What about… *smack*
• But these people will hate that… *smack*
• Couldn’t we also use this to… *smack*
• But that isn’t generic enough… *smack*
• But I wouldn’t like that… *smack*
• It doesn’t send email… *smack*

Maybe a big gong in all the conference rooms? That’s how they used to
train the “ums” out of us in speech class.

Let me try and be a bit more on-topic for some of the planet
aggregators my blog shows up on. Think about the history of GNOME (for
example) in this context. The job we were originally successful at was
an interface for developer/enthusiast-oriented Linux
distributions. GNOME was a UI optimized for tinkering. But there are
also strong tugs in other directions that have waxed and waned over
the years. For example, the needs of the “enterprise Linux”
distributions have played a major role (remember that their job to
date is to substitute for UNIX, and UNIX-traditional features are
therefore very appropriate). Other ambitions include the “corporate
knowledge worker” (Windows currently owns that market) or the vague
and poorly-specified “home user” (as Walter
Mossberg just pointed out, Apple has their design center there).

GNOME currently defines itself as “a desktop,” Christensen talks about
why this is wrong:

The great Harvard marketing professor Theodore Levitt used to tell his
students, “People don’t want to buy a quarter-inch drill. They want a
quarter-inch hole!” Every marketer we know agrees with Levitt’s
insight. Yet these same people segment their markets by type of drill
and by price point; they measure market share of drills, not holes;
and they benchmark the features and functions of their drill, not
their hole, against those of rivals.

If I look back on the last few years, substantially contributing to
this problem for GNOME is one of the (software-related) mistakes I
regret the most. I’ve personally been responsible for tugging in
several different directions, and had some of those directions much
too vague and poorly-specified in my mind, leading to fuzzy thinking
and thus fuzzy contributions to discussions. I can think of quite a
few flamewars I could blame on failing to sort out what kind of hole
we’re helping people to drill.

What are the options then?

It’s quite possible that GNOME should move more in the direction of
the Linux kernel. i.e. think of the customer as the developers of Maemo, various
specialized Linux distributions, thin client solutions, and
other focused products with a clear design center. Make GNOME a highly
modular set of parts that can be assembled and modified by downstream
development teams. This is the Linux kernel model, and also typical of
many libraries and compilers and other developer tools. But it’s
absolutely counter to a lot of our “everything upstream”/”forks are
bad” mode of thinking.

If GNOME embraced “building block” status wholeheartedly it might be
able to do that job a lot better. Some half-ass examples:

• The content and messaging on gnome.org could be oriented toward
  developers and explicitly point people away from “raw GNOME”
  (the same way few people use kernel.org kernels)
• GNOME-based derived projects such as Maemo (or Ubuntu, or RHEL)
  become the focus and adding more such projects defines GNOME’s success
• Perhaps one of those decentralized version control systems
  becomes a lot more interesting?

I don’t know. I’m sure that seriously thinking it through would reveal
a lot of good ideas. Here’s the point: deliberately focusing on being
a good building block for developers building derived products is
very different from becoming such a building block by default
due to lack of focus.

If GNOME doesn’t focus on being a “building block,” my personal view
is that some hard choices are in order. Who’s going to love it? More
importantly (to be sure the hard issues aren’t dodged), who’s going to hate
it? How do you clearly set expectations up front in the marketing and
positioning of the project? What about the visual design – if you’re
making something for bored teenagers is it going to be the same as a design
for hardcore UNIX admins? (Hint: hell no.)

What could the text on gnome.org say? Right now it says “GNOME is a
desktop suite,” this is broken. How could it describe the hole instead
of the drill? Who wants the hole and why?

I lean away from the “building block” road, because I’m just not sure
it works for something high in the stack like GNOME. It seems to
barely work for the kernel, and has been a bumpy ride for the X Window
System too. GNOME has too many user-visible decisions to make. But on
the other hand, building blocks seems like the most practical
direction for an open source project. This is a tough question.

GNOME is only one example I happen to be familiar with. Probably
every open source project could benefit from thinking about this
stuff.

A final thought. Since we have Christensen in this post already, let’s
drag in Geoffrey Moore as well. I think sometimes we talk about
“momentum users” and “early adopters” vs. “majority” as if they were
identical to “technical users” vs. “nontechnical users” or
“UNIX-accustomed users” vs. “Windows-accustomed” users.

That feels wrong. I would say, maybe first you have the set of
people who would benefit from your specific focused product. That set
might be “UNIX developers.” Then among UNIX developers, we have early
adopters who like to download and try the latest GNOME, and we have
the people who are still using twm in 2006.

In other words, in
Moore’s diagram the wedge labeled “technology enthusiasts” isn’t
all technology enthusiasts. It’s the subset of technology
enthusiasts who are also in the target audience the product
was designed for.

If I’m right about this, then getting lots of UNIX developers to early
adopt something does not lead to getting a lot of bored
teenagers to adopt down the line after you cross the chasm. It leads
to converting all the hardcore twm users down the line after you cross
the chasm. If you focus on UNIX developers, the total size of the
market in Moore’s diagram is simply the set of all UNIX developers,
not the set of all people in the world. Similarly, if you focus on
people who love music, there’s no reason to expect that the early
adopters will even know what UNIX is.

An implication is that as a company or project talks about
customers to focus on, it might be beneficial to have a description of
the customer that spans all the parts of Moore’s diagram, and then
perhaps discuss the early adopter and majority variants of that
description. But your early adopters should basically share the same
goals and attributes as the majority, aside from relative openness to
new products.

I haven’t re-read Moore’s book in a long time so this may already be
addressed there or just make no sense, who knows.

(This post was originally found at http://log.ometer.com/2006-01.html#3.2)