User>Driven

Check out this post from John Nack, Senior Product Manager for Adobe Photoshop. He argues persuasively that you shouldn't (just) listen to what your customers say they want but figure out what they really need.

He also attributes the faster horse story I related a while back to Henry Ford. Google seems to agree with him on the source of that meme.

Thanks, John.

Last week I was visiting with a customer, an online seller of branded sports apparel. Someone in the meeting noted that when speaking of the competition she completely ignored other brands, focusing on the other channels selling her product.

We asked why and and she said "The gap between [her brand] and its potential is far greater than the gap between [her brand] and it's competitors." I thought that so well encapsulated my feelings about dealing with the competition that I would share it here.

Competitive analysis is a standard product management task and necessary sometimes. Sales people and prospects ask for feature comparisons. And when your product is closely comparable to another or when you are the discount brand, checklists can be useful for positioning. In my experience, though, much greater market success comes form staking out your own territory.

Think about it this way: would you rather have a conversation with a prospect about whether your feature list is longer than the competition's or about the benefits the prospect will derive from your product? Which of those conversations would allow you to charge more? If you're concentrating on market needs rather than competitive checklists, you have a chance at that second, more profitable conversation.

Similarly, would you rather spend your development efforts on duplicating the competition's every feature so you can say "yes" when asked if you have it, or would you rather concentrate on building the features that will solve your customers' problems? I'd much rather be thought of as great than as just better than someone else.

Building value that responds to market need puts you in partnership with your customers. They come to you to solve their problems. Getting into a checklist war with your competitors just invites your customer to look at you and the competition in the same way - to hold you both arm's length.

So don't be better than the competition. Be great.

The consulting firm Booz Allen Hamilton does a study of innovation each year at the largest corporations in the world hoping to describe what works and what doesn't. In their 2006 study I think they tried a little too hard to add value by breaking the successful strategies they observed into different categories. All of them really came down to intelligently listening to your market, but they nonetheless presented some good principles and at least one good story of corporate User>Driven behavior.

One key principle they uncovered was that it was more important what process you use to develop products and services than how much you spend on it. "As in years past," they said "we found no statistically significant connection between the amount of money a company spent on innovation and its financial performance." What they found instead was getting close to customers was the key thing.

"It's engineers and marketing product managers spending hours and hours on job sites talking to the guys who are trying to make their living with these tools," said John Schiech, President of the DeWalt division of Black & Decker, one of the subjects of the study.

DeWalt has grown from $150 million to over $2 billion in sales of their power tools since 1991 by listening closely to current customers. In field studies, for example, they observed that builders couldn't cut large crown mouldings in one pass using traditional 10" miter saws. They brought the first commercial 12" miter saw to market, priced it a premium, and quickly found themselves with a best-seller.

Plantronics also practices market listening through focus groups and shadowing of both their corporate and consumer telephone headset customers. BAH had no specific tales of successful innovation at Plantronics, but described their process of applying "strategic filters" to help choose which products to bring to market. Those filters are all related to the expected financial performance of the products over the next 1-3 years.

The largest of these companies, Siemans AG, uses these same market listening techniques in their individual divisions but adds a greater layer of oversight, allowing them to pick and choose where to invest based on heir perception of longer term market trends such as the movement to personalized medical care, the need for portability, urbanization and other changes in demographics.

BAH tries to cast these companies in different roles, saying they are driven by customer needs, market needs and technical innovation, respectively. I don't see that in these examples. I think each company is actively researching and responding to market needs and the differences are really just in the time-horizon each is planning for. It should be no surprise that the larger companies are looking farther out.

In the Siemans study, BAH does quote one executive saying "You've got to be somewhat skeptical of what they [customers] see as the technical solution, and instead depend on your own core set of people who can creatively link new technology to the future market." BAH seems to think this is unique to Siemans and other technical innovators thinking long-term. This is no different than what DeWalt did with the miter saw, though. DeWalt's customers didn't ask for a bigger saw, DeWalt observed the current practice of cutting each piece of molding twice and came up with a solution that saved their customers' time. It may have been a more obvious extension of a current product, but the process of innovation in that case, like the others, was driven by observing unmet needs in the market.

This study just reinforced for me a few key principles of good product design:

• Pick your target market, both in terms of whom you are targeting and when you plan to bring the product to market
  
• Determine the needs of that market, ideally by studying first-hand the problems they face or that you believe they will face in your target time-frame
• Design your product to solve those problems in a way that can be brought to market affordably and profitably

Barb Nelsen at Pragmatic Marketing writes on the politics of agile, outlining the frustrations many product managers feel when their development organization begins adopting agile methods.

While developers sprint through development cycles, one of three things happens to product managers. 1) They are ignored. 2) They are dragged deep into the development cycle. 3) They lead the team to build products people want to buy. The first two situations are lethal to a product manager’s career. The third alternative can lead to successful products and successful careers.

She says that "the problem seems to be that everyone is trying to wrestle control from the other" but I think the destabilizing effects of a move to agile on an organization just reveal long-standing tensions between developers who want certainty about what they are supposed to build and product managers who want flexibility to respond to changing market conditions.

In the end, she says that agile doesn't really change the product manager's role. They still need to "lead the team to build products people want to buy."

A key concept is that the product manager must become the market expert and the single voice of priority on the team. Rather than just reacting to the list of requirements submitted by everyone (customers, sales, support, development, executives), the market-driven product manager visits a representative set of people in the market (including non-customers) on an ongoing basis. He keeps the team focused on the targeted market segments, buyer and user personas, and problems worth solving. He conducts surveys periodically to quantify the inputs and a keeps a prioritized list of open problems to solve.

Go Barb!

We've been exploring Agile methods where I work at ATG. A number of us attended a seminar given by Ken Schwaber on Scrum methods for product development and it stirred up some interest.

I've been doing a bunch of reading about agile methods, especially on how it affects the product owner (read: product manager) and requirements. Predictably, Steve Johnson at Pragmatic Marketing has a good summary of Agile requirements. It takes a little time to get past his trademark warnings against "ReqSpecs" (requirements that have too much implementation in them) and the need to say no to feature-creep, but the wait is worth it for his insights on the true motivations behind Agile.

If you can't wait, though, here are four paragraphs I think are key: 

Agile is often an attempt to manage our executives rather than to be more responsive to the market. The executives keep changing their minds, adding new feature requests, flip-flopping on issues. The agile approach of development is a technique in forcing executives to choose.

Management mandates rigor and precision before the scope of the work is truly understood. “How long would it take you to build it?” “Well, that depends on what it is, doesn't it?” “Yes, but give me a date anyway.” Management over-commits Development all the time.

As product managers, we should support the ideals of agile development. We want some process, but not too much process. Small iterations give us more flexibility to adapt to change. Team collaboration means less time is spent documenting, leaving more time for doing.

The key to any agile team is building products that people want to buy. To do that, an agile team needs a messenger for the market, a product manager who thoroughly understands the problems facing today’s customers. In agile programming—and frankly in any programming model—the effective product manager serves as representative of a market of customers.

Thanks, Steve!