A map the size of the empire: Shape Up, agencies, and non-trivial domains

A budget that does not move

If the work takes longer, the agency pays. In an article on bringing Shape Up into client work, Klaus Breyer lists this among the principles for agencies. Shape Up itself is how Basecamp built its product. In Ryan Singer's guide, time is fixed and scope is not. The work starts before the build, with shaping. A few people first set the appetite, the time the business is willing to spend, and then define the problem, a rough solution and its limits. They write the result up as a pitch. A bet commits a team to one pitch for one uninterrupted cycle, with the work expected to be finished. During the cycle, the team hammers the scope, cutting what does not fit. Work still not finished when the cycle ends is stopped by default, not extended; the guide calls this the circuit breaker, and Breyer's guarantee takes its place. The guide ties each step to one risk, not shipping on time: shaping removes the rabbit holes, parts too unknown or open-ended to bet on, and the team builds the most unknown parts first. In its agency version, Shape Up turns the appetite into a fixed budget, the thing that stirs the most emotion in client work, and leaves the scope to be hammered.

Breyer illustrates this with the process of Bruce van Zyl, an agency owner, as he described it in a conversation with Singer. A 30-minute call comes first, then a paid discovery project of about two weeks: it opens with a two-hour session, and the client's founder takes part in at least a couple of its sessions. Between the sessions, the agency team does the shaping and brings the client a set of pitches, each a fixed-length package of work, to choose from.

When I took a course on Shape Up, shaping looked familiar: it is close to the product workshops I have run with clients over ten years as a project manager at Visuality, and to my work as a UX designer. We have never used Shape Up in commercial projects, though. Nor on this article: it ran to almost twice its planned length, and its scope was never hammered. 🤷‍♂️

The course took eight hours and was taught by Enrique Comba Riepenhausen, an expert and long-time practitioner; what follows is my reading, not his. In simple domains, van Zyl's process may well work for packages of work of any size; my reading starts where the domain stops being simple.

This article asks whether Shape Up is a good fit when a client starts working with an agency that does not know its product yet.

Maps and territories

In Breyer's own summary of van Zyl's process, the client's part in shaping comes down to a two-hour session and a presentation of pitches. Breyer's principles ask the client for an active part in shaping, and so does van Zyl when he describes his process to Singer. In both versions, though, an agency team that does not know the product yet shapes the pitches for the first bet within about two weeks, and that window is what I argue with. The sources also name limits: for Breyer, a relationship without trust, projects shorter than two weeks and a client whose top management does not back the work; in the conversation, reactive work for Singer and large organizations for van Zyl. All are visible before signing; none concerns the domain. Singer's guide does not name the domain as a limit either, but it expects whoever shapes to judge why a problem matters to the business and what solving it is worth.

A map is not the territory it represents: Alfred Korzybski's line is well known. The second half of his sentence is quoted less often: a correct map is useful because its structure resembles the territory's. For a product, the map is the model of its rules, and whether its structure is right can be judged only by someone who knows the territory. A domain is non-trivial when the people shaping the work cannot assemble the product's rules from ordinary experience, as applying some of them correctly requires a practitioner's in-depth knowledge; either side can usually tell this before signing. A platform for meeting friends by video during the pandemic, built for a client in the UK, sits at the trivial end: the whole team lived that domain at the time. Difficulty of form is a different matter. A memorial platform in California, for victims of historical violence, was hard to give its final form, yet the weekly rounds converged into a successful launch despite a nine-hour time difference, because its rules needed no practitioner.

A race registration platform, built for a client in the US, looks like a product anyone could shape from ordinary experience. Yet even that product turns out to be non-trivial, and my argument applies from its level up. There are as many ways to run a race as there are organizers, and the same product had to serve charity races run in teams or relays and ordinary races, where everyone runs alone and results are split by distance, gender and age group. How to serve the first well while still serving the second could not be worked out in one or two conversations with the product owner. Further up sits a recruiting platform for the US legal market: before seeing what would add value, the team had to learn how lawyers move between law firms and in-house legal departments, how recruiters are paid for placements and referrals, and a dense web of US regulation. Higher still is US healthcare, to which I return below.

What does not travel

In a non-trivial domain, part of the knowledge the agency team lacks is tacit: it cannot be handed over, only built in rounds with the client's expert; that takes longer than two weeks, and behind hard barriers some of it cannot be built at all.

Knowing more than one can tell

The obvious fix is to bring in the client's expert, and van Zyl's process often does so anyway: at the scale of our clients, the founder who takes part in discovery frequently is, or was, the domain expert. Having the expert in the room does not transfer the knowledge: in my projects the expert was usually present and the knowledge still did not pass, because an expert recognizes a wrong model more readily than they can describe a right one.

"We can know more than we can tell," writes Michael Polanyi in The Tacit Dimension. We recognize a familiar face among thousands without being able to say how; the expert reads the agency's model the same way.

