Test the assumption before you build on it.

Most wasted development spend does not come from bad code. It comes from building something well that nobody needed, or building the right thing in a shape people cannot use. Both are visible before development starts, and both get expensive the moment they are not.

The practical version is unglamorous. Write down what you are assuming about your customers. Rank those assumptions by how much you are betting on each one against how confident you actually are. Test the top two or three with real people, using a prototype rather than a description, before anyone commits a sprint to it.

We do this most often as a round of usability testing on a prototype ahead of development, or a short discovery study when the problem itself is still fuzzy. Both are small. Both routinely surface issues that would otherwise only appear after launch, when fixing them costs a release cycle instead of an afternoon.

We would not claim research guarantees you build the right thing. It shortens the odds, and it makes the bet explicit.