Three Circles and Three Arrows

Murray is an illustrative reconstruction of the scoping problems we encountered in studio work. I have combined clients and invented the napkin, dialogue, dates and farm details to make that work visible. This is a worked example, not the documented history of one farmer.

Place the example in the South Island of New Zealand in 2012. Murray runs a beef operation across several properties, with two tractor drivers and a herd manager. He wants an application. His brief is a scanned napkin: three circles, three arrows, the labels cows, men and paddocks. The arrows connect all three in a rough triangle.

This was the brief.

I said yes to the call the next morning because in 2012 Sliday was three years old, we were hungry, and Murray had money. I assumed, as all of us assumed then, that I understood what he wanted. Thirty minutes into the conversation I realised I did not. An hour in, I realised he did not either. We were both trying to derive a product from a set of nouns that neither of us had ever said out loud together. By the end of that first call I had filled four pages of a notebook with words like rostering, GPS ear-tags, implement wear, drench schedule and ACC liability, and I was no closer to knowing what to build than when the napkin had arrived.

It took a year.

The year was not continuous work, and it was not billed as a year of work. It was a year of calls, emails, visits, sketches, corrections, re-sketches and a steady accumulation of facts about the beef industry that nobody had thought to tell us at the start because nobody thought those facts belonged in an application. Murray wanted to know which paddock each herd was in on any given day, because rotating grazing is the difference between a farm that breaks even and one that does not. He wanted to know when each tractor had last been serviced, because breakdowns at harvest time are measured in tens of thousands of dollars. He wanted tasks to generate themselves from the seasonal calendar, because his herd manager was in his sixties and forgot things. He wanted all of this to be usable with one hand on a phone in a paddock in the rain, because he had dropped two iPads in the previous eighteen months. None of this was on the napkin.

We got to the napkin’s truth by interrogation. Literally — I had a checklist of questions I would work through each call, and a file of his answers that I would re-read before the next one. The checklist and the answers became a scoping document, the artefact we were really selling, and our senior designer turned it into wireframes, which we sent through, which Murray would mark up and send back with notes like this menu should open up not down, because down means it is going away. Our senior developer, who would eventually have to build against whatever I wrote, spent most of that year writing almost nothing, waiting for the specification to stabilise into something he could read. I did not know at the time whether this was a good thing or a bad thing. It felt like work, and we were being paid for the work, and the work was moving. Only years later, talking to David about what Sliday had actually been selling in that first decade, did I see it clearly.

We had been selling translation.

We had known, for years before anyone had a word for what changed, that the translation was the expensive part. In 2017 Sliday built an app called Estimapp — a quoting app that walked a prospective client through multiple-choice screens and produced a detailed build quote, with hours, timeframes and taxes at the end. We built it to shorten the translation step. It did not. Estimapp is obsolete now, which is the right outcome: the quote was always, at the end, a confident-looking number attached to a picture the founder had not yet drawn. Estimapp could tell a client what the building would cost. It could not tell them what they were building.

Every client Sliday took on between 2009 and roughly 2022 arrived with something like Murray’s napkin. Not literally — some of them arrived with thirty-page briefing documents and some with a single sentence emailed on a Friday afternoon — but structurally the same thing. They had a picture of a working product in their head, and the picture was always more complete in their head than in any document they could produce, and our job was to close the distance between what they pictured and what they described. The methodology names we used for this work — discovery, scoping, user stories, wireframes, acceptance criteria — were all, underneath the vocabulary, the same operation. We were extracting a specification from a person who could not write one, and we were being paid well to do it.

Then 2022 arrived. The tools that had been curiosities on a designer’s weekend — GitHub Copilot, the first serious generative chat assistants, a quiet crop of prototype-builders — crossed a threshold between that year and the next, and within eighteen months a founder could produce, on a Saturday, something that used to take us six weeks. The napkin, without warning, started arriving as a running application. AI had landed, and the work reorganised around it.

The extraction was the business. The code, when we eventually wrote the code, was the easy bit. The hard bit, the expensive bit, the bit that killed more projects than any technical problem ever did, was the bit where a person’s mental picture became a document a developer could implement. That bit took months, and it produced scoping artefacts of genuine craft, and clients paid for it because they had no alternative way to get from idea in my head to thing on the App Store.

If you are reading this in 2026 and have spent a year writing prompts, the shape of the work will feel familiar. What we were doing, if you squint, was prompt engineering — the prompt being a thirty-page scoping document and the model a team of six humans who had to be kept aligned for four months. What we were doing around it was context engineering — except the context was assembled by hand: brand guidelines in a binder, user interviews in a shared drive, competitor screenshots pinned to a wall, every meeting minuted and forwarded by Thursday. The paperwork at the larger agencies now reads as the pre-digital version of what a well-loaded model does in a minute. Same operations, different substrate.

In the example, Murray gets his application. The point is the work required to get there: the calls, the scoping document and the translation of a business into a product. Across the studio’s first fifteen years, we learned to do that work and charge for it.

