Why Most Clients Don't Need More Features — They Need Clarity

A common project kickoff looks like this: a client arrives with a 40-page spec document, a list of 80 features, and a deadline that assumes the work is already done. There is absolute certainty about what should be built — and, often, a wide gap between that vision and what is actually needed.

The specification trap

When a detailed spec is written before anyone technical is involved, it usually solves a problem that has been imagined rather than the one that actually exists. The solution is built in someone’s head based on a limited understanding of what’s technically possible. The spec becomes an answer to a question that hasn’t been properly asked yet.

"A good brief describes the problem. A bad brief describes the solution."

A better way to brief projects

Before any project starts, it is far more useful to walk through the problem from the user's perspective. Not 'we need a dashboard with X, Y, Z widgets' — but 'our users currently do this manually, it takes 3 hours, and they hate it.' That description of pain is worth more than any feature list.

From there, the work moves backwards from the outcome. What is the minimum change to the user's experience that would make that pain go away? That becomes the feature. Everything else is optional.

Clarity compounds

Projects that deliver the most value almost always invest more time in defining the problem than in designing the solution. A week of clarity work at the start can save months of rework later, and the same mindset often carries over into other parts of the business — not just software.

• Start with the user's pain, not your solution
• Question every feature: what problem does this solve?
• If you can't describe the problem in two sentences, you don't understand it yet
• Build the simplest thing that could work, then improve