Our team had to go through training and pass knowledge tests on US healthcare, and still could not, on its own, propose features critical to the business (nobody expected us to). Nor does the expert hold the whole model: in discussions of new features for that product, we watched the client's product owner revise the rules of legal dependency, such as between a child and a guardian, and at times step back after new findings. On a property valuation platform for lenders in the UK, one of the client's domain experts, who knew the product better than our developers, specified a small portal from a general description of a need, without working it through with the rest of the business. The business saw it only after the first phase, and its corrections took another month, about as long as the original build. The product owner of the race registration platform knew the domain well, yet could not tell which details of an offline kiosk at race venues would matter to us if we were to plan the best version of it.

Rounds with an expert are therefore the only way in: the agency proposes a model of the domain's rules, the expert picks what fits and corrects the rest, and the agency proposes again. This is a probe-sense-respond loop, the kind used when the answer cannot be worked out in advance: try something, see how it lands, adjust. In the same passage about faces, Polanyi describes a police method that works the same way. To help a witness describe a face, the police show a large set of pictures of noses, mouths and other features; the witness picks those that match, and a likeness is assembled. It works only because the witness can match the pictures against a face they cannot put into words. The agency's proposals are the pictures, and the expert is the witness, so the pace of the rounds is set by the expert.

Ever more detailed maps

Which method an agency uses matters less than it seems. A client can tell an agency about the domain in workshops, in event storming, through an impact estimation table or in a Lego game, and in a non-trivial domain the telling still carries only part of it: learning such a domain takes time, patience and exposure, which no session compresses. Telling it in more detail does not close the gap.

…In that Empire, the Art of Cartography attained such Perfection that the map of a single Province occupied the entirety of a City, and the map of the Empire, the entirety of a Province. In time, those Unconscionable Maps no longer satisfied, and the Cartographers Guilds struck a Map of the Empire whose size was that of the Empire, and which coincided point for point with it. The following Generations, who were not so fond of the Study of Cartography as their Forebears had been, saw that that vast Map was Useless, and not without some Pitilessness was it, that they delivered it up to the Inclemencies of Sun and Winters. In the Deserts of the West, still today, there are Tattered Ruins of that Map, inhabited by Animals and Beggars; in all the Land there is no other Relic of the Disciplines of Geography.

Jorge Luis Borges, On Exactitude in Science, translated by Andrew Hurley.

The escalation is ours too: every session covered more of the client's world, and the most detailed telling, like the map that coincided with the Empire point for point, was the least useful. Korzybski's map is useful through its structure; this one failed through its size. A smaller map that works needs someone who knows which details to leave out, and that is what a team new to the domain cannot tell.

In van Zyl's process the client chooses the direction, by picking the bet from the pitches; the shaping behind each pitch, its appetite included, is the agency team's work, and that is where my claim sits. Ten years of agency work tell me that for people who do not know the product, the rounds needed to shape features that depend on domain rules do not fit into two weeks, even with the expert available on demand. That is experience, not proof: in ten years no project let our development team move freely in a non-trivial domain.

Ryan Singer's own case study had Singer, new to the product, at the table as an external fractional CPO, along with two people from inside the company: a senior engineer who knew the product and its code, and a subject-matter expert, a salesperson who used to run his own gym. After the first session with the engineer, domain questions remained that neither of them could answer, so the expert joined the next one. Shaping took a few sessions, and the project was built and shipped. It worked, and the difference from the setting of my claim is who shaped: the engineer brought the product and its code, the expert its domain, and both shaped with Singer rather than only answering his questions.

Behind the barrier

Three of my agency's collaborations have lasted between two and four years each, and in none of them has the gap closed, because the knowledge sits behind barriers that time does not erode, such as the contractual restrictions on US health data that have kept developers outside the US away from the production environment and its data.

The client could tell us what the rules of US healthcare are, but could not show us how the product lives with them: no developer reads the conversations with its users as a matter of course, and for our team even access for a specific task was closed. On the recruiting platform for the US legal market, the inside of the headhunters' work stayed closed to us, so the client shaped the business side and we built to its requirements. In the UK, where the product serves property valuations for lenders, the main barriers are the client's security rules, which tighten as it works toward a certification, and the way banks must be dealt with. Under those rules our team has no access to production, its data or its users, learns about errors there from the client's product owner, and will see less of the sensitive data in error reports. Both restrictions on production are the clients' own decisions, and their reasons do not fade: the risk a client carries for its data, and the banks it serves and those it hopes to work with. Each institution expects its own manner and channels of communication, and that knowledge lives in the client's conversations with them. Because banks connect through the product's API, a developer from our team takes part in some of those conversations, to answer what can change, how and when, but the requirements always travel from the bank to us, never the other way. Part of the market picture also forms offline, in meetings a team abroad never joins.

This rests on three cross-border collaborations of one agency, none of them using Shape Up. All three clients have been satisfied with our work, and the feeling has been mutual.

Such barriers block the exposure that learning a non-trivial domain needs, and time cannot replace exposure. Behind them, without the client's people in the shaping itself, an agency will rarely deliver value other than technical. Technical here is a generous word: it also covers an interface that meets general usability standards, such as Nielsen's heuristics, and local fixes to the user flow.

