Sunday November 20, 2005

Software as a Product

One of the things I am trying to do here is to foster an understanding of software as a product. We talk breezily about the "value proposition" that we offer the customer, and about the "return on investment" that the customer will realize, but by and large I think our industry has very little critical understanding of the real financial implications of what we sell, or of why we price software the way we do. (Sun is a notable exception.) Sadly, the analysts that follow the industry seem to suffer from the same lack of understanding.

Fortunately, some sharp minds are starting to think and write about these issues. On the O'Reilly site there's a terrific article by Robert Lefkowitz that applies modern techniques of financial analyisis to software pricing. It makes a strong case for the use of open source software, based on the sophisticated use of option pricing theory.

Sun has made some bold decisions in the open source arena, and I hope that as Wall Street begins to see how its own analytical techniques apply in our world, they will begin to understand what we're really up to.

Thursday November 17, 2005

Are product managers really clueless?

Am I really necessary? My software heroes often have nasty things to say about what I do. For example, Paul Graham, one of the most perceptive observers of the software world, in one of his best essays wrote that "... if you can figure out a way to get in a design war with a company big enough that its software is designed by product managers, they'll never be able to keep up with you."

Hmm. So the product manager actually subtracts value....

There's no denying that Paul made a small fortune writing software without the assistance of product managers. (For the full story, see his terrific book, Hackers and Painters.)

I do think that a lot of developers think of product managers as clueless suits who just get in the way of building what really ought to be built. But I think that this attitude is really a symptom of a larger fear. Developers are starting to fear that software companies regard them as interchangeable functionaries, as "technicians who translated the visions (if that is the word) of product managers into code" (Paul's words), and who can easily be outsourced to whatever country is currently offering the lowest cost programming labor.

I think if we return to the motion picture analogy, we can see that the enlightened product manager makes a valuable contribution to the process of software development. On a movie crew, if the product manager is the producer, and the development manager is the director, then the developers are the cinematographer, set designer, lighting coordinator,  and all the rest, all of whom are artistic professionals who make great contributions to the finished product. Some producers foolishly try to control every detail of a production, and the movie suffers for it. The enlightened producer regards the crew as a team of of artists, all of whom contibute to making the product a successful, elegant creation. Often, his best strategy is just to get out of the way and let them do what they do best. Similarly, the wise product manager sets a general direction for the product, figures out what features the market is looking for, then watches happily as the crew comes up with one wonderful suggestion after another.

My preferred work style is to put my feet up on my desk and just pick from all the great stuff the developers come up with. ;-)

Wednesday November 09, 2005

The Craft of Software Product Management

I promised when I started this blog that I would talk about my profession, software product management. I think the best way to start is to post an article I wrote about it sometime ago, before I started at Sun.

Nevertheless, there is a central task at the heart of the software product manager’s role, and it is this: The product manager decides what the product will do. In computer industry jargon, he "defines the functionality of the product." The jargon merely glorifies what is in essence a simple task.

Of course, software product managers lead very busy, complex work lives, performing hundreds of separate tasks. Yet the best product managers always remain conscious that their overarching responsibility is to create the definition of what the product does, and to make sure that the definition is carried out. This last is a vital point, for the specification of functionality will ultimately be meaningless, if at the end of the development cycle, the product that is released doesn’t actually do what the product manager had intended it to do. In reality, product mangers spend more of their time making sure their vision of the product is actually given flesh than they spend in creating the vision.

Let’s make one thing very clear. Software product management is not software project management. In the typical organization, the whole process of architecture, design, coding and debugging is not under the product manager’s control, though he is obviously keenly interested in the process. The development process is usually under the control of a project lead who manages the team of developers. In many organizations, the development process is also monitored by a program manager or project manager. But all these people, though they manage the design and construction of the software, have nothing to do with the specification of what the product will actually do. That responsibility lies solely with the product manager.

There are many methodologies for managing the development process, and (unlike the product management process) many books have been written about it. Two of my favorites are Frederick Brooks’ classic, The Mythical Man-Month, and Steve Maguire’s Debugging the Development Process.

The point of the story is that classical product management is marketing driven. The classic "marketing mix" taught in business school consists of four elements: Product, Pricing, Place (distribution channel) and Promotion. The classical product manager is a marketing executive. As such, she exercises a large degree of control over all four elements. The four elements are considered to be more or less equal in importance. In fact, the Product element is often the least important of the four.

Contrast the typical software product manager’s job with the Tide product manager’s job. In software product management, the Product element is the most important part of the four-part marketing mix. Tide’s ingredients rarely change; your product’s feature set may change every three months. Her job is to manipulate the other three P’s in order to successfully market one brand of a product that is essentially a commodity; your job is to add the features to your product that will prevent it from becoming a commodity.

The inadequacy of the classical product management model when applied to software can be seen clearly by looking at the real world of software products. The classical model assumes the product is a) relatively low-priced, b) sold to consumers, and c) sold in millions of units. This is not the reality faced by the software product manager. In the real world of software, the product is probably priced in excess of 100 thousand dollars. It is sold to businesses, not consumers. And the number of sales in a year is probably less than 200.

But wait, you may argue, doesn’t Microsoft sell low-priced software, directly to consumers, and by the millions of units? Of course, you are right. There is an exception to every rule. In this case, it is the exception that has caused the rule. In the early days of the personal computer (PC) industry, there was a plethora of PC software vendors. These companies produced exciting innovations like spreadsheets, personal money management programs, word processors and Internet browsers. By and large they are all gone: merged, moribund or bankrupt. Why? Because if they produced anything that truly had the potential to be a mass-market product, a competing version was soon available from Microsoft, often for free as part of Windows. Microsoft Excel drove out Lotus 1-2-3. Microsoft Word has largely supplanted WordPerfect. And, most infamously, with Internet Explorer bundled with Windows, Microsoft has displaced Netscape as the leading supplier of Internet browsers. As Walter Mossberg noted succinctly in The Wall Street Journal,

