Experience Is the Unit

Imagine the system that does everything it was asked to do.

Invitations go out on time. Places fill. Scores publish. Sponsor messages land exactly when the run-sheet said they should. Ops can point at a dashboard that is, by its own lights, a success. Every row is green.

And the day is wrong.

The group has the wrong people in it. Beginners feel exposed on a course that was never going to suit them. Sponsor activity interrupts the conversations that were supposed to be the point. The corporate host spends the afternoon resolving problems instead of hosting customers. Nobody would write a review that made you proud — except, perhaps, the operations report.

The system completed its tasks. The company failed to deliver the intended experience.

That is not a story about buggy software. It is not a story about lazy agents. It is a story about a company organised around the wrong unit of measure.

Production is not value

The unit of production might be code, a document or a completed task. The unit of value is the experience the client actually receives.

Simply replacing “software features” with “agent tasks” does not fix the original mistake. Both keep the company focused on its internal activity rather than on what that activity does for the customer. You can improve forever on the production unit and still not know whether the business is any good.

I was a photocopying expert

My first accounting job made the distinction physical.

Everything lived in manila folders. A lot of the work was typed letters, invoices, tax returns, copies of tax returns. Photocopying was more than half of what I did. Different documents needed different numbers of copies — tax office, client, firm file. There were codes on the machine so the firm could charge the client for the copies. If you had to describe the job by how many hours you spent, I was a photocopying expert.

That was never why the client engaged the firm.

The photocopying was production overhead around the service. The service was understanding the client, exercising judgement, accepting responsibility, and preparing the next person on the account to do good work. Cumbersome tools did not mean the client was poorly understood. Equally, the team’s pride was not the only measure; what the client actually received still mattered.

If we describe an AI-native company by lines of code generated, tools called or tasks completed, we might be describing its photocopying — not its value.

Hours were the billing unit in that firm. They were not necessarily the value unit. The same separation applies now. A service can be personal without being billed hourly. It can be individually designed without being reinvented from scratch. It can be repeatable in quality without producing an identical answer. What you must not do is let the easiest thing to count become the thing you optimise.

Why coding looks like the prize

Coding is an outsized AI capability for understandable reasons. It has a relatively clear feedback mechanism: execute the code, run tests, inspect failures, improve it. That verifiability helps explain its prominence without requiring a conspiracy theory about frontier labs. Anthropic’s measurements of agent autonomy in practice found software engineering accounting for nearly half of agentic activity on their public API sample¹ — useful as a picture of where agent effort concentrates, not as a universal market statistic.

What is convenient to demonstrate and evaluate is not necessarily the right organising principle for a company.

The wrong inference is: AI is excellent at writing software, so our opportunity is to build more software.

The right inference is: AI gives us substantial new delivery capability. What experience could we now provide that was previously impractical?

Coding then becomes one of the ways to make that experience possible. An agent might create a calculation, a temporary interface or a specialised tool during the work. The coding capability can be strategically important without the code becoming the product — or the score.

That sounds reckless until you put it next to the green dashboard. Coding becomes a distraction when its visibility and measurability pull attention away from the value it is supposed to enable. The same is true of watching agents complete tasks. Operational tests still matter: payments must reconcile, invitations must reach the intended recipients, commitments must be tracked. They establish component performance. They do not establish the entire customer experience.

What “experience” means here

Experience, in this book, is not a pleasant interface. For an engagement business it means something closer to this:

The client’s end-to-end experience of achieving something worthwhile — with the right people, appropriate attention and minimal unnecessary burden.

That includes what happens before, during and after. It includes enjoyment and belonging where those matter, and also whether the engagement advances the client’s actual purpose. Judge it through three connected lenses:

Those are not all reducible to one satisfaction score. Client and participant feedback, observed outcomes and subsequent behaviour supply different pieces of evidence. A model declaring its own design “excellent” establishes none of them.

In a business setting a remarkable experience might be less uncertainty, fewer handoffs, a resolved problem, or confidence that someone is holding the whole responsibility. The golf day is a specimen used throughout this book because it makes stakeholders visible. The unit claim travels.

Stop scoring the photocopying

The agent’s central brief, once you accept the unit shift, is not “complete the task list.” It is closer to: understand the experience we are trying to create for this client; work out what would improve it; arrange what is needed; notice when circumstances change; retain what we learn. Tasks emerge from that responsibility. Software emerges where it helps perform those tasks.

The question for a founder or operator is not how impressive the software or the agent team looks in a demo.

It is how much better it is to be this company’s customer.

The next chapter splits the work that creates value into two jobs that builders routinely collapse into one: removing unwanted effort, and creating time worth spending. A flawless registration app only ever does the first.

Pine and Gilmore draw a line that most “customer experience” programmes quietly erase.

