Why “Requirements” Are Bad
Ditch requirements in favor of assumptions for better product outcomes
Have you ever considered that “requirements” are bad? I am not talking about poorly written, or bad requirements, but rather the concept of requirements altogether.
Back in the day, I used to write requirements documents — business requirements and functional requirements. The process took months to write and get approval before any code was written. Folks felt like they knew what they wanted at some level, but at the detailed level required to produce these commitments, there was less confidence. Never-the-less, they were still “requirements.”
The deployed product often missed the mark on what was really needed. I find that users don’t know what they want or need until they see it and have something to work with. A lot of work was done to find out the requirements weren’t really required after all. The move to Agile ways of working would solve that problem, right?
Today, requirements documents have been replaced with user stories. Most teams I’ve encountered still refer to user stories as requirements. I hear terms like “business requirements” and “product requirements.” Despite less effort, scope, and timeline, working from requirements still leads to the wrong product.
