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

A colleague at work sent this send up of Scrum and other development methodologies of the moment. I couldn't resist sharing.

Recently I've been writing about issues arising as we explore Agile principles within the more traditional scheduling environment of ATG. As we talk about how to schedule sprints in a Scrum pilot project, we've been debating key principles and how they might apply to our projects. The latest is sprint length. Should the length of your sprint be fixed or should it flex in response to the size of the tasks in it?

It's second nature to the experienced program managers I work with to break projects into milestones, so the idea of breaking a project into sprints seems easy to adopt. According to what we've read, sprints are supposed to be a short (2-4 week) cycle of work kicked off when the team agrees on a list of tasks to be attempted and finished off with a review (usually a demo) of what's been completed.

We've been used to determining the milestone schedule according to the size of the tasks on our list, though. A related set of large, complex tasks should require a longer time frame than a single simpler task, right? Makes sense. Scrum says you ought to be able to break any task down into component tasks that would fit into a sprint, but why force different size tasks into an arbitrary schedule? Why try to demo something that's only half done? Is there any reason we couldn't have a sprint of 2 weeks followed by one of 4 and then one of 8 for a really big task?

I've heard a few reasons that sound credible and that we plan to test.

1. Accountability - Have you ever seen a feature stay at 90% complete for weeks with no apparent progress? Have you ever seen developers procrastinate on work with a long deadline? Rapid-fire deadlines force people to get things done efficiently for fear of looking bad at the demo.
   
2. Course corrections - There's always some gap between what product manager asks for and what the engineers deliver. Frequent reviews minimize that gap by bringing the two parties together regularly even when features aren't done. It's easier to make changes before the feature is done, tested and documented. And without the discipline of regular check-ins it would be easy to wait until back-tracking feels like more work than it's worth.
   
3. Rhythm - I've heard people experienced in Scrum say that a regular schedule puts them into a productive rhythm. It's like exercise, I gather - once you get to doing it regularly you begin to expect it. It's self-reinforcing. Developers look forward to the sprint reviews and to kicking off the next round.
   
4. Attaboys - Steve Johnson from Pragmatic Marketing mentioned this effect when he spoke at the BPMA recently. He likened it to the increased desire of a husband to tackle items on the "honey-do" list when he gets praise from his wife for doing them. The regular demos provide an opportunity not just for feedback on direction but for positive feedback. "Cool!" the product owner will say when they see something working (even partially), and cool the developer will feel hearing that. Will developers respond to that kind of thing. Are developers human? It's in our nature.

It's still under discussion but I'll push for fixed-length sprints, the shorter the better. It seems to me the chief value in Scrum is the visibility that frequent check-ins afford, facilitating accountability, course corrections, rhythm and morale-boosting attaboys. I'll let you all know how it goes as we dig in.

Next time I will try to write a bit about coordinating sprints and releases for an Agile project with the longer release cycle of an underlying platform.