Stop talking about requirements

Zorik D

Please stop talking about software requirements. Requirements analysis relies on customers who can articulate their needs, and understand and commit to a corresponding requirements specification. These customers sound great but, like Santa Claus, I’ve never seen them and no longer believe they really exist.

In product management, the very notion of a requirement sounds like a category error. Constraints, which you share with your competitors, come closest: security, and not breaking the law, for example.

Requirements mindset

From a product management perspective, stakeholders have problems and wishes, not requirements. If you set out to discover all of their so-called requirements, you will end up with an infinite backlog that you cannot ever complete. Don’t try to boil the ocean.

Requirements only exist in the context of a project-based business model that works badly for most kinds of software development. But in software product development, you won’t ever reach a point where you have implemented all of the requirements. It doesn’t work like that.

Vestigial waterfall

The word requirement indicates vestigial waterfall software development: the idea that development teams build software that someone else has somehow defined in advance. Even if you don’t work that way yourself, you may find yourself working with people who did in the past, especially on fixed-price software development projects that extract profit from the client’s own attempt to avoid previous project failure.

Words matter, and apparently outlast business models. Holding on to the language of requirements, because we don’t know what to call our units of work, holds us back. It holds product management back.

Requirements documents

As well as talking about requirements, we write about them. The requirements document and product requirements specification belong to the past, but product managers still make the PRD mistake that encapsulates and perpetuates requirements thinking.

Good writing offers another clue: avoiding passive voice. You can recognise passive constructions like:

the software was designed

when you can add by zombies, because the phrase doesn’t identify another actor:

the software was designed by zombies 🧟

Similarly, you can also fix requirements written with the usual MoSCoW method phrasing:

the software MUST do X

which might as well read:

🧟 zombies think the software MUST do X

Requirements share passive constructions’ fake objectivity in how they obscure who requires particular product characteristics. As a product manager, state your audience.

Objectives > requirements

Objectives and key results (OKRs) offer a popular alternative to requirements thinking. Instead of attempting to specify a software product by stating which requirements the ‘finished’ product must satisfy, OKRs focus on outcomes.

I recommend three different books that introduce OKRs, each taking a different perspective:

1. Succeeding with OKRs in Agile - agile software development focus
2. Radical Focus - start-up focus
3. Who Does What By How Much? - broad adoption

Organisations get different things out of OKRs, but everyone can take advantage of a new vocabulary. Instead of requirements, talk about objectives, results and outcomes. And most importantly, as a product manager, refer to your discovery work with customers. You wouldn’t want anyone to think you take instructions from Zombies.