When the deliverable replaces the problem

A deliverable is often easier to name than a problem.

So I begin by understanding:
• What is the client trying to change?
• Who are they trying to change it for? And why?
• What would a win actually look like?

Sometimes the original request is right.

Sometimes discovery points somewhere else:
• A clearer story.
• A better way to explain what they are building.
• A clearer understanding of why the audience is not connecting.

The important thing is that the deliverable comes out of the problem.

It should not quietly replace it.