DON’T Ask the Users What They Want! (Continued)

Brady Joslin commented on my first post about great products saying that you should look at what the customer’s problem is but not ask the customer how to solve it.  He is absolutely right although, in an extreme case, the customer problem at first blush may not look anything like the innovative solution that will make it go away. 

In that earlier post I blogged about VisiCalc as a solution to a problem no one knew he or she had: spreadsheets written on lined accounting paper don’t recalculate themselves when you change an assumption or correct an error.  People didn’t know this was a problem because it never occurred to them that there could be a solution.  And, of course, the problem wasn’t with the paper spreadsheets; it was with the use of paper spreadsheets to do what-if analysis.

My own best product (ideas don’t count unless they turn into products or services) was implemented as Macintosh software called Glue.  The product was a predecessor of Adobe Acrobat. It makes a good example of implementing what users need rather than what they say they want because I know the whole story.

I had two projects that were on my mind.

Wife Mary and my first company, Solutions, Inc., had a contract to develop an MCI Mail client for the Macintosh.  This was before public use of the Internet and so mail ran on proprietary networks.  Our customer was a rather ungainly alliance of MCI, Apple, and Dow Jones, which then published software.  One goal was to use the great new Mac GUI to make the product easy to use – that was a snap.  The other goal was to let email be more than just ascii text.  After all, everything produced on the Mac had a graphic character.  Oh yes, we also had to be able to print all email so that it could be snail-mailed to recipients who didn’t yet have a Macintosh – that was part of the service.

The original assumption was that the software would “understand” the document formats of MacWrite, MacDraw, and MacPaint and be able to image and print documents just the way these programs did.  Soon the spec was amended to include MacProject, Lotus Jazz, and other new programs that were appearing for the Mac.  And the new version of MacWrite had a new document format.  It was pretty clear that our product, now named Desktop Express, would never be delivered because the spec would expand faster than we could program.

The second project that was worrying me was a report Mary was preparing for the United Way to illustrate why the Red Cross chapter she chaired should get a substantial allocation.  “Illustrate” was the operative word.  Mary had quickly become Mac-adept and had prepared graphics in a number of different programs that she wanted to put into the same report.  Cut and paste, in these early days, couldn’t handle complex graphics between programs; it got confused between the graphic and the underlying data.  It looked like she was literally going have to print all the stuff she wanted to use, cut it with a scissors, paste it up, and Xerox it.  Yuk.

But then one day, driving down Highway 101 (really), I’m thinking to myself how come, once we commit to paper, we no longer have to worry about which program created the particular page. That’s why we can do paste up.  And I realized that Macintosh products all “talked” to printer drivers in a language called QuickDraw which is all about graphics and nothing about the underlying data.  Eureka!  I almost crashed.

As soon as I got back to the office, I stripped down the source code from the sample printer driver Apple distributed to developers and had a way to “print” to disk.  Then I wrote a viewer that could display the pages from disk and print them.  Now Desktop Express could be finished because it was no longer dependant on understanding the data format of any particular programs.  And Mary could copy and paste from the viewer into MacWrite and create her persuasive report (this was pre PowerPoint).

The point is that the solution didn’t look anything like the problem as stated.  My customers said they wanted the product to understand the data formats of an expanding list of programs.  But that wasn’t really what they wanted; they really wanted to be independent of those formats.  They didn’t want a print-to-disk capability either; it was just the best way to solve the problem.  But they were smart and it wasn’t hard to renegotiate our contract.  Solutions retained the right to sell this capability as a standalone product and we bundled it with Desktop Express.

In case it sounds like I’m bloasting (boasting in a blog), I then proceeded to make five of the worst business decisions of my life.

1. I refused to give away the viewer to create a market for the print-to-disk capability even though Steve Case wanted to distribute it with the Mac-only predecessor to AOL.
2. I didn’t patent the technology.
3. I didn’t do a Windows version because I preferred to develop for the Mac.
4. I didn’t do a PostScript version.  Adobe did.
5. I didn’t raise money to promote it even though it was winning awards and was very well-known within the Mac community.  In fact, when a good friend set up a meeting with John Doerr at Kleiner Perkins, I told Dorr I was too busy to make a business plan.

Some of these mistakes may get a post of their own.