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.

Comments

[May Sui]

Hi! Somewhere in my garage, I still have the brown Glue pot that came with my copy of Glue to review for Publish! Every time I use Acrobat, I think of Glue and that glue pot and wonder what happened to Tom and Mary (and now I know).

[Pieter Hartsook]

I remember you prototyping a PC version when I was working as the strategic alliances guy at TOPS. It actually allowed easy exchange of formatted documents between Macs and PCs over the network. A great idea! If I remember correctly, the working project name was TOPS TV.

[Dave Ely]

Interesting story, I always wondered what had happened to Glue. The tie in with AppleLink Personal Edition (ALpe if I remember correctly) would have helped considerably.

Didn't Apple also use Glue quite a bit on AppleLink (the professional version run by GEISCO)?

[Jim MacLennan]

My last blog post talks about this a bit - how many Users come to IT with a solution ("please make this program do _this_") - which innvolves customization of standard product.

Better approach would be to understand what they _need_ ("please prevent the shop floor from seeing _this_ piece of information"), and find out if that functionality is available elsewhere in the system (but they just don't know about it yet).

http://www.cazh1.com/blogger/thoughts/2005/04/if-you-want-to-be-more-than-programmer.shtml

[Brady Joslin]

Very interesting, I see your point. This is actually related to the Human Action Cycle in by Donald Norman.

On one side we have the Stages of Execution:

Goal -> Intention to Act -> Sequence of Actions -> Execution of the Action Sequence –- The World

On the other we have the Stages of Evaluation:

The World -- Perceiving the State of the World -> Interpreting the Perception -> Evaluation of Interpretation -> Goal

The user’s ability to communicate their goal often gets jumbled with the actions typically performed. Similarly, their ability to communicate their problems often gets jumbled with the feedback they received after performing the actions. They are mentally stuck in the constraints of the current cyle. The problem solver must ignore the current cycle and focus specifically on the goal at hand.

Once the goal is understood, there are a couple of ways to approach the issue.

1) Can we enhance the actions taken and feedback received to help them reach their goal?

This is perhaps best described as operational improvements. We say, "Do it this way."

2) Can we change their world, through the development of software, tools, etc., to help them reach their goal?

This is the fun part for most of us – innovation. We say, "Don't use that any more - use this new thing instead and do it this new way."