The Founder’s View

Return to Leon, the fictional founder from The First Call. The call, cut list, messages and reactions in this chapter form a worked example, not a transcript or a client case history. He has spent a long weekend building a customer-analytics prototype. Now he wants a studio to help him decide what can reach users.

In the example, he joins the Thursday call.

I am going to tell this chapter from the other side of the glass. Most of this book has been written from the studio’s chair: the receiving end of napkins, the composer of cut lists, the invoicing hand. But the founder has her own chair, and it is a harder chair to sit in than the one I occupy. Everything this book has so far called the artefact is, from the founder’s side, a weekend. Everything called a feature is an argument she had with herself at eleven o’clock at night and won. Everything called a cut is the undoing of one of those arguments, in public, by someone she is paying. If the whole book only ever describes the studio’s posture, it does the founder a disservice, and it does the methodology a disservice as well. Sculpting is something a studio does with a founder rather than to her, and the founder’s half of the work is the half most likely to be skipped when the chapter is written by the studio.

Leon illustrates the harder case: an experienced founder who has shipped products before and still feels attached to a prototype he built himself. Experience gives him a vocabulary for the work; it does not tell us how he will respond when the studio proposes removing his features.

What happened on the Thursday call was, from his point of view, strange.

Imagine the first meeting he expects. A director joins, asks about the vision, scope, timeline and budget, and leaves with a feature list to price. Leon has prepared that list. He expects the call to help him express it.

Instead, the specialist from The First Call shares the running prototype she has already explored. She enters a test account, navigates to the results page and asks Leon whether the activity map is finished. He explains which parts use live data and which are placeholders. The studio can ask about a screen both sides can see.

That is the artefact-first call, the meeting that becomes inevitable once the scoping document has already been written in code. The mechanics were described in The First Call. What that chapter did not say is that the founder on the other end of the call is not always prepared for it. Leon was prepared intellectually but not emotionally. He had arrived expecting to explain his product, and was instead invited to watch someone else use it, which is a different kind of conversation, and a harder one to hold.

The cut list arrived on the Tuesday of the following week.

The illustrative cut list has five items under What stays and twelve under What goes. Leon built all seventeen. One proposed removal is a cross-metric comparison panel he spent much of Saturday arranging. The two-page document gives a reason for each removal and explains what the cut makes possible elsewhere.

What happened over the next seven days is the reason I am writing this chapter.

In the example, Leon replies that he needs a few days and will bring his reactions to the next Tuesday call. The studio agrees when to talk and leaves him that time. A founder may prefer an earlier discussion; agree the interval with them.

In this scenario, he is mourning the work he expects to lose. Not loudly, and not in a way that showed on the call the following week, but in the form of a slow, private re-sorting of the product in his head. Twelve of the seventeen features he had built, on his evenings and weekends and the limited time he had while running a company, were being proposed for the cutting-room floor. Each had, at some point during that weekend, felt like the point of the product. Reading the cut list required him to look back at each of those nights and concede, on the evidence of someone else’s read, that he had built the wrong thing. He had built it competently, and it would still not make it through to the version a stranger would pay for.

The IKEA effect offers one way to read this fictional response. The IKEA Effect, Industrialised described the mechanism. Norton and his colleagues did not test whether business experience protects a founder from it. Leon’s example illustrates the possibility of attachment; it does not supply evidence for its frequency.¹

On Tuesday, Leon accepts eight cuts, questions three and asks to revisit one later. He says that he dislikes the document and thinks the studio is mostly right. This is fictional dialogue. The team works through his objections: two features stay and one goes after they examine a Safari bug and the cost of repairing it.

By week three he was defending the cuts to his own team.

In week three, Leon’s engineer questions the removal of the cross-metric panel. Leon explains the reasons to his team instead of forwarding the objection to the studio. The engineer agrees to revisit it at the next review. The scene illustrates the handover we want: the founder can explain a decision in his own words.

In the example, relief arrives when Leon can defend the cut himself. The studio gave him reasons he could test. He has accepted those reasons and can explain them to someone who was not on the call.

The opposite possibility deserves attention too: a founder accepts a cut on the call and adds it back through small requests during the build. The studio needs a record of the decision and a way to reopen it. David Kravitz, my co-founder, has described the wider risk of continuing to work in the old way while the tools change around us. Leon’s fictional response illustrates one way a founder could adapt.

A first-time founder could reach the same point. The useful distinction in this example is willingness to examine the proposed cuts, ask questions and own the decision that follows. Prior experience may help someone name the change; it does not settle the choice for them.

What the studio owes, in return, is specific. It owes the founder a cut list written honestly, with reasons she can test against her own memory, not against the studio’s authority. It owes her the week. The week is the time the founder needs to do the work the studio cannot do for her, which is to look at her own weekend hours and re-sort them against a new shape of the product. A studio that treats the week as friction has not understood the engagement. The kindest thing we can do, having sent the cut list, is leave the founder alone with it until she is ready to speak.

There is also something the founder owes herself before arriving. David told me that when someone arrives with a working prototype, the first question he asks is whether the founder has thought through how it should actually work, whether any sense of UX is present, however rough. A prototype that shows no consideration is a draft, not an artefact. The distinction matters because a studio can only hold what has already been held.

There is a second, smaller thing the studio owes, easy to forget: the record of what she built. The twelve cut features should exist, somewhere in the repository, tagged at the commit before the deletion, with a short note on why each was cut and under what conditions it might be revisited. Most never will be. The record is for the founder, so that the weekend Leon spent on the cross-metric panel is not, in his own head, wasted hours. The panel did not ship; the work informed the cut. Those are different things, and a studio that conflates them is being unkind.

The founder who arrives with a repo has already done the hardest thing; the studio’s job is to not waste that courage.