Experience Is the Unit: Design the Company Backwards from the Testimonial — and Let It Pull the Work, the Code and the Proof

Imagine an event system that does everything it was asked to do. Every invitation goes out. Every place fills. Every score publishes. Every sponsor message lands on time. The dashboard is green.

And the day is wrong. The group has the wrong people. Beginners feel exposed. Sponsor activity interrupts the conversations that were the point. The host spends the afternoon firefighting instead of hosting.

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

That is the failure mode this method is built to remove. Not buggy software. Not lazy agents. A company organised around the wrong unit.

The unit of production is not the unit of value

My first accounting job was mostly photocopying. 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. Measured by hours, I was a photocopying expert. That was never why the client engaged the firm.

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

Coding is an outsized AI capability because it is verifiable and funded. Anthropic’s own traffic observations put software engineering near half of agentic activity on their public API sample.¹ That explains the visibility. It does not make code the organising score of a company whose customers came for something else.

Swapping “software features” for “agent tasks” does not fix the original mistake. Both keep attention on internal activity. Agents doing tasks are a distraction too — when task completion stands in for whether anyone had a day worth having.

Two jobs: time well saved and time well spent

Pine and Gilmore draw a sharp line. Services compete on time well saved. Experiences compete on time well spent.² Convenience drains drama; it gets people in and out. Experiences ask people to value the time they spend with you.

An AI-native engagement business has both jobs:

• Remove what nobody wants — chasing, reconciling, repeating, coordinating chaos.
• Create what people came for — belonging, useful conversation, a day that advances a real purpose.

A flawless registration app only ever addresses the first. Builders who stop there are polishing the photocopying.

Why this is urgent now

In Steve Blank’s 2026 Stanford Lean LaunchPad teaching, student teams arrived on day one with MVPs that looked like finished products previous classes had taken weeks to build. By week three, product velocity outran learning. Teams began to treat the product itself as the truth.³

His June follow-up is even sharper: 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. “In this class it wasn’t the AI that was hallucinating — it was teams.”⁴

That is the environment founders are building in. Generation got cheap. Validation did not. The method below is how you stop mistaking production for proof.

Companies aren’t software

I sat through a startup pitch that said “software 1.0” and “2.0 beta” about ten times. Companies aren’t software.

A founder testing his beta on free users is answering software questions: Does registration work? Which features were requested? What goes into 2.0? He is not answering company questions: Can we attract the right customers with a proposition they value? Would they pay and return? What can the company now do with less founder intervention?

When software sits in the middle of the offer, a beta mostly tests the software — not the business. That is one reason a software release cannot stand in for a company pilot. (The deeper architecture of that bargain belongs elsewhere. Here it is enough that the feedback object is wrong.)

The Agile principle that “working software is the primary measure of progress” is right for software projects.⁵ It is not a sufficient measure of progress for building a company whose product is a lived engagement.

In the founder-dependent loop, feedback becomes a backlog routed through one person’s vibe-coding. In the company loop, feedback becomes company-owned capability.

Testimonial-back design

Amazon’s Working Backwards method starts by defining the customer experience, then works backwards until the team is clear on what to build.⁶ The extension here is not another product-launch PR/FAQ. It is applying that discipline to every delivered engagement, and to every stakeholder at once, with a compatibility test.

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 — tongue in cheek, but serious: rm -rf the inherited solution assumptions. Keep useful knowledge, relationships 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 a resource, not a requirement.

Step two: define the experience, outcome and review for each participant.

Hypothetical worked example — not a reported event. Labels matter.

The important design test: can those reviews be true together?

A sponsor’s “excellent exposure” must not become a guest’s “I spent the afternoon being sold to.” The host’s “we barely organised anything” must not mean venue staff absorbed all the chaos. The company’s “we learnt a lot” must not excuse an experience nobody would buy again.

Then work backwards from the words. Take “I was paired with people I genuinely enjoyed talking to.” What must be true? What do we need to understand? What must we arrange? How will we know?

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.

Magic is appropriate attention

They feel understood without feeling studied, and looked after without feeling managed. Magical should mean unusually relevant — not unnervingly well informed.

First experiment: same venue budget, same catering, same guest count. How much better through understanding, preparation, matching and timing alone? Extra luxury is financed from credible engagement economics, never from a hypothetical future lead.

Ask preferences directly. Do not infer why someone does not drink from their online history. That is the whole privacy point for this method — proportion, not a compliance chapter.

Paul Graham’s early-stage advice lands in the same place from another angle: early “insanely great” is the experience of being your user; the product is only one component. Over-engaging early customers is not a blind alley — it is often how the feedback loop that makes the offer good gets started.⁷