Services, they argue, compete on time well saved. Experiences compete on time well spent. What consumers look for with rapidly commoditising services is to spend less time on the transaction; what they seek from engaging experiences is to value the time they spend with you.² Making things merely nice, easy and convenient can mean customers spend less time with you — and less money as well. That is exactly what they want from services, so they can spend harder-earned time on memorable, personal experiences that actually engage.

Services are delivered. Experiences are staged. Confusing the two is how a flawless checkout gets mistaken for a day worth having.

That distinction is not leisure theory bolted onto business. It is the commercial shape of Chapter 1’s unit claim. Friction removal and experience creation are both necessary. They are not the same achievement.

Two jobs in one engagement

Take a corporate relationship day built around golf — the specimen used throughout this book because the stakeholders are visible. There are two different jobs inside it.

Job one is removing what nobody particularly wants: chasing registrations, reconciling payments, repeating information, coordinating arrangements, remembering follow-ups. Time well saved.

Job two is creating what people actually came for: enjoyment, belonging, useful conversation, stronger relationships, a day that advances a real purpose. Time well spent.

Your proposed company should do both: minimise the effort required to participate, maximise the value of participating.

A perfectly functioning registration app addresses the first job. It does not, by itself, establish that the company is good at the second. Builders who stop at job one are polishing the photocopying from Chapter 1 and calling it customer experience.

The requirement as a premature answer

This is where backlog thinking does its quiet damage.

Consider the requirement: Build configurable sponsor packages.

That sentence has already made several decisions. Sponsorship should be packaged. Packages should be configured. A software interface is how the business should manage the variation. The design space has collapsed into an application feature before anyone asked whether a sponsor would improve this particular engagement.

Compare that with: Work out whether a sponsor would improve this event, what they could contribute, and how both the client and the sponsor would benefit.

The second brief permits a different answer — including no sponsor. It may produce an introduction, a tailored agreement, an activity, a small piece of software, or simply a decision. The work stays open until the situation is understood.

Once you accept that distinction, Agile’s familiar progress measure needs careful handling. The principles behind the Agile Manifesto state that working software is the primary measure of progress.³ That makes sense for developing software. It is not a sufficient measure of progress for building a company whose product is a lived engagement.

Be fair to the manifesto: it also puts customer satisfaction through valuable software at the top of its list. The move here is one layer deeper. Valuable software can still be photocopying if the company’s real promise is an experience that software alone cannot constitute. Keep rapid feedback and small experiments. Change their object.

Not “What should we add to the next release?” but “What did this engagement teach us about delivering greater value?”

Where systems thinking helps — and where it traps you

Systems thinking remains useful when the system is the client, the participants, the relationships, the delivery and the learning loop. It becomes restrictive when the application is mistaken for that whole system.

Software preserves decisions made earlier: these inputs, these branches, these permitted outputs. Agents can assess the current situation and choose how to use available capabilities. That division of labour matters for an engagement company:

• Consistency in the commitments — correct amounts, honoured permissions, confirmed arrangements, accurate records, clear ownership.
• Flexibility in the service — who should attend, what format fits, what preparation is useful, when to intervene, what to leave alone, what should happen next.

The payment calculation should not be creative. The design of the experience should not be confined to the imagination of whoever wrote the payment application. Consistent standards do not require identical experiences.

The compounding asset, if you are doing this properly, is better judgement about what matters — not merely another feature. A useful learning might be that an introduction before the event mattered more than another activity during it; that a group valued privacy and combining them with another company would have undermined the purpose; that a follow-up was relevant but arrived before the client was ready to act. Sometimes better service means adding something. Sometimes it means having enough understanding not to.

That couplet gets its full delivery treatment later. First you need a design target that is sharper than a backlog item and more honest than a vanity score. The next chapter installs that target: write the testimonial you would be proud to have earned — then work backwards from the words.

Amazon’s Working Backwards method has a simple key tenet: start by defining the customer experience, then iteratively work backwards until the team achieves clarity of thought around what to build. Its principal tool is a written narrative — the PR/FAQ — that forces a customer perspective before precious development resources are committed.⁴

That is ancestry, not destination.

Working Backwards is typically applied to product launches. The method in this book applies the same discipline to every delivered engagement, and to every stakeholder at once, with a compatibility test you will meet in the next chapter. You are not writing a press release for a SKU. You are writing the review you would be proud to have earned — then assembling the company’s work around making that review honestly possible.

Design backwards from the testimonial you would be proud to have earned, then let that experience pull the work, tools and code into existence.

Step one: clear the inherited assumptions

Tongue in cheek, and serious: rm -rf the inherited solution assumptions.

Clear the design space, not necessarily the repository. Keep useful knowledge, relationships, customer records and proven capabilities. Remove the assumption that the existing app — or a competitor’s app — defines what the company should deliver. Anything already built becomes an available resource, not a requirement. It earns its place by supporting the experience.

