I would like to add, that only weenies take over the aggregators by upgrading their WordPress. Real men just write absurdly long blog entries.
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:
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:
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.
The tripleverbs are flowing in! Todays discoveries include Squarespace, Caesar, Static Photography, Flickr, Mono, Gather, Essembly, and Sonicare. Thanks to everyone who discovered, shared, and celebrated new tripleverbs.
According to an an article in today's paper Clayton Christensen took a stand for design over megapixel in last month's Harvard Business Review. I'll have to find a copy.
Harvard Business School professor Clayton M. Christensen is trying to shake up the marketing establishment with a deceptively simple proposition that flies in the face of conventional wisdom: People hire a product to get a job done.
Sometimes the job is functional: I need to send this document from here to there as fast as possible. Other times it is emotional: Help me escape the chaos in my world. And often it's aspirational: I need to feel pampered. Different products -- Federal Express, Apple's iPod, and Gucci's handbags -- are retained for these different tasks.
Marketers, however, ply their trade in a whirl of product extensions and customer segmentation increasingly divorced from the realities of needs and jobs. They focus on bells and whistles, features and options, baby boomers, soccer moms, and upwardly mobile young professionals with disposable income.
Employing customers or products as the fundamental unit of analysis -- rather than jobs -- amounts to ''marketing malpractice," Christensen and a pair of coauthors contend in a provocative essay in last month's Harvard Business Review.
...
Christensen, in an interview, said product managers should spend less time on market research and more time walking around and observing how people live their lives -- their habits, behavior, and cycles.
That last paragraph especially points toward ethnography-driven product design... something one can get a college degree in, or at least read stacks of books about. And something one can have natural talent for (or not - I don't). How many product managers have this kind of skill? How many tech companies have both a product management and a design/usability function, and does that make any sense? Seth Godin might go further and wonder why marketing is also separate, since he argues the core of marketing is the product/service offering itself.
(Caveat, the title "product manager" can apply to lots of jobs, I'm referring to a product manager who designs and specifies the details of a new product, not one who's a project manager, customer request manager, logistics specialist, or partner relationship manager for example. "Marketing" of course also includes a lot of different jobs.)
There was also a great article from Walter Mossberg a couple days ago.
In fact, the industry operates on a false model of the U.S. computer-using population. It imagines the world is divided between "consumers," who lie around at home playing games and listening to music, with the occasional homework assignment or tax form thrown in; and "enterprises," large corporations where computing is controlled by IT departments and only mission-critical tasks are performed.
If these models acknowledge small businesses at all, they get lumped into a category called SMB, for small and medium businesses, where the minimum size is something like 500 employees and an IT staff rules.
In fact, the most accurate way to divide the computer-using world is into two segments: the one controlled by an IT department and the one controlled by the people who actually use the computers, be they consumers or small-business folks. A vast amount of business crucial to the U.S. economy is conducted every day in the non-IT part of the computing world.
The computer industry loves, and caters to, the IT segment because it buys machines in large quantities and is run by a geeky priesthood that speaks the industry language. By contrast, the non-IT camp, even though it is larger in the aggregate, buys one, two or three machines at a time and tends to be nontechnical.
Speculation: if the industry favors selling to industry "insiders" - e.g. IT departments and developers - this is in part because an engineering/IT-driven organization, as many tech companies are, will have a much easier time figuring out how to build and market a product for other people like themselves.
There are other, more mundane explanations too though I imagine. As demanding as they are, a few large enterprise deals can be a lot easier for a small software company to manage than a couple bucks from each of thousands of consumer customers.