Homework: capture, augment, compose

The homework that makes the magic possible is not sending invitations faster. It is giving the company enough understanding to decide which people could benefit from being brought together, why this occasion would suit them, and how to make it worthwhile for everyone — sometimes before there is even an event to advertise.

1. Capture what you already know — relationship history, what they enjoyed, appropriate routes to approach.
2. Augment lightly with dated public professional information.
3. Infer fit as hypotheses, not scores.
4. Design combinations, not rankings: if X were invited, would Y come too?

Hypothetical worked example. Three unrelated records — a past client who liked meeting other businesses, a club contact wanting corporate introductions, a sponsor preferring a few relevant conversations — can combine into a curated joint event nobody predefined. Or the right answer is that outsiders would make it worse.

You are not finding customers for an event. You are discovering events that deserve to exist. Preserve contextual evidence: declined-because-of-the-date must not harden into “not interested.”

The abundant-expertise thought experiment

Say you have a billion dollars and a thousand employees, and revenue does not matter — what would you deliver? Then sharpen it:

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

That isolates cognitive richness from hospitality spend. Imagine human excellence. Engineer machine-native delivery. The ideal team is a benchmark for service quality — not a blueprint for the agent org chart.

Cheap intelligence is not literally unlimited money. It cannot conjure a tee time or a yes. That sharpens the investment rule: let AI supply the thinking; spend scarce money on the remaining constraints — an excellent practitioner, trusted relationships, on-the-day hosts.

A premature requirement collapses that space. “Build configurable sponsor packages” has already decided sponsorship is packaged, configured and managed through an interface. “Work out whether a sponsor would improve this event” permits a different answer — including no sponsor. A feature is something the software must do. An outcome-responsibility is something the company must achieve.

Use software to keep the promises. Use intelligence to work out which promises are worth making for this client. Standardise the capabilities, not the customer experience.

Desired experience → conditions needed → knowledge and actions → missing capabilities → code only where useful. That is demand-pulled delivery equipment — not a permanent matching module for every variation.

The new freemium

Not free software with a premium tier. Cheaper early iterations for the company to compound on.

Two returns from every founding engagement:

• Commercial: buyer, objective, willingness to pay, true delivery cost, repeat demand.
• Capability: client understanding, proven approaches, better tools and briefs, examples to check future work against.

“We learnt a lot” is not a licence for indefinite underpricing. Bound the offer. Cost it fully — including founder time. Price toward the intended rate. Test willingness to buy at commercial price; free usage alone cannot answer that.

Afterwards the company should 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? And it should retain something operationally useful — not merely another release note.

AI hires people to learn from

Instead of hiring developers to encode the founder’s current understanding, commission excellent practitioners to expand the company’s understanding — and make that expertise usable by its agents.

Two deliverables per commission: the experience for the customer, and the capability for the company.

The AI should be an active apprentice, not a recorder. It proposes; the expert rejects; the distinction behind the rejection is the asset. “That prestigious club is wrong for this group: half are beginners and the objective is relaxed conversation.” Or: “Their audience fits, but their presence would turn this into a sales event.” Those are distinctions a feature checklist will not teach you.

Anthropic’s engineering guidance on Agent Skills is blunt about the need for composable ways to equip agents with domain-specific expertise, and about starting from evaluation on representative tasks before packaging what is missing.⁸ Evaluating agents that take different valid paths requires judging outcomes and process reasonableness — not only whether prescribed steps were followed.⁹ That is the same lesson as the all-green dashboard, one layer down in the machinery.

Progression by evidence, not event count:

1. Expert leads; agents assist.
2. Agents propose; expert challenges.
3. Agents carry established work; experts handle the genuinely new.

Documented is not the same as transferable. A club relationship or someone’s personal credibility does not move because it was written down.

Four answers so “experience” never goes vague

Keep those four answers separate. Outcome-based selling prices a result; this method fixes the unit of value one layer deeper and refuses to let operational activity stand in for value.

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. The method travels.

What to do next week

1. Pick one real engagement you can bound.
2. Write the review for at least four stakeholders. Run the compatibility test. Resolve one conflict on the page before you touch a backlog.
3. Run the same-budget thought experiment: what improves if only cognitive attention becomes abundant?
4. Replace “here is free beta access” with a founding-client offer that returns commercial evidence and reusable capability.
5. If you hire, commission an expert to expand judgement — two deliverables — not a developer to encode assumptions you have not tested.

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

Stop scoring the photocopying.