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 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.

You have just saved me! I am at that very point in the concepting phase and my engineering colleagues and indeed our implementation of the project phase gate process (interestingly written by an engineer) are pushing me for more and more detail…..already! In a former PM role, I started just as the article ‘advises’ with a single sheet of paper and we went on journey together through feasibility into implementation. It was very scary and engineering inevitable kicked back at the lack of detail – this was a defence supplier and used to sepcifications ,literally 30 inches thick. We got their in the end witha product that was both commercially and technically succesful as witnessed by three patents and a two Queens Awards for Export and Innovation. We found that a well managed technical & commercial risk register was a way to get our mutual concerns onto the table which helped avoid any blame. I have a copy of 42 Rules, so you’ve inspired me to re-read it this weekend!

Thank you for sharing this lesson learned. I was lucky to have observed this as a system’s analyst on a rather large project involving lots of characters. It can happen.. and very much as you portrayed it. The Product Owner really must set the tone and set expectations of functionality while allowing the programming team the freedom to interpret. I think that is why I love Agile development so much. The ability to tell user stories, develop in smaller sprints, do a Sprint 0 for the UX, or just to a “Spike” that proves out a prototypical concept that is an Industry first. The ACPM course I took from 280Group is excellent at helping you develop strategies for addressing this issue and many other. We can all use help bridging the “What” to “How” bridge for ensuring our products delight customers and are on schedule.