That reset is harder than it sounds after twenty years of software-centred corporate life. People reach for the feature list because the feature list is what they have been trained to see. Testimonial-back design refuses that first move.

Step two: write the experience you want to earn

For a corporate client, an imagined future review — not a claim about an actual event — might read:

And the extraordinary longer-term version:

“One of the relationships that started that day became our most valuable new client.”

That last result is an upside to pursue and subsequently verify. It is not something a pairing algorithm can promise. Put it in the design space as a possibility you will look for evidence of afterwards — never as a sales claim on the way in.

The review is a target, not a script

This is where testimonial-back design goes wrong in careless hands. People treat the imagined review as copy to extract from the customer. That is not the method.

The most useful review is not necessarily the most enthusiastic. “The advance introductions made all the difference” teaches you more than “Great day, five stars.” A negative observation can be equally valuable: “The introductions were useful, but there were too many of them.” That should change the next design, not be filed under feedback and forgotten.

Work backwards from the words

Take a single line from the imagined review:

“I was paired with people I genuinely enjoyed talking to.”

What would help make that true? Understanding preferences. Knowing something relevant about the participants. Choosing thoughtful groupings. Allowing discretion or changes when the first grouping is wrong.

That does not yet imply a matching application. It might require a conversation, a few knowledge lookups, judgement and a short briefing. Code enters only when a specific part of the work benefits from it.

The same backwards pass applies to every intended review. Four questions carry the work:

Those four questions are the operating handle of the method. Chapter 9 walks them through a full engagement. Here it is enough to see the direction of pull:

Desired experience → conditions needed to create it → knowledge and actions required → missing capabilities → code only where useful.

First define the experience worth earning a remarkable review. Then assemble the company’s work around making it real — not around making customers use what you already built.

One review is not enough. An engagement has a host, invitees, a venue, sometimes a sponsor, suppliers, and the company itself. Each has a different definition of success. The design challenge is not to optimise one of them. It is to create reviews that can be true together. That compatibility test is the next chapter.

Start with the conflict, not the catalogue.

You have written a sponsor review you would be proud to earn: relevant, welcomed participation; useful conversations; permission to follow up — not merely a logo on a banner. You have also written a guest review: paired with people worth talking to; comfortable; included; never pressured to network or buy anything.

Now put them on the same afternoon.

If the sponsor’s “excellent exposure” requires interrupting conversations, cornering beginners, or turning the drinks tent into a pitch bay, the guest review becomes impossible. You did not discover that failure in a retrospective. You designed it when you treated each review as an independent optimisation.

The design challenge is to create mutually compatible value — not optimise one stakeholder at everyone else’s expense.

Blank’s 2026 teaching noted the same multi-party gap from another direction: polished deliverables were being confused with the need to understand all the stakeholders, not only to ship something that looked finished.⁵ Compatibility is how that stakeholder set becomes a design constraint rather than a retrospective apology.

One event. Several definitions of success.

For a particular engagement, the reviews you would aim to earn might look like this. These are starting hypotheses for this event, not another catalogue of standard packages.

Two players in the same group might want different things: one wants introductions; another wants a relaxed afternoon with existing colleagues. Compatibility is not unanimity. It is the absence of designed contradiction.

Three conflicts that kill the design

Compatibility is a creative constraint

Treating compatibility as a constraint does not shrink ambition. It focuses it. The restrained sponsor who earns three good conversations and permission to follow up may create more commercial value than the loud sponsor who “reached” everyone and left a taste. The smaller group that fits may outperform the filled tee sheet that does not. The private relationship day with no outsiders may be the right answer even when your inventory of contacts is itching to be used.

Chapter 9 walks a full engagement through this test with a real conflict resolved in the design. Here the doctrine is enough: write the reviews; force them to cohere; only then work backwards into what must be true, understood, arranged and evidenced.

Once those targets can live together, you still have to make the afternoon feel like something other than competent logistics. The next chapter names that quality without mysticism: appropriate attention — and the same-budget experiment that proves you can improve it without buying more hospitality.

That is the first experiment. Write it down before you budget for better drinks or a car service.

The experiment isolates the advantage you are actually trying to build. Otherwise an expensive chauffeur can conceal the fact that the underlying experience design is ordinary. You are initially seeking more value from the arrangement of the resources, not simply more resources.

What the guest should feel

They feel understood without feeling studied, and looked after without feeling managed.

“Magical” should mean unusually relevant — not unnervingly well informed. That single distinction protects both taste and privacy.

The aim is designed opportunities for good encounters, not engineered social pressure. Every participant should have a reason to value being there — not simply serve as a prospect for the organiser.

Privacy in proportion

For any briefing sheet, start with attendee-provided information and supplement it sparingly with sourced public professional information. Ask about preferences directly. Do not infer why someone does not drink from their online history. Identifiable opinions are personal information too; health or religious information attracts additional protection. That is the whole privacy doctrine for this book: proportion, not a compliance chapter. Creepiness is not a strategy.

