We all do it. Even those of us, like myself, who should know better do it occasionally. But it is wrong. Or if "wrong" is too strong a word, then it is at least misguided.

What is it? It is the habit of stating a solution when we should be explaining the problem. This habit isn’t confined to a specific role; I’ve seen all members of the team do this … users, product managers, project managers, business analysts, technical architects, developers, user experience designers, testers, and management stakeholders.

Small Example

Here is a real example:

• A: I’ve noticed the requirement on the product backlog for multi-date news stories. What is that about?
• B: Yes, the news planners want to plan stories that span several days. The news story screen already has a "story date" field. It just needs a tick box indicating if the story is multi-date and if it is then there will be a "to date" to fill in.
• A: Are you sure?
• B: Absolutely, that is what the business needs.

Variations on this same conversation happened a few times with different participants in different meetings, but the requirement endured = tick box and to-date. So we built the software as described. It turned out to be quite tricky as the filters on our display views couldn’t cope with date ranges. But we got it working after a bit of work.

Unfortunately it wasn’t what the business needed. The requirement had been stated as a solution – a tick box and a to-date. That is what we built. In fact the real problem to be addressed was the speed of copying and updating the data on a running story, bearing in mind that yesterday’s data had to be kept for auditing/archiving reasons. From the outside it superficially looked like the same news story from day to day, but most everything could differ from one day to the next. The story slug (e.g. "Lbya") was constant but the angle, summary, correspondent, producer, other crew, etc could change. The real need became very clear in user acceptance testing – before live but a long way through our release pipeline. So we quickly put together a new solution which was basically a deep copy facility. The user could copy yesterday’s news story, update the details with new information, but be confident that the previous data was intact.

We would have saved some time, money, and stress if the real requirement, i.e. the problem, had been stated in the original conversation. My team is full of clever people and they would have made short work of the problem … if only they’d known what it was.

Strategic Example

The multi-day example above is small scale but I’ve seen the same problem at more strategic, and expensive, levels.

My current programme had a budget line for upgrading the search component. It is possible to spend hundreds of thousands of pounds on hardware and licenses for a search solution. It is also possible to spend virtually nothing. In fact our existing, and cheap option, gave us everything we needed from search and the team struggled to find a use case that needed anything more complicated. However, some of our external, and technical, stakeholders challenged us on not putting in the "strategic" search solution that had been in the budget.

The way I look at it just because an item in the original budget doesn’t seem like a good reason to spend that money. So the come back to the technical stakeholders was simple … "What is the business problem being solved here?". Several use cases were listed – speed of indexing, saved search – but we had already addressed these with our simple solution.

Final Thought

The way it should work is identify the problem (the requirement), solve the problem, and deliver the software. Jumping directly to the second step doesn’t work. So increasingly I find myself saying something like "That sounds like a solution; what is the problem?" I’d encourage you to ask the same thing when you hear a certain type of "requirement" being thrown around.

Ultimately people who state the solution rather than the problem are denying the team the chance to succeed. Or at least to succeed quickly.

Success is not delivering a feature; success is learning how to solve the customer’s problem

Mark Cook, VP of Products, Kodak Gallery (Reis, 2011, p. 66)

References

Reis, E. (2011). The Lean Startup: How constant innovation creates radically successful businesses. Penguin.