challenge

Challenge: stress-test the plan before you build it

A brief taken at face value builds exactly what was asked and discovers the wrong assumption after it's shipped. Before you commit, pressure-test the thinking and find the holes now, while they're cheap. This is in service of the work, disconfirmation, not negativity.

Run the plan through these:

• Framing. Is this the right problem? What is the request really trying to solve, and is building this the best way to solve that?
• Assumptions. List what the plan quietly assumes. Mark the load-bearing ones that haven't been tested, the ones that, if wrong, sink the whole thing.
• Unknowns. What don't you know that could change the answer? Name them as risks, don't gloss them.
• Scope that will change. What's likely to grow, shift, or get added after v1? Where will "just one more thing" land? Design the seams so that change is cheap, not a rebuild.
• The unasked need. What do the users and the business need that the brief doesn't mention? What will they want the moment they see v1? And the compliance, privacy, or legal angle nobody thought to raise, surface it before they do.

Then de-risk the worst one. Find the single riskiest assumption and the cheapest way to test it before you commit, a spike, a question to the client, a look at the real data. One cheap test beats a confident plan built on a guess.

The failure this prevents: building precisely what was asked, on assumptions nobody checked, and finding out only after it's built. The planning-time counterpart to brains-trust (which stress-tests built code); pair it with imagine (which expands the idea) before plan-and-build turns the result into a plan.