In my last post, I explored how Simon Sinek’s Golden Circle and James Clear’s three layers of behavior change unexpectedly mapped onto each other, and how both connect to Behavior-Driven Development.
That piece was more conceptual. This one is more concrete.
Around the same time I was connecting those dots, I was also sketching how the Golden Circle maps directly to the user story format. Not as a metaphor, but as a structural overlay.
The Story Format as a Golden Circle
The story format I’ve been using for years looks like this:
“In order to [value], as a [persona], I want to [action].”
And underneath it: the Given/When/Then scenarios.
When I laid that out against the Golden Circle, the alignment was clear.
-
Why = “In order to…”: the business value, the purpose, the reason this feature should exist at all
-
How = “I want to…”: the approach, the solution path the team proposes
-
What = “Given… When… Then…”: the specific behaviors, the scenarios, the concrete things that must happen
The Why is the center. The How is how you get there. The What is how you confirm you’ve arrived.
Note: I’m not neglecting the Who (“As a…”); I’ll cover that in another post.
Who Owns Which Layer
This is where the conversation gets productive, and where a book I was reading at the time gave me useful language.
In 50 Tips for Better User Stories, Gojko Adzic makes a point that resonated with how I’d been thinking: the business is responsible for the “In order to.” The delivery team (UX designers, developers, testers, everyone building the solution) is responsible for defining the “I want to’s.”
That’s not a minor detail. It shifts the whole dynamic of the conversation.
The business doesn’t own the solution. They own the goal. The team owns the options for reaching it.
One Why, Many Hows
Here’s where it gets creative.
Take a problem ride-sharing apps solved: the anxiety of waiting for a ride you can’t see. You don’t know where the car is. You don’t know how long to wait. That uncertainty is the problem.
The “In order to” might read: In order to reduce the anxiety of not knowing where my ride is.
Now the team generates “I want to” options:
-
I want to see my driver’s location on a live map in the app.
-
I want to receive a text notification when my driver is 15 minutes away.
Both serve the same Why. But they differ significantly in cost, complexity, and time to implement.
The live map is richer. It might be the ideal long-term experience. But it requires real-time location tracking, a mapping integration, and a continuously updating mobile interface. It has weight to it.
The SMS notification is simpler. It requires a phone number, a notification service, and a trigger condition. It might already provide meaningful relief to the anxious commuter.
Acknowledging the relationship between many Hows and a single Why opens space for creative, pragmatic decision-making. The team can assess each option on its merits: What’s the risk? What’s the cost? When could we deliver something of value?
Prototyping and the MVP as Experiment
When I was first sketching this framework, it was years before AI made rapid prototyping accessible. If you wanted to show stakeholders three different “I want to” options, you needed a UX designer, time, and probably some low-fidelity wireframes.
Now the picture looks different.
If the solution is software-based, you can use AI tools to generate a working prototype or interactive mockup in a fraction of the time. You can put it in front of users within days or hours, not sprints. Feedback comes early, when it’s most valuable.
That changes how you think about the minimum viable product. Instead of committing to a full implementation before learning anything, you treat the first “I want to” as a testable experiment. Send the SMS notification first. Learn whether users actually care. Measure whether the anxiety reduces. Then, if it does, you’ve validated the Why and earned the confidence to invest in the richer solution.
The roadmap becomes a sequence of experiments that are more likely to produce more valuable deliverables. That’s a very different way to build.
What I’m Learning
The Golden Circle is often described as a leadership and communication framework. I didn’t expect it to show up inside a user story. But the more I work with teams on requirements and story-writing, the more these structural parallels appear.
Clarifying who owns the Why versus who owns the Hows is one of the most practical shifts I’ve seen in collaborative teams. It removes the feeling that the business is dictating solutions, and it gives the delivery team genuine design authority. They’re not order-takers. They’re problem-solvers exploring a space defined by shared purpose.
What would it look like in your team if the business only defined the “In order to,” and the delivery team proposed several different “I want to’s” before any code was written?
Leave a Reply