This article originally appeared on MarketingProfs.com on August 3rd, 2004.


How to Guarantee Product Failure
by Roger L. Cauvin

Understanding and documenting market requirements are among the most important tasks that a product manager performs. Unfortunately, many product managers do not perform the tasks well, causing the following problems:

 - A development staff that doesn’t know what to build
 - Products that don’t solve real problems in the marketplace
 - Product designs that lack creativity and innovation

If you want your company’s products to fail for these reasons, there are a number of guidelines to keep in mind. These are the top five mistakes that product managers can make to ensure their products fail.

Mistake 1. Focus on the how instead of the what

To constrain your product designers and developers so that they cannot devise innovative solutions to prospective customers’ problems, specify the how instead of the what in requirements documents.

If you specify how to solve a problem, instead of what a product must do to solve a problem, then you’re doing design, not requirements.

For example, if your requirements document tells the developers of a software application what programming language they must use, you (a) constrain them in delivering the best solution in the least amount of time and (b) fail to describe the real requirement, the underlying reason that using a particular programming language might be advisable.

Mistake 2. Don’t ask ‘why?’

Say a prospective customer tells you that the software product it wants you to build must provide users a means of registering and logging into the system. An effective way to neglect important privacy and security requirements would be to accept this specification at face value.

But ask “why?” and you may discover precisely which problems the prospective customer is trying to avoid.

You may find, for example, that as long as you can keep outside intruders from accessing certain information using the system, the customer will be happy, whether or not you use registration and login. Or you may find that implementing the precise features that the customer requests will fail to solve the underlying problem.

Mistake 3. Write all requirements up front and freeze them

It would be nice if you could define all of the requirements for a product up front and freeze them. Actually, you can. However, doing so will virtually guarantee that the product will not satisfy customers.

Designing, implementing and testing a product inevitably reveals unanticipated problems. An iterative, agile approach incorporates this reality into the product development process by…

 - Limiting the time and effort initially spent on requirements
 - Designing and implementing part of the product and getting feedback from prospective customers
 - Revisiting the requirements to address problems and incorporate customer feedback

If you want to frustrate your customers, don’t employ this kind of agile development process.

Mistake 4. Forget to include nonfunctional requirements

The functional requirements of a product specify what it should do to solve or avoid prospective customer problems. Nonfunctional requirements specify attributes and constraints that the product should exhibit as it delivers the functional requirements.

If you want to create or ignore serious problems that your prospective customers face, omit nonfunctional requirements from your product’s requirements.

Say you’re documenting requirements for a word-processing product. Specify that the product should enable users to compose text documents (functional requirement), but don’t state how easy it should be for users to do so (nonfunctional requirement). An ease of use requirement might…

 - Specify a typical user’s prerequisite skills and experience
 - Place a limit on the number of user gestures (keystrokes, mouse clicks, etc.) it should take to accomplish a functional task
 - Place a limit on the amount of time that it will take a typical user to perform the functional task

These constraints provide a measurable way of ensuring that the product will be easy to use. Furthermore, they do not prevent product designers from applying their skills and creativity in satisfying them.

If you want to develop a product that frustrates users, avoid documenting these sorts of constraints.

Mistake 5. Include UI designs in the requirements

Including user interface designs in your requirements is a great way to jump into solution space and fail to gain a thorough understanding of the real pain your prospective customers are experiencing.

User interface designs are not requirements; they are possible solutions. By dictating one way of solving an underlying problem, you give no latitude to UI designers to employ their talent and creativity in composing the blueprints for a solution.

Imagine that you tell the user interface designers of a software application that “OK” buttons should be colored red and “Cancel” buttons should be colored blue. You have an important reason for this mandate: all of your key users are used to this color scheme and may press the wrong buttons if you deviate from it. Eureka—now you’re closer to the real requirement—avoiding the data loss or waste of time that might result from a different color scheme.

To overly constrain your UI designers, dictate the user interface details instead of stating the real requirements that drive them.


Roger L. Cauvin is founder and principal consultant of Cauvin, Inc. (www.cauvin.biz), based in Austin, Texas. Reach him at roger@cauvin.org.