Early intensity is not a product feature

Paul Graham’s early-stage advice lands here from another angle. What founders often miss, he writes, is that early “insanely great” is not primarily the product — it is the experience of being your user. The product is just one component. You can and should give users an insanely great experience with an early, incomplete product if you make up the difference with attentiveness. He has never once seen a startup lured down a blind alley by trying too hard to make their initial users happy.⁶

That is not a licence for permanent heroics. It is permission to treat early engagements as places where appropriate attention is the method — and to capture what that attention teaches so the company does not have to invent it again from scratch.

Three returns from the afternoon

Design each engagement to leave the company with more than a nice memory:

• Commercial evidence — what the client valued, what they would pay for again, whether worthwhile relationships or opportunities actually followed.
• Reusable judgement — which combinations worked, under what conditions, what disappointed people, which assumptions need changing.
• Earned credibility — a genuine review, referral or case study, where participants have agreed to that use.

The afternoon is temporary. The relationships, evidence and better judgement can outlast it. How early pricing buys those returns without lying about willingness to pay is a later chapter. First raise the ambition of what you are designing toward.

The next chapter pushes the limiting variable — the cost and availability of expert attention — to an extreme, then sharpens it back to an ordinary client budget. That is how you stop designing the service a small team can afford to imagine, and start designing the service an exceptionally capable company would deliver.

The billion-dollar thought experiment is a way to break the app-first frame. Design the service as though expert attention were abundant, then work backwards to an agent-native company.

The cognitive richness of that service is the target. Its thousand-person organisation chart and billion-dollar cost base are not.

Push the limiting variable — the cost and availability of expert attention — to an extreme until a different design becomes visible. Then sharpen:

Keep the client’s event budget ordinary. Remove the limits on the research, thinking, design, checking and coordination available to serve them. What would we now do differently?

Not better gifts. Not more expensive hospitality. Not subsidised extravagance. Better understanding and execution around the same real-world resources. That is the sister of Chapter 5’s same-budget experiment, run at the level of company ambition rather than a single afternoon’s hospitality line.

What would that company actually deliver?

Do not start by designing a global events platform. Start with:

“What would this client experience if an exceptionally capable organisation understood their situation, cared about their outcome and could devote substantial attention to getting it right?”

The distinction is not “we run a more elaborate day.” It is “we make a better decision about what this client needs, then take responsibility for delivering the agreed experience.” For one client that might mean a private retention day. For another, a carefully assembled group of complementary businesses. For another, fewer participants and more time for conversation. Occasionally the best answer is: do not run another event yet; follow through on the relationships the previous one created.

Imagine human excellence. Engineer machine-native delivery.

Recover the questions that come before application design:

• Who are we serving?
• What do they value?
• What can we do exceptionally well?
• Which relationships and capabilities must we develop?
• Why would they pay us rather than organise it themselves?

An application inventory does not answer those questions. The work an organisation currently performs is often a rationed selection, not a complete inventory of valuable work. Starting with existing workflows can exclude the thinking nobody previously had the budget to commission.

Crucially, the ideal team is a benchmark for the quality of the service, not a blueprint for the agents. You need not reproduce departments, meetings, reporting lines and human handoffs. Organise around the work: understand the situation, explore alternatives, check feasibility, assemble the chosen delivery, evaluate the result. Anthropic’s own guidance on building effective agents lands nearby: success is less about the most sophisticated system than about the right system for your needs, with clear success criteria and meaningful human oversight.⁷

Cheap intelligence is not unlimited money

Abundant cognition changes what was previously unaffordable for substantial parts of cognitive labour. It does not literally equal unlimited money and people.

A funded organisation can purchase physical execution, reserve capacity, commission first-hand investigation and absorb commercial risk. A model cannot turn an unavailable tee time into an available one, make a particular person accept an invitation, or infer private client facts that nobody has supplied. Nor is more inference automatically equivalent to better expertise.

That distinction strengthens the investment rule: use AI wherever it can supply the thinking, and spend scarce money on the remaining constraints — an excellent practitioner, trusted relationships, on-the-day hosts, access to better evidence — rather than a large speculative feature backlog.

Two passes, then:

1. Design the best client outcome without prematurely rationing the thinking. Keep the client’s time, preferences and practical circumstances central. Unlimited preparation should not become unlimited messages or demands on the customer.
2. Work backwards to the delivery model. What can existing agents and knowledge already do? What evidence is missing? What requires a person or partner? What needs a small tool? What is not yet reliable enough to promise?

You can ignore revenue temporarily to discover the service’s potential. You bring economics back before deciding what to sell and scale. The test is whether the fitted service creates enough customer value to cover its actual delivery cost — not whether a billion-dollar subsidy could make it wonderful.

The next chapter is the homework that fills that cognitive space: capture what you already know, augment it lightly, and design combinations rather than rankings.

