Young woman with tape on her mouth.

Requirements = “Shut up”

Agile and User Experience guru Jeff Patton claims that requirements in software development “harm collaboration, stunt innovation, and threaten the quality of our products.” (Jeff Patton  – Requirements Considered Harmful)

In person he’s more succinct: “the word ‘requirements’ means ‘shut up’.”

“What?”, you might think, “requirements can always be changed.

Not always. In my experience, requirements, especially when codified into something like a Product Requirements Document (PRD), can easily become sacrosanct. The document becomes the deliverable, and any thinking that deviates from the required features can encounter a negative bias. 

“But what’s so bad about listing what we should build?”  Initially I thought it was because software moves too fast but I don’t think that’s it.

Let’s look at an analog: the punch list. This is a list of items that a contractor needs to confirm have been completed in order to be paid.  It might include line items like “stove is connected to gas line”, electrical outlets are providing 110v…” etc.   

punch list table

A punch list works because there aren’t many variables or options when it comes to a stove being connected or not connected. It would not carry over to a project where the concept of having a stove at all was in play.

Let’s say you were designing a personal submarine. User needs are going to emerge as discovery proceeds:  Will people need to eat on the submarine? Will they want hot food?  Will the heat generated be a problem?  You might solve for all these issues only to discover that the people commissioning the submarine, your users, are raw-foodists.    

So it’s not that software moves too fast,  it’s that formal requirements tend to limit further inquiry, and in software development we are always discovering new things about users and how they work and what they want..

Consulting companies have a legacy of being documentation-heavy.  They need to produce “a thing” in order to reify their work, and to justify their fees. A satisfied client is their preferred outcome, not necessarily a satisfied customer.

Jeff  Patton uses his own contractor analogy when talking about outcomes:

“For Ed, my kitchen remodeler, me being a happy customer is his desired outcome. Ed isn’t responsible for the ROI of my kitchen. I am. The kitchen wasn’t built to satisfy thousands of users. And whether I really use it, all of it, isn’t Ed’s responsibility.“ (Jeff Patton  – Requirements Considered Harmful)

The ROI on software isn’t going to be realized until the initial consulting contract is a distant memory.  And building shippable software is an expensive way to do requirements testing.

Furthermore there is a morale cost to a team who discovers alternate ways to add value, or to overcome unexpected roadblocks:

Can’t get access to users to interview in a short time frame?

    • Value-driven: Pivot to use behavioral data from site metrics analysis.
    • Requirement-centered: Cobble together (make up) hypothetical personas so you can check the boxes.

Redesigning a site for a client team with a durable track record of zero innovation?

    • Value-driven: Uncover the gaping culture problem and address it.
    • Requirements-centered: Deliver better navigation categories.

It takes courage to structure a contract that says, in essence, “we will provide value in the way we discover value is best to be provided”.  Companies who do this, however, who are holistic yet move quickly, and who can re-organize in light of new information, will win over their more conservative competition.

Privacy Preference Center