The right work for its time is also the clue.

I want to name the smallest version of what we were selling, because I missed it for most of the first decade. The hardest thing to close in extraction work was the gap between what lived inside a client’s head and what I, as a specialist, believed I had understood. That gap was delicate. You could not measure it. You stepped over it, or mostly stepped over it, or believed you had stepped over it until a demo fourteen weeks later said you had not. The guessing was the work. The checklist around the guessing was the craft.

Put a crude picture on it. Imagine two dots on a line. On the left, a specialist with zero per cent understanding of the product the client is picturing. On the right, the client at one hundred per cent, because the product lives inside her head.

In the extraction era my job was to drag the left dot right. A month of calls, sketches and corrections would carry a specialist to perhaps forty or fifty per cent of shared understanding — which was also, roughly, how much of the finished product we ended up shipping on the first round. The remaining gap, the fifty per cent the client still held alone, was what she felt in the demo. If the gap was wide, she left unhappy. Every studio I have ever run knew that moment.

The AI prototype changes where the dots start. The client now arrives at seventy or eighty per cent of the product already built — a running thing, over-engineered, absurd in places, but present. I read it on the first call, and my understanding of what she wants jumps in thirty minutes from zero to the same seventy or eighty. The dots converge before the second meeting.

The remaining gap is small, and the question inside it has changed from what is this to which of these features survive and which do not. Our job reversed: we reduce the excess in what the founder built rather than extract another specification. These percentages illustrate the direction of the change; they are not measured studio results. That is the sentence the rest of this book unpacks.

There is a canonical image, which you may have seen on the back of a conference lanyard or in a consultant’s slide deck, that draws three rows of cartoon vehicles to explain the history of software methodology.

The top row is waterfall: first a single wheel, then a wheel with an axle, then a chassis laid on top of the axle, then a complete sedan. Nothing in the top row is usable until the sedan at the end. The middle row is agile, as Henrik Kniberg’s 2016 illustration shows it: first a skateboard, then a scooter, then a bicycle, then a motorbike, then the sedan. Everything in the middle row goes somewhere. Each step is a working vehicle, rougher than the next, but complete on its own terms. The image works because it makes a methodological point without any words, which is the highest compliment you can pay an image in this business.

Top and middle rows adapted from Henrik Kniberg, “Making sense of MVP” (2016).¹

I am going to add a third row to that image, and that third row is the subject of this book.

The third row starts with a vehicle that is already driveable on day one. It is an over-engineered contraption bristling with equipment and antennae. It moves. It performs the function of a car. It is also structurally unsafe, cosmetically absurd, and likely to fall apart on the first motorway. The second frame of the third row removes some of the weaponry. The third frame removes more of it, straightens the panels, and fixes the paint. The fourth frame is the same sedan the other two rows end on. The difference is the direction of travel. The top row assembles. The middle row iterates. The bottom row subtracts.

If you are reading this book and you cannot yet see why the bottom row is different in kind from the other two, be patient with me for a chapter or two. It took Sliday about eighteen months of project work to see it ourselves, and we were living inside the change while it happened.

Now move the same illustrative farmer to 2026. Murray does not send napkins. He signs up to Lovable or Bolt or v0 on a Saturday morning, watches a YouTube tutorial, and by Sunday night he has produced a working prototype of the beef-herd application — not complete, not safe, not one anyone should run a business on, but working. He clicks around it. He shows it to his wife. He sends me the GitHub repository on Monday morning and he says, not can you build me something like this, but can you make this actually work.

That is a different brief, a different commercial relationship, a different skill set, and — as it turns out — a different methodology to describe.

Sliday kept doing what Sliday had always done for the first six months or so after Murray’s successor started appearing in our inbox. We tried to scope his repository the way we had scoped his napkin — long calls, user stories, careful extraction. It did not work, because the extraction had already been done. The repository was the specification. We were billing for translation work that no translation was required for. Our clients knew it, and they started treating the scoping phase as friction rather than as the core service. A few of them said so, in so many words, and the most honest one told me it felt like hiring a locksmith to open a door that was already open.

At roughly the same moment, the industry around us was having the same conversation at a higher volume. The METR study published in July 2025 caught sixteen experienced open-source developers in a controlled trial and measured them nineteen per cent slower on their own repositories when allowed to use the tools they believed made them faster.² The CodeScene work of Borg, Tornhill and colleagues in early 2026 put the stability side of the picture at a similar angle, finding that model-written refactorings broke fifteen to thirty per cent less often on healthy code than on unhealthy code, depending on the model, with some models showing no significant difference at all.³ Karpathy, the man who had coined Software 3.0 in a Y Combinator keynote only months earlier, posted on a social network in December 2025 that he had never felt this much behind as a programmer.⁴⁵ None of these people were wrong. The two studies were measuring narrower frictions: completion time in familiar repositories, and how reliably a model refactors code of differing health.

Every methodology of the last forty years was an attempt to bridge that gap, and every methodology failed in roughly the same way.