The homework that makes Chapter 5’s “magic” possible is not sending invitations faster. It is giving the company enough understanding to work out which people could benefit from being brought together, why this occasion would suit them, and how to make it worthwhile for everyone.

That work can happen before there is even an event to advertise.

Which combination of people would make this occasion valuable enough that each would want to participate?

Three layers of network intelligence

Capture more than names, titles and organisations.

Public research tells you who someone appears to be professionally. Your relationship history helps establish who they are to you. Neither alone tells you whether they want this invitation.

A practical starting inventory might be an export of first-degree professional connections, reviewed in conversation with the person who actually knows them: “We worked together years ago. She brought customers to our last event and enjoyed it. He likes golf but does not want an all-day commitment. I know that person well enough to ask about an introduction.” Those distinctions are precisely what a public profile cannot supply.

Design combinations

The question is no longer simply “Who is a good candidate?” Ranking individuals by a universal score flattens the thing that creates value: composition.

The following is a hypothetical worked example, not a reported event.

Suppose your records contained three separate facts. A past corporate client enjoyed meeting other businesses and expressed interest in another event. A club contact wanted introductions to potential corporate customers. A sponsor preferred a small number of relevant conversations over broad logo exposure. None of those records individually says “this is the next engagement.” Combined with a new enquiry — say a small Sydney corporate group looking for a valuable afternoon — they can propose a curated joint event. Equally, the agent might conclude that this client needs a private relationship-building day, and inviting outsiders would make it worse.

Flexibility includes deciding not to add complexity.

You are discovering occasions, not filling a tee sheet

The starting asset is not just a small group of participants. It is that group plus the business’s accumulated relationships, experience and ability to put them together intelligently. The output should be a reasoned proposal: here is the combination, why it fits, what each participant would gain, which past experiences support it, and what we still need to confirm. After the event, record which assumptions proved right.

Chapter 9 runs this homework inside a full engagement walk-through. The doctrine point is simpler: stop using AI to accelerate a ranking you should not have trusted, and start using intelligence to compose occasions that deserve to exist. Graham’s early-stage counsel to delight initial users to an extreme — even acting as if you were consulting for a single user — is the same instinct at smaller scale: composition and attentiveness before automated reach.⁶

Once experiences diverge by design, something still has to stay stable — or the company dissolves into heroics. The next chapter draws that line: standardise the capabilities, not the customer experience.

Personalisation that only changes the wording around an identical package is marketing. Personalisation that changes the actual service is the point.

You do not have to deliver the same thing for everyone. With rigid software that ambition becomes complex branching, or at best templates that are still rigid. With accumulated knowledge and agents that can pull from it, the same underlying capabilities can support different experiences without a separately programmed feature for every variation.

Standardise the capabilities, not the customer experience.

Two classes of compounding

Compare two approaches to the same specimen business.

Scorecards and attendee names can still be useful supporting features. They simply are not the organising idea. The tenth engagement can be better informed than the first even when the underlying tools are largely unchanged — if more of the improvement sits in customer understanding, evidence, relationships and how the agent applies them. External investment writing is already circling the same commercial unit: Bessemer’s AI-native services frame puts it bluntly that AI can deliver the work itself and the outcome is the product.⁸ This book still goes one layer deeper — the experience stakeholders would testify to — but the direction of travel is the same: stop organising the firm around tool features.

Demand-pulled delivery equipment

The architectural consequence of Chapters 3–7 is a sequence, not a product roadmap:

Desired experience → conditions needed → knowledge and actions required → missing capabilities → code only where useful.

Suppose the design calls for carefully composed groups. The agent may need a one-off comparison script. Perhaps everyone needs a small event-specific information page. Perhaps a short private briefing document is better than any new interface. None of those needs automatically justifies a permanent matching module, networking platform or guest-intelligence product.

Keep the capability when reuse warrants it. Retire event-specific machinery when it no longer serves. Preserve the records needed for continuing commitments and appropriate learning. You are standardising the ability to deliver — not insisting on identical events or building a separate permanent application for every client.

Why a software beta cannot test this business

One paragraph, because the deeper architecture belongs elsewhere: when the offer is still organised around an application that customers must operate, a beta mostly answers whether the application works. It does not answer whether the company can attract the right customers with a proposition they value, remove real effort, earn payment and return, and reduce founder dependence. The filter that puts software in the middle of the offer is why release vocabulary feels like progress. It is also why release vocabulary is the wrong proof object for an experience-led company.

The practical test for any proposed permanent module is the same as Chapter 3’s backwards questions. Name the review line it serves. Name the condition it creates. If you cannot, you are building inventory for a competitor comparison chart. Chapter 9 will show demand-pulled tools appearing inside a real engagement design; Chapter 10 will show what replaces the beta as the company’s proof object.

