State the result before the feature.
What it really is
On the surface, Defining the outcome to aim for can look like a single technique you either know or you don't. The real skill underneath is starting from the user's real problem and turning it into something worth building — and that's the part that actually transfers from one situation to the next. Here it shows up as a concrete, repeatable habit: state the result before the feature.
Why it matters
Building the right thing beats building the thing right. A Delta finds the problem worth solving before writing the code.
What good looks like
- You separate the literal request from the underlying job.
- You can name who the user is and what they're really trying to do.
- You prioritize by impact, not by what's easy.
Common trap
Taking the feature request at face value and skipping the "why."
How to practice
The rep: State the result before the feature.
Do it on a real problem, not a hypothetical — under the kind of pressure where it's tempting to skip. Land it and you earn the Outcome Driven badge. Repeat it until it stops feeling like a technique and starts feeling like instinct.