Walter Mossberg referred to another reason for the demise of consumer-oriented software companies: the Internet. Consumer software companies, particularly those that are content-based, simply cannot survive when most of what they provide is available for free on the Internet. Consider Encyclopedia Britannica, the world’s greatest reference work. It contains 55 million words of unparalleled scholarship. For more than two hundred years, its print edition was a lucrative cash cow. It is still available, at a price of $1295.00. With the advent of the software revolution, Britannica had to start offering a CD version that now sells for $29.95. With the coming of the Internet, Britannica has made its entire content available on line by subscription for $7.95 per month. Abbreviated entries can be searched and retrieved without a subscription. Clearly, the chance that a new software vendor would be able to successfully market a new CD-ROM encyclopedia is nil. The Web has already allowed the competition to reach the ultimate price-point: zero.

What it means is that, unless you work for Microsoft or a handful of other companies, you are going to be the product manager of a product that a) sells for more than $100,000, b) is sold to businesses, not consumers, and 3) at least initially, sells only a few new licenses per year. As we shall see, this means that the classical model of product management will help you very little. The bad news is that you will have to learn an entirely new craft, the craft of software product management. The good news is that software product management is one of the most exciting, interesting professions that one can practice.

Thursday November 03, 2005

My short career in the phone sex industry

Many years ago, out of work and getting desperate, I accepted a consulting assignment at what was believed to be the world's largest provider of phone sex. It was housed in a large complex of buildings in the San Fernando Valley (natch). There were about 500 employees, male and female, who manned the phones, but the heart of the operation was a massive DEC VAX that was used as a telephone switch. There were about 25 programmers on staff, and a full time person who built and repaired PCs in their own shop.

As I said, this was a long time ago, but looking back it is striking to me how much this operation was a precursor to things we now take for granted. The use of the VAX to route incoming calls was a prototype of the massive call centers we have today, and a form of "hosting" could be seen in the fact that smaller phone sex companies subscribed to the switch for the routing and billing of their own incoming calls. Outsourcing was in play too, for the big company would "lay off" incoming requests for phone sex onto these smaller providers when its own staff was maxed out.

But beyond that, I think there are two major lessons I learned there. Both of them have been remarked on by many commentators, but they were demonstrated first hand to me there:

1) Technology is utterly amoral. (For a recent meditation on this, see Nicholas Carr's essay here.)

From pornography to smart bombs, technology doesn't care to what uses it is put. It's up to us poor human beings to think about what we build, and to balance the good they'll do against the evil they might do.

2) Less important, but fascinating: the early adoption of new media is often driven by pornography. I don't have the exact quote, but Patrick Dennis in  Auntie Mame talked about finding some very old photographs showing "some old-fashioned looking people in some surprisingly modern positions." An early precursor of the Internet, the French Minitel, became a conduit for text-based pornography very early on. I read recently that the next thing on the horizon is pornographic video delivered to cell phones. All it takes is bandwidth. An interesting essay on this phenomenon, here, argues that tolerating it is important in order to subsidize the early growth of new technology.

Anyway, I got fired off that job in about a month. I guess my heart just wasn't in it.

Monday October 31, 2005

More books on human interface design

Jeffrey Olson, in a comment below asked if I could recommend any more books on human interface design. I'm happy to, but I haven't read these myself. Instead, I went back to Sun SeeBeyond human factors guru Dr. Gary Olasci for his recommendations. Here are his big three:

GUI Design Essentials, by Weinschenk, Jamar and Yeo. Note that this book emphasizes Windows design.

Designing Web Usability, by Jakob Nielsen. He also runs a cool web site. That's why I love answering questions: I learn so many cool things!

And finally, by our own beloved alma mater: Java Look and Feel Design Guidelines. 

Now that I've recommended these books, I'll have to read them! That's what I love about this industry: you never stop learning.

Friday October 28, 2005

Great human interface design book

One of our Sun SeeBeyond human factors gurus, Dr. Gary Olasci, loaned me his well-thumbed copy of The Design of Everyday Things by Donald Norman. What a great book. It's not just about GUI design. In fact, it's more about how to design things like door handles and light switches so that they intuitively make their function known to the user. One of the most striking observations is that when the number of functions exceeds the number of controls, confusion sets in. If there is one control for each function, like a knob for the radio's volume and another for the frequency, no problem. When you have something like the extreme case of the BMW iDrive, where one knob controls 800+ functions, you're in trouble. With a computer interface, you've got thousands of functions. That's why it's so important to provide clues, like drop-down menus, that guide the user through functions that are too complex to memorize easily. Without the Outlook menu to remind me that Ctrl+Enter means "send," I would have forgotten it long ago.

Thank God for the human factors guys like Gary O. It's easy to cite these principles, very hard to apply them!

Tuesday October 25, 2005

Producer and Director

One of my favorite books about software development is The Mythical Man-month, by Frederick Brooks. I suppose it's one of everyone's favorites, but it's still amazing that so many of its precepts are ignored on a daily basis.

My favorite piece in the book is the one that compares making software to making a movie. Both require a producer and a director. The producer is analogous to the product manager. The director is analogous to the architect/development manager. The main function of both is to prevent the other from going off in a crazy, expensive direction.

(Brooks lifted the analogy, with full credit, from one of Robert A. Heinlein's best stories. How cool is that?)