User>Driven

Bob Corrigan at ack/nak (a funny blog that's sometimes about product management) tells a great story about a Japanese concept called omakase. Read it. It's quick.

The story is about the implicit trust that develops between people when they know each other and each other's needs very well. He compares it to the level of trust he would like to achieve as a product manager with his customers.

I think it takes time and deep experience with a particular customer base to develop. I think I probably only got there once as a PM - after 5 or 6 years at the same company and only with a handful of customers.

This may be a less lofty ideal, but I think the story illustrates how you can't be a really good PM for a product until you know its customers well enough to effectively guess how they will react to a proposed new feature without asking them first.

Mark Asdoorian, a friend and colleague for many years, sent me this amusing link about medieval monks getting used to the new-fangled printed book with these comments: "Great bit about how adopting a new UI can always be confusing to some users.  Gotta have quick eyes to read the translation."

At the annual sales meeting for ATG this year, the SVP of Marketing, Cliff Conneighton, told what I think is a good story about product innovation. He said that if you'd asked someone in the 18th century what the perfect mode of transportation would be, they'd describe a faster horse that can run all day, carry a heavy load, and not need much food or water. They would not describe a car or a train or an airplane because, Cliff said, no one had yet laid out a vision for these modes of transportation.

What cliff is getting at is a couple of fundamental truths about product innovation. The first is that most customers have little or no imagination. They can imagine incremental improvements to what they have (a faster horse), but they can't usually imagine something entirely different that solves their problems in a different way, even though it would be orders of magnitude better (an airplane).

The second is that, because of the first, there are situations in which you can't actually go out and ask your customers what they want. You can't ask them to design a revolutionary new product for you because they don't know what technology can do for them if it's something they haven't seen before.

Here's another example. I described in an earlier post a story that Patricia Seybold told about how Staples reorganized their site based on the organizational schemes submitted by real users. The results were so good that they rolled them out in their bricks-and-mortar stores as well. So Staples asked their customers how to improve the product and it worked. Staples was not asking the customer to innovate, however. What was innovative was Staples providing a means for the customers to give that feedback in a systematic way (through software, natch). While some customers may have dropped organizational suggestions in a suggestion box somewhere, it took someone with imagination at Staples to push the concept to its logical end and devise software to gather the feedback.

As I've said before, the task in being User>Driven is not to ask customers what they want but to ask them what they are trying to accomplish and what obstacles they face in meeting those goals. A good product manager and engineer can then put their heads together and devise a solution to those problems based on their knowledge both of the problems and of technology. This is where the vision comes from.

Links

Patty Seybold:

My post on Staples: http://userdriven.squarespace.com/blog/2006/5/14/eating-my-own-dog-food.html