Beware the Requirements Death Spiral

A pattern I've observed in multiple companies over the years is product managers defining features and the corresponding implementation in excruciating detail in their requirements documentation. When I see this, I know the company went into the "requirements death spiral." The story of each company is always remarkably similar.

It starts off simply enough and with the best intentions: A product manager provides some high level requirements to their development team and asks for an estimate to do the work. When the estimate is longer than the time available, the product manager asks the team if they could try to make it happen by the deadline and assures them that the product is really very straightforward and there are no hidden surprises. Because the team wants to be accommodating, it agrees.

As the development progresses, new requirements are added as more is learned, but the team is told the release date cannot move, sections of the requirements are misunderstood, the resultant solution does not match the product manager's or customer's expectations, rework is needed, and the schedule inevitably slips. Feeling powerless, the product manager points the finger at engineering for missing the date and getting the product wrong. Being blamed after having worked overtime and with heroic efforts, engineering points the finger right back at the product manager for not being clear on what he wanted and frequently changing his mind.

For the next release, the product manager—a little wiser now—asks the development lead to sign off on the requirements. This way the engineering team will somehow think it is legally bound to the terms of the requirements document. Product management also presses the engineering team to ensure the delivery date will be met. Having been burned once—and also a little wiser—the engineering manager starts to pad the dates and says that he cannot commit to anything sooner without more detailed requirements. This, of course, does not fix the problem.

Thus, the spiral begins. With each subsequent release, the product manager demands ever more detailed time estimates from development. Development, in turn, demands ever more detailed requirements from the product manager. Without even realizing it, the product manager begins to specify the solution (rather than needs) and the development team, not wanting to be blamed for any mishaps, starts to build exactly what is written without ever questioning it. Worst of all, the customer is disappointed and the product meets with only limited success in the marketplace.

The destructive feedback loop that sets up the requirements death spiral is a fascinating phenomenon because both sides want to create a winning product and start with the best of intentions. Further, both sides are behaving completely rationally within the scope of their area (i.e., product management or engineering). Only when viewed from the perspective of delivering value to the customer and creating value for the company are product management's and engineering's actions so clearly counterproductive.

It is product management's responsibility to identify customer problems worth solving. It is engineering's role to identify technical solutions to those problems. Together both sides must collaborate to create the optimal design that will solve the problem for the customer and delight them in its use.

Ultimately, the product manager is accountable for the product's success. Product managers, therefore, must be vigilant to avoid entering the death spiral. The easiest way to do this is to focus on the problem space and encourage engineering to apply their creative energies to the solution space. Product management and engineering are on the same team and share the same objective of creating value for the customer. The product manager's actions must reflect this truth.

© 2013 Laura Lowell