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.

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.

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

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.

Many of the problems we are grappling with seem to stem from trying to plan an Agile effort within a more traditional development organization. At my company, for example, projects can last for many months and doc and QA usually join a project already in progress and stay with a project after feature work is done. And unlike most developers, doc and QA folks (especially doc) are often split among several projects at once. So while some team members are ready to start daily scrums, it has been hard to include these disciplines. Our first pilot began scrumming with only the developers and a program manager turned scrum master. The doc person has since joined but is still splitting her time between two projects.

There is a general feeling of wanting to do Scrum "right" with this next pilot, so we've decided to wait until doc and QA can at least be part of the project kickoff where the team is supposed to review requirements and decide which features they can take on in the first sprint. Even then, commitments to other projects will mean the first few sprints in that project will have to consist of tasks not requiring doc or QA, things like tech spec writing and UI design.

At first I was uncertain about this approach. I thought one of the key principles of Scrum was that all disciplines were represented and that features were supposed to be really "done" at the end of a sprint - done as in shippable - which would, of course, require they be tested and documented. Some smart folks at Cyrus Innovation told us, though, that at least in their approach to Agile, it was more about commitments and checking progress on a regular basis than about "completing" features in each sprint.

What you put on your product backlog (the prioritized list of work for the team) doesn't have to be limited to features. The list can include anything the team needs to accomplish to meet the goals of the product. And that can begin with designs and specs. It can also begin with only part of the team represented, it seems, though we do plan to fold all disciplines in as soon as we can.

I'm still not sure how I feel about this, but it seems in resolving the tension between two principles, one sometimes has to take precendence over the other. I will revisit this issue as we move forward with the project and let you all know how we do. 

Next time I will try to talk about scheduling sprints and releases for an Agile project in a traditional organization. 

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!

In this post, I thought I'd outline our current understanding of Scrum. Briefly, Scrum is an Agile software development methodology designed to produce higher-quality output that is more responsive to market needs. it is focused on constantly delivering value rather than on meeting a specific date with a pre-determined set of features. It is characterised by:

• Work periods called "sprints," usually of 2-4 weeks, wherein the team attempts to complete some segment of work such as a short list of product features.
• An agreed-upon definition of completeness for the work, such as that it is functional, tested, documented and otherwise "done" enough that it could be shipped to the customer as is if required. Usually this requires a demo of the work at a meeting called the "sprint review" at the end of the sprint.
  
• A list of features and other work to be done called the "product backlog," maintained and prioritized by the "product owner" (the representative of the customer, usually a product manager) and updatable between sprints.
• "Just in time requirements" that are specific and detailed for what is being worked on in the current sprint but less well-defined for work that is further down the road.
• An agreement among the team members on what features will be attempted for a given sprint, and joint responsibility for delivery of that fixed list of features.
  
• Daily quick meetings run by the "scrum master" to review what's been done in the last 24 hours and what each team member intends to do in the next (called "stand-up meetings" because they are supposed to be held standing up to motivate people to finish quickly), designed to uncover issues that need immediate resolution among team members.

The team is independent during a sprint, dividing up and and completing work as they see fit, but they must demonstrate the results of their work to the product owner at the end of every sprint. Despite the autonomy of the sprint, this increases transparency and accountability. Flexibility is also enhanced by allowing the product owner to continuously adjust the priorities of the features on the backlog for the following and later sprints in response to changing market conditions and knowledge.

There is a lot more to it, but I suggest people view Ken Schwaber's video or read some of the other great material available on the web about Scrum rather than me summarizing it all here. In my next post, I will try to summarize some of the early concerns and issues raised by folks at ATG as we talk through piloting Scrum on a project or two.

I usually get a kick out of the tech comic Geek And Poke. I thought this one and this other one were particularly apropos. 

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!