Why does my team keep building the wrong version of what I asked for?

You can see the feature clearly. You explain it to your team, and they nod. Then they build something else. This is not a failure of their listening. It is a failure of your writing. A picture in your mind is not a specification. Specification is the dull work of listing every edge case, every "what if," every example of right and wrong output — before a single line of work begins. You skipped that work because it felt beneath you. It was the job. You and your team share this blind spot. You accept vague language as if it were precise, because precise language is harder and slower to write. Stop blaming the builder for guessing. Choose to write the test before you ask for the build.

◆ How this problem reads on the two dials

GuidanceKnowledge

Coaching

More to learn

1:1 with AureliusWith others (a Pod)

Some one-to-one

Practise with peers

This is mostly a missing skill — writing testable specs — so teaching leads, with coaching to build the habit of doing it together.

How the two dials adapt to you →

What’s really going on

The feature was never unclear in your head — it was unclear on paper. You described a picture and called it a specification. It was not. Stop describing the feature. Write the exact cases that prove it works, before anyone touches the work.

🔒 What you’ll build togetherUnlock by starting

A moveBefore any handoff, write three concrete examples: one normal case, one edge case, one failure case, with the exact expected output for each.

A moveTurn every sentence that says 'it should just work' into a numbered list of pass or fail checks.

A moveSit with the builder for ten minutes and have them repeat the spec back in their own words. Fix what they got wrong — in the writing, not just the conversation.

A moveName the ugly cases out loud before work starts: the empty input, the error, the user who does the strange thing.

A moveWhen the build is done, check it against what you wrote, not against what you remember meaning.

PractiseSpec the Edge Cases · a Pod of 4 · 30 min

What changes unlock by starting

Your team builds the right thing more often on the first attempt.
Fewer rounds of rework and fewer arguments about 'that's not what I meant.'
A written document you can point to, instead of a memory you have to defend.
A shared habit of writing specs that holds up after this one feature is forgotten.

One object, two jobs: a public answer to a real problem, and — the moment you start the chat — Aurelius’s live plan for your version of it.