Doctrine is now in place: the unit, the two jobs, testimonial-back design, compatibility, appropriate attention, abundant expertise, homework, and the capabilities line. Part II puts the method on one engagement and walks it end to end — reviews, conflict, backwards questions, composition, and what evidence the company should expect afterwards.

Everything in this chapter is a hypothetical worked example, labelled so on purpose. It is not a reported client case. The method is real; the specimen is constructed to show the method running.

The brief arrives like this:

That last sentence is already better than most intake forms. It keeps the sponsor question as an outcome-responsibility, not a premature package feature. Working Backwards starts by defining the customer experience before deciding what to build;⁴ this walk-through is that discipline applied to one engagement and every stakeholder who can make it fail.

Write the reviews before you arrange anything

Clear the inherited assumptions. There is no requirement to reproduce a competitor’s event app. There is a requirement to earn reviews that can be true together.

Read them as a set. Already you can see the load-bearing constraints: existing-customer retention, not prospecting theatre; inclusion without surveillance; host free to host; venue not used as a shock absorber; company learning that does not burn the client.

The compatibility conflict

Homework surfaces a candidate sponsor. Their audience profile fits the host’s industry. They are willing to contribute budget. On a feature checklist, they look green.

An experienced practitioner — or an agent proposing and an expert challenging — rejects them:

“Their audience fits, but their presence would make this feel like a sales event. That would undermine what the client is trying to achieve.”

That is the Chapter 4 conflict in living colour. The sponsor review as written cannot be true without damaging the invitee review and the host’s purpose. Compatibility fails.

An alternate compatible design, if the host insisted on offsetting cost, might be a quiet contribution that improves the day without extracting attention — for example underwriting a better briefing experience or a follow-up dinner the host already wanted — with no on-day pitching. In this specimen we take the cleaner path: no sponsor. The point is the test, not the merchandising of sponsorship products.

Work backwards from one line

Take the invitee line that carries the day:

“I was paired with people I genuinely enjoyed talking to.”

1. What must be true?

Participants are grouped by more than handicap or company size. Social energy, conversation preferences, and the host’s relationship goals shape the groupings. At least one person in each group has a natural bridge to the others. Beginners are not thrown into a format that humiliates them. Non-drinking guests have equal social options — asked, not inferred.

2. What do we need to understand?

From the host: who among their customers matters most on this day, what “stronger relationship” would look like afterwards, and any combinations to avoid. From invitees: golfing confidence, dietary and drink preferences (asked directly), whether they want quiet conversation or broader mixing, and one attendee-approved conversation topic if they want one. From prior records: who has enjoyed similar days, who declined for date reasons rather than disinterest, which formats failed before.

3. What must we arrange?

A venue suited to mixed ability and conversation — not the most prestigious club if prestige fights the objective. Groupings drafted, reviewed with the host, adjustable on the day. Short briefing notes for hosts and players: names, roles, one safe topic — not dossiers. On-the-day hosts who can notice a bad pairing and fix it without drama. Follow-up that continues only the conversations people actually wanted.

4. How will we know whether it worked?

Not five stars alone. Specific observations: Did pairings hold or get quietly reshuffled? Did conversations continue after? Did the host spend the afternoon hosting or firefighting? Would they buy the next engagement at the intended rate? Which assumptions about combinations were wrong? Capture the answers as commercial evidence and reusable judgement — with permission where personal.

Same-budget choices

Venue and catering stay inside the ordinary budget. No chauffeurs. No luxury escalation financed by imaginary pipeline. The improvement budget is cognitive: research, matching, briefing, host preparation, follow-through. If the day earns a higher fee or a future sponsor that passes the compatibility test, hospitality can rise later from economics that already work.

Homework composition

Still hypothetical.

Three separate facts sit in the company’s knowledge:

• A past client liked meeting other businesses and asked about another event.
• A club contact wants introductions to suitable corporate groups.
• Several of the host’s customers have previously enjoyed smaller, quieter formats.

For this objective — strengthen existing relationships — the composition decision is: keep the day private to the host’s customers. Do not import the past client’s networking preference into a retention day. Note the club contact for a different engagement where introductions are the purpose. The opportunity to combine facts is real; forcing the combination would fail the host and invitee reviews.

You are not finding customers for an event. You are discovering whether an event deserves to exist in this shape.

What code is pulled — and what is not

Working backwards from the conditions above, the company might need:

• A one-off comparison to explore grouping options.
• A short private briefing page for the day.
• A checklist for on-the-day hosts.
• A structured place to record outcomes and lessons.

None of that requires a permanent matching product, a sponsorship configuration module, or a networking platform. If a small tool helps once, build it for the engagement. If it helps repeatedly, promote it into a capability. If it does not, retire it. Demand-pulled equipment — not a roadmap looking for justification.

What the company should hold afterwards

