How is Agile like a frog in a pot of water?

April 29, 2011
Frog example

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…

  1. 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
  2. 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”.

Advertisements

The 7 Principles of Software Product Management

April 6, 2011
A stool with adjustable height.

Image via Wikipedia

As software product managers, we are constantly analyzing data:  needs from customers, revenue from sales, win/loss reports, development plans and costs, feature specifications, evaluations of competitors, etc.

As we process all of this information, an effective product manager should be guided by 7 key principles, divided into 2 key categories, as follows:

Product Planning

Effective software product planning requires you to balance the following 3 key principles:

  1. Customers — Your customers (or potential customers) represent the needs that your product should be fulfilling and the revenue that your company expects to receive by providing them with a suitable product (or service).
  2. Product (or Service) — This is the mechanism (or method) that your company uses to provide value to your customers.   If your product doesn’t fulfill most of their needs, then they will go elsewhere and buy something else.
  3. Product Team — This is the staff that your company employs (either directly or indirectly) to create and deliver your product (or service).  If your team doesn’t provide a suitable product, your customers will not be satisfied.  And if your team doesn’t know what your customers need, or understand how much your customers appreciate your products, then they will be unlikely (or perhaps, unable) to create a suitable product.

These three principles can be thought of as the 3 legs of a stool, with your company resting on the seat.  As a product manager, you must constantly balance these 3 elements.   If you over-emphasize (or under-emphasize) one of these principles, then your company will fail.   Just like a stool will fall over if one of its legs is overly long or short.

Product Creation

Creating a software product (or service) is an iterative process, whether you are using Waterfall, Agile, or some other development methodology.  In all cases, your product (or service) is provided to your customers in one or more releases.   As a product manager, you must balance 4 additional key principles for each of these releases, as follows:

  1. Content — Each release contains a certain amount of content.  A number of bugs that have been fixed, a number of new features that have been developed, and perhaps one or more changes to the infrastructure of your product.
  2. Resources — Each release is created (and tested) by a specified group of people; usually those who have the knowledge necessary to effectively and efficiently do the work.
  3. Schedule — Each release is delivered (or at least, planned to be delivered) according to a specific schedule, based upon the amount of work that needs to be done and the approximate date when the finished release needs to be completed.
  4. Quality — Each release must achieve a certain level of quality to ensure that it is suitable to used by the desired customers to accomplish its stated purpose.

As a product manager, you must also balance these 4 principles so that each release helps increase the value that your product provides to your customer.

However, in most situations you don’t have nearly as much flexibility.    Each product release must achieve a certain minimal level of quality, and while it is desirable to achieve a much greater quality, it is rare that this happens.   And although it may be tempting to increase the content you can complete within a given timeframe by adding resources — this rarely works — as explained in  The Mythical Man Month.

Thus, you typically have to manage trade-offs between the content that each release includes and the date (or schedule) when it will be available.

Conclusions

Product management is all about balance.   You need to  effectively (and consistently) balance the 4 principles that define the creation of each product release and also balance the 3 principles that govern your product planning.

If you do this well, your customers, company, product, and your team will all benefit — and you will be able to sleep well at night feeling good about yourself — which is always a good thing.


%d bloggers like this: