Image via Wikipedia
Remember the old tale about the frog and a pot of water? In essence, if you put a frog into a pot of very hot water, it will immediately jump out. However, if you put a frog into a pot of cold water and gradually heat it, the frog will allow itself to be cooked to death.
Not to worry — I have never done either of these and I don’t suggest that you do so either.
However, there are lessons from this tale that I believe apply to the Agile development methodology…
I believe that a “successful product” must provide a valuable resolution to one or more needs from your target market. Otherwise, nobody will buy it. So when I talk to other Agile practitioners, I am amazed at how little thought they give to getting accurate and reliable feedback from their market. Many of them make one (or both) of the following mistakes:
Product Owners Focused Solely on Development
The product owners of some companies spend so much time with Development that they quickly lose touch with their market. Or even worse, allow the product direction to be set by the 1 or 2 customers that they have time to talk to. Sure, they could talk to a number of customers via email, Skype, Twitter, etc — but you will only get answers to questions that you ask or reactions to significant positive (or negative) aspects of your products. You may never know that some function takes twice as many clicks to complete as it should or that users are constantly using other tools to compensate for functional gaps in your product.
To know what your customers really “need”, you have to talk to enough of them so that you understand the difference between what a few customers say they want and what your product needs to provide to satisfy your target market.
Note: If you’re interested in how to do this, consider this article written by Steve Johnson, Luke Hohmann and Rich Mironov published by Pragmatic Marketing,
Developers Gone Native
Some companies encourage Developers to engage with customers so that they can get first-hand knowledge of what the customers need. They carefully select the Developers for this task, because some are simply better suited for this type of interaction than others.
However, there are at least 2 problems with this approach…
- The Developers can’t spend a lot of time talking to customers — because they are typically senior people who need to be contributing to the product, and
- The Developers usually do not have the skills / experience to identify what each customer really “needs” (as opposed to what they say they want) and to synthesize the requirements for the product’s target market from feedback from only a few customers.
As a result, the Developers often focus on providing the capabilities that the customers they have met say they need — almost as if they were working directly (or “natively”) for those customers — instead of providing capabilities that benefit the majority of the product’s target market.
The Frog and the Water
If done right, Agile allows you to get rapid feedback from your market to keep you on course toward creating a successful product. But your product can “go off the rails” just as easily with Agile if you don’t understand how to obtain and utilize customer feedback.
Waterfall is like the pot of hot water — it provides dramatic evidence of how well (or poorly) your product matches the needs of the market.
Agile is like the pot of cold water — and each iteration increases the temperature of the water in the pot a bit. So if you do not have good people who are experienced in obtaining and understanding market feedback — you could, like the frog, sit in your pot until it is too late.
What Should You Do?
I believe that each product development team should consist of people who are highly qualified to do their specific jobs. I look for teams where well-trained engineers are developing a product that is being tested by experienced QA personnel. I’m not fond of teams where “everyone does everything” — because not everyone can be an expert at everything.
Likewise, your development team should include someone who understands the “art” of obtaining feedback from current (and potential) customers and synthesizing that into prioritized product requirements. Whether you call this person a “product owner”, “product manager” or something else is up to you. But they need to spend time at least 25% of their time with your current (and potential) customers. Otherwise, they will quickly lose touch with what your target market needs and will have to rely on their own opinions, guesses, and/or hopes.
Creating a software product is very expensive and you can’t afford to make very many mistakes, because in many cases your competition is only “one click away” for a current (or potential) customer. So avoid the temptation to ask developers to do this job “in their spare time” and get yourself a good product manager who can do this job “full time”.
Posted by David Fulton 