The imagined review remains a design target. The actual response is the evidence. If the host says the pairings were fine but the afternoon still felt like work, that contradiction is gold. Fix the next design; do not paper it with a testimonial request.

The same method without golf

In a business setting a remarkable experience might be less uncertainty, fewer handoffs, a resolved problem, or confidence that someone is holding the whole responsibility. Swap the specimen and keep the spine:

• Write the reviews for every party who can make the engagement fail.
• Force compatibility on the page.
• Work backwards into what must be true, understood, arranged and evidenced.
• Hold hospitality — or project theatrics — fixed while you test cognitive attention.
• Pull tools only where the conditions need them.
• Return with commercial evidence and reusable judgement.

Part III turns from one engagement to the company that must learn from many: how to stop mistaking betas for business tests, how to price early learning honestly, how to hire expertise so the system improves, and how to keep four answers separate so “experience” never goes vague.

A founder testing his beta on free users is answering a coherent set of questions. Does registration work? Did people understand the interface? Which features did they request? What goes into version 2.0? How many bugs got fixed?

He is testing his software. He is not testing his business.

Test the company, not the beta.

“Companies, not products” means the company must be the unit of experimentation and improvement. A software beta can contribute. It is not a substitute.

Two question lists

The software still needs to work. The commercial hypothesis is larger than the software.

What the feedback becomes

The founder-dependent loop looks like this: give access → receive feature requests → founder interprets them → vibe-code changes → repair interactions → release another beta.

That can improve the application while leaving the company’s judgement concentrated in one person. Every unfamiliar request risks becoming another item that must pass through him and become permanent software.

The alternative: deliver an engagement → observe customer and commercial outcomes → retain the evidence → improve knowledge, working methods and agent capabilities → apply them to the next engagement.

Polish is not proof

Steve Blank’s 2026 teaching makes the timing unmistakable. Teams could generate more products than they could validate. They started to believe the product itself was the truth. The abundance of MVPs became, in his phrase, an accidental denial-of-service attack on the search for a repeatable business model.⁹

By June he sharpened it further: a finished-looking product felt like success. Students confused a polished deliverable with understanding stakeholders and with customer validation. They pivoted late because they assumed polish meant product/market fit.⁵

That is the failure mode Chapter 1 opened with, observed in a classroom where generation got cheap. Your company pilot has to refuse the same substitution.

Replace free beta access

Instead of “here is free access to our beta app; tell us what features you’d like,” test something like:

Pick one objective — strengthen existing relationships or introduce relevant prospects — not both by default. Afterwards answer: Did the client get the intended value? What did delivery really cost? Which relationships helped? What should change? Would they buy the next engagement? Retain something operationally useful.

The founder-dependence test is simple: when the next unfamiliar request arrives, can the company’s workers handle more of it using what previous engagements left behind — or does everything still return to one person?

What a company pilot looks like on the calendar

Pick one bounded engagement. Write the stakeholder reviews and run the compatibility test before anyone builds. Deliver the experience at a founding-client rate. Hold a structured review afterwards against the pilot questions in the table above — not against a feature backlog. Write down what the company can now do that it could not do before. Only then decide what, if anything, deserves to become lasting software.

That sequence is slower than spinning another demo. It is also the only sequence that answers whether you have a business.

Early customers can get a better price. That subsidy has rules. The next chapter names them: the new freemium.

Classic freemium subsidises access to a feature set. Use the limited version for free; eventually pay to unlock more software.

The new freemium subsidises early delivery so the company can acquire experience, evidence and reusable capability.

Join an early, lower-priced engagement. Receive a real service. Help the company understand what works. Let that improve its ability to deliver for the next customer — not merely unlock another screen.

Two returns, always

Hands-on learning with early customers has strong precedent. Paul Graham’s advice to do things that do not scale includes intensive manual recruitment and service; how well you are doing a few months later, he argues, depends more on how happy you made those early users than on how many there were of them.⁶ The extension here is to make the resulting knowledge usable by the operating system: not merely something the founder learnt, but something future workers can retrieve and apply.

That is why a carefully selected early client can be valuable even at a reduced margin. The learning has to be worth the subsidy.

Cost it fully

Record the full cost of the founding engagement — including founder time. Soft labour that “doesn’t count” is how underpricing becomes invisible. If the only way the day works is a founder quietly doing all the hard thinking again, you do not yet have a capability return. You have a heroics return.

Make the early offer bounded. Price toward the intended commercial rate. Test willingness to buy at that rate. Free usage cannot, by itself, answer the willingness-to-pay question. A second engagement that still requires the same subsidy without new transferable capability is a signal to stop, not a reason to extend the founding programme forever.

What “we learnt a lot” must leave behind

• A sharper client brief template for this class of objective.
• Evidence about venue, format, combinations — with conditions attached.
• Distinctions that changed decisions (as in Chapter 9’s sponsor rejection).
• Tools or briefs that a later worker can reuse without reconstructing the business from scratch.
• An honest note on what did not transfer.