Local optimizations and rabbit holes

Whoever does not know what is critical to the business improves what is visible and misses what is not: the part gets better while the whole becomes slower and costlier to change, and the rabbit holes surface later, in the build or after the release. When we joined the race registration platform, the code had no tests, and our way to learn it and make it safer to change was to cover it: we aimed for 70 to 80 percent and got there. We wrote most of those tests at the start, before we knew the product or the business, so the areas that mattered most got no deeper tests than the rest, while CI ran for over ten minutes and flaked, every pull request waited about half an hour, and the costliest bugs still reached production for a while. It was an engineering decision at the start, not the shaping of a bet, but the pattern is the same.

A rabbit hole is a different cost: not effort in the wrong place, but a risk nobody saw in time. The visit scheduler in the US healthcare product, a core feature for the business and for end users, handled virtual and in-person visits with different specialists at different facilities through an external API, and depended on much of the rest of the system. It took far more work and fixes than anything else, and fixing it felt like the squirrel from Ice Age plugging leaks in a wall of ice: plug one, and another opens.

The kiosk at race venues, mentioned above, was another. It had to keep working offline and fit when and how runners use it on race day, and the simplest way to learn that, watching a race on site, was out of reach, so the requirements took many rounds. The roles were the reverse of the scheduler's: there the client's product owners wrote the specification and our team could propose corrections at every stage; here we wrote the requirements ourselves, from conversations with the product owner. Either way, a map drawn by one side of the table leaves details out, and they come back in the build.

The two costs share a root: what is critical to the business and how the system works are known by different people. Apart from bug fixes, I'd say no less than 90 percent of the changes made to digital products are local optimizations. The real bottleneck shows up where current, deep knowledge of the domain and the product meets deep knowledge of the technology and the codebase, and data good enough to show where the product stands, or only in hindsight, once the business results have improved. Hence the trying: one more feature, just in case it is the one the business was waiting for.

A toe in the water

It is tempting to start small, and a small first package of work does put less of the budget at risk. A smaller package of work does not need proportionally less knowledge, because the system and the domain are interdependent; the exception is a feature that stands fairly apart from the rest, and such a feature is rarely what is critical to the business. The visit scheduler was a single feature, and it reached into much of the system. Writing the product from scratch helps only with the code: the team learns the code as it writes it, but not the domain.

At the table

Two checks

Before signing, both sides should settle who sits at the shaping table: if no one there knows the product well, the first shaping needs more time than the agency's process grants, and behind hard barriers it also needs the client's people. For the client, that means naming the people: who knows the product well enough to sit at that table, and whether they can give it the time. When the client is also the expert, the question concerns the decision-maker's own calendar. Behind hard barriers, it also means committing the client's people to the shaping itself, not only to answering questions. Breyer's principles already ask the client for an active part and for the backing of its top management; a non-trivial domain adds the time (or effort). Singer's recent primer, written for operators who need software for their own work, shows where that effort can start: writing down, from past cases, how the work runs today, then sketching how it should run, before hiring anyone to build it. In a non-trivial domain, such preparation carries only the part that can be told.

For the agency, it means checking whether its process allows the first shaping to run longer than the usual window, as a longer paid discovery, and saying so in the offer, before the budget is fixed. It also means keeping the same people on the product, since the knowledge built in the rounds stays with them.

A safer opening move

Two cases fall outside this article. One is maintaining a product: for that, van Zyl describes a separate monthly subscription of 20 hours, run as its own process next to the Shape Up cycles. The other is a new product still in its R&D stage: Singer's guide gives that stage to the company's senior people, because the team has to hold the product's vision, and an agency team on a first contract does not hold it yet.

In a non-trivial domain, opening a new agency relationship with Shape Up is an unnecessary risk; Shape Up begins to pay off once someone who knows the product intimately sits at the shaping table, in-house, or with the agency when the client brings its own expert and a developer who knows its code. The second half of that sentence follows from the argument, like the checks above; the first half goes a step further, and that step is my recommendation rather than a conclusion. The risk sits in the opening, not in the method: a team that does not know the product shapes the pitches for the first bet in a fixed window, and the budget rests on that shaping. Instead of opening with Shape Up, start with a model that does not tie the budget to an outcome shaped before the team knows the product; it can still cap the time, but the client pays for the team's learning. Where the product can be learned within weeks, the longer paid discovery from the checks above is such a model; where learning it takes months, it happens in the work on the product itself, and the team returns to Shape Up once the knowledge is at the table. Behind hard barriers, that moment may never come on the agency's side.

The exception is a pilot where the knowledge already sits at the table: the client brings its experts and a developer who knows its codebase, and the agency joins them. That is close to the setting of Singer's case study above, and it lets both sides try Shape Up without betting the relationship on it.

What would change my mind is a case from a non-trivial domain in which a short transfer was enough for a team that did not know the product: two weeks, an available expert, and a first bet whose features critical to the business were shaped right. I have not seen one in ten years, which proves nothing, so if you have, I would like to hear how it went.