what we build · part one
The Translation
What happens at the moment the brief is signed. Why every JIRA artifact is a substitution risk. What gets carried, what gets replaced — and how to recognise the failure before it ships.
The brief is signed. What now?
A Feature Brief is signed on a Tuesday. The trio has reached genuine alignment. The Experience Snapshot contains Gal at her grading session and Uri at his Cardcom reconciliation. The Decisions are written. The Prediction has a baseline measured before any design or code. The team disperses to start work.
By the next week, the work has crossed at least four boundaries. The Product Owner has named Epics in JIRA. The designer has begun sketching from the journey. The tech lead has read the Decisions and started thinking about the schema. A developer has read the brief and asked the first question. Each crossing has created an artifact. Each artifact has a shape that is not the brief's shape.
The brief is a narrative — a witnessed sequence with verbatim quotes, a journey of phases marked friction or broken, a set of decisions and a prediction. JIRA is hierarchical: Epic, story, sub-task, scenario. A schema is relational: tables, columns, foreign keys, constraints. An API is contractual: verb, path, request, response, errors. A wireframe is spatial: regions, alignment, hierarchy.
Each of these shapes catches a part of the brief. Together, if chosen well, they preserve the meaning. Chosen poorly, each one quietly substitutes its own representation for the part of the brief it was supposed to carry. The substitution is rarely obvious at the moment it happens. It surfaces six weeks later, when a developer ships a feature that does what was specified and not what was needed.