The next engagement then tests whether that retained knowledge actually helps. It might transfer well, need qualification, or should be abandoned. That is stronger evidence of compounding than another software release or another hundred pages of unsorted notes.

A worked bound

Make the founding programme concrete enough that finance cannot argue with the shape even when the numbers are still being measured. Example form:

• Three founding engagements at a stated discount to the intended rate.
• Each fully costed on a single sheet: people time (including founder), model/tool spend, venue pass-through, third-party fees.
• After each: commercial answers and capability artefacts written before the next is sold.
• After three: a go/no-go on continuing the discount. Continuation requires evidence that engagement two started stronger because of engagement one — not because the same person heroically covered the gaps again.

If you cannot write that go/no-go rule before the first discount, you do not have a freemium. You have hope with a price list.

Sometimes the missing ingredient is not another founding discount. It is expertise the company does not yet have. The next chapter inverts the usual hiring move: instead of hiring developers to encode current assumptions, commission practitioners so the company — and its agents — can learn.

It is in reverse: AI is hiring people to learn from — instead of people enlisting software.

The first investment might be discovering what an exceptional engagement business should deliver, with software built only where it helps deliver that. You are not just buying a few great days. You are buying the beginnings of a company that knows how to create them.

Two deliverables per commission

An experienced event designer or corporate relationship specialist gets a brief like this:

Deliverable one is for the customer: a well-designed, well-delivered engagement. Deliverable two is for the company: a better ability to understand, design and deliver the next one. Early low-margin work can be an investment when it purchases reusable capability rather than exceptional effort that must be purchased again next time.

The AI as active apprentice

Do not treat the expert as a voice to record. Have the system participate from the beginning: assemble the brief, research possibilities, propose alternatives, ask about important distinctions, and retain corrections alongside outcomes.

Two rejections teach more than a dozen acceptances.

The assignment is not “copy how this expert has always worked.” It is “understand what makes their choices valuable, then find the best way to deliver that with our capabilities.”

Progression by evidence

1. Expert leads; agents assist — prepare research, maintain records, capture decisions.
2. Agents propose; expert challenges — exposes whether retained knowledge helps on a different client.
3. Agents carry established work; experts handle the genuinely new — improve standards; contribute where human presence matters.

That progression should follow evidence, not an arbitrary event count. Anthropic’s guidance on equipping agents with domain-specific expertise is blunt about the pattern: start with evaluation on representative tasks, observe where the agent struggles, then package missing procedural knowledge into reusable skills rather than trying to prescribe everything up front.¹⁰

Your own test remains decisive: does a later engagement start stronger because the company’s shared capability improved, or because the same expert quietly does all the hard thinking again?

Previously, people bought software to multiply their labour. Here, an AI-native company commissions human expertise to build capability that can be applied across many future engagements.

One last discipline keeps the whole method from dissolving into soft language: four answers every such business owes — value, commitment, price and proof — kept separate on purpose.

Outcome-based selling prices a result. This book fixes the unit of value one layer deeper — at the experience stakeholders would honestly testify to — and refuses to let a single metric do four jobs at once.

Investors will talk about margins and repeat revenue. Operators will talk about tasks completed. Customers will talk about how it felt and whether it worked. Those need not conflict — if you keep the four answers separate on purpose. Sequoia’s services-as-the-new-software thesis puts a related commercial point on the table: for every dollar spent on software, far more is still spent on services, and the winning form may look like a services firm powered by software rather than a tool customers must operate themselves.¹¹ Keep that as orientation. Your four answers still decide whether the experience stays the unit of value.

Field checklist for one engagement

The method travels

Golf made stakeholders visible. The unit claim does not require leisure.

In a business setting a remarkable experience might be less uncertainty before a decision, fewer handoffs across a messy process, a resolved problem someone is actually holding, or confidence that the company understands the client’s situation well enough to notice when this year is not last year. Write the reviews those parties would give. Force compatibility. Work backwards. Prove the company with pilots, not polish.

What this book deliberately left alone

Why software sat in the middle of the firm, and what replaces that bargain architecturally, is a different argument. So are folder-as-relationship designs, opportunity selection for investors, and the mechanics of harness improvement across loops. This book owned one route: fix the unit of value at the experience, then derive design, delivery, measurement, early pricing and early hiring from it. Neighbouring problems stay neighbouring.

The score that matters

The experience is the target. The agents are the delivery capability. Accumulated judgement is the compounding asset. Code is something the company uses along the way.

When cognition is abundant, the scarce design move is choosing the right unit — then insisting that every stakeholder review you would be proud to earn can be true together.

Stop scoring the photocopying. Design backwards from the testimonial. Let it pull the work, the code and the proof.

Then go run one engagement. The method only counts when the actual responses — free to contradict your design targets — change what you do next.