Skip to content

step 1 / 32 · 5 min

The feature that took six weeks and nobody used

A team is asked for "a dashboard for the sales data". Six weeks later they demonstrate twelve charts, filters, a date picker and an export button.

The person who asked watches politely and then says: "I only wanted to know which shops are below target this month."

Nothing was built badly. The charts work, the filters work, the export works. The team built the wrong thing, carefully, for six weeks.

Where it went wrong

The request was a solution ("a dashboard"), and nobody asked what problem it solved. One question would have done it: what will you do with this once you have it?

That answer is "phone the shops that are behind", which is not twelve charts. It is one list, sorted, with a phone number next to each row. Two days.

What good requirements look like

A useful ticket answers three things, and you can ask for them politely without sounding difficult:

QuestionWhy it matters
Who is this for?Decides the language, the detail, the device
What will they do with it?Separates the list from the dashboard
How will we know it worked?Gives you a way to stop

The third is the one people skip. Without it there is no definition of done, so the work expands until somebody runs out of patience.

Iterations exist for this

Two weeks of work, shown to a real person, then adjusted. Not because two weeks is a magic number, but because it bounds how wrong you can be before somebody notices.

A six-month plan is not more organised than six two-week iterations. It is the same work with the feedback removed.