Lean UX, 3rd Edition

Chapter 4. The Lean UX Canvas

Assumptions Are the New Requirements

If you work in an industry where things are relatively predictable, where there is low risk and high certainty in what the company is making, what it takes to make your product, what it looks like when it’s done, and what your customers will do with it once they have it, you can comfortably work with a set of rigid, predetermined requirements. In a world with this manufacturing-era mentality, big design up front is the norm, and any variability in the production of your product is seen not as an agile response to a changing marketplace but rather as an expensive deviation from the plan. This way of thinking about requirements was adopted in the early days of the software industry, was the dominant model for decades, and continues to permeate many teams’ ways of working even to this day.

Requirements assume we know exactly what we need to build. Ideally, they come from engineering rigor. But in software, they usually don’t have the rigor behind them. Still, they are taken at face value based on their author’s credibility or organizational title. In many cases, that blind faith is augmented with the phrase “well, it worked before.” Individuals or teams who question the absoluteness of the requirements they’ve received are perceived as troublemakers and treated as scapegoats when projects end up missing deadlines, exceeding scope, or both. In organizations still leaning heavily on them as a way to tell teams what ...