Day 5 · Distribution is the moat

By Karthik Nagapuri · 2026-09-18 · Draper Founder Program #2

Peer demos, a civil servant on selling to government, a health-AI advisor on why products are no longer moats, and an investor who said the real question is not "where can I fail?" but "what can I do first?"

Friday was the longest day of the first week, and it felt less like a programme day than a working day that happened to have speakers in it. We started with founders showing each other half-finished products, spent the middle of the day with a man who has built software used by every taxpayer in the country, and ended it pitching to people who were kind enough to be blunt. Reading the transcripts back, one idea keeps surfacing in different accents: the product is not the hard part any more. Getting it into someone's hands, in a way they will pay for and keep using, is the whole game.

This chapter is organised around the lessons rather than the clock, but I have kept the stories, because the stories are what made the lessons stick. If you are a student thinking about starting something, a first-time founder, or an operator weighing the jump, almost all of this travels to your sector.

Demo to your peers before you demo to buyers

The morning was informal. A handful of founders took turns putting their screens on the projector and letting the rest of the room tear into what they saw. I like this format more than any lecture, because the feedback comes from people fighting the same fight with no reason to be polite, and because it is cheap. A room of peers costs you nothing but a little pride, and it surfaces the obvious objections before a customer or investor does.

If your programme, co-working space or college does not run a session like this, run one yourself. Five founders, one projector, ten minutes each, and a rule that every piece of feedback must be specific.

The hook is the product

A fellow founder demoed an AI video studio: version control for media ("GitHub for media", as he put it), automatic shot detection, face tracking, speaker identification, and a movie-maker flow where you design a character and a voice separately and then reuse that persona across a whole project broken into chapters and scenes. It was the first time he had shown it outside his own team, and he said so, which made the room lean in.

Two things he said are useful to any founder who has to make demo or launch videos, which is every founder:

• Most of the work happens before generation. Record your screen, record the real product in hand, record a human face, and get the storyline right. He reckoned those steps are most of the job, whatever tools you use afterwards.
• The hook is the video. On Instagram or LinkedIn, the opening seconds decide everything. "It is not even the rest of the video, to be honest."

He was also honest about his own moat. Model access and routing are things everyone is building; what he thinks differentiates him is the workflow on top, the scene-level controls and the consistency tricks. That kind of honesty, naming which part of your product anyone could copy, came back later in the day in a much harsher form.

Content without a content team

Another founder showed an open-source tool that generates a content calendar in your own tone: it learns about your company, has platform-specific prompting for LinkedIn, X and Instagram, and runs locally with whatever model you plug in. Someone else described a lower-tech version that works for them: reverse-engineer your own storytelling style into a saved prompt or a custom assistant, then give it a topic each week and edit what comes back.

The honest reason, in his words: "I don't have the time to write and post on every platform." Neither do most founders. The lesson is not "use this tool". It is that consistency beats brilliance for founder-led content, and anything that lowers the cost of showing up every week is worth an afternoon to set up.

Show the ladder, not step 100

Then came a deep-tech founder working on continual learning: models that keep learning after deployment instead of having frozen weights with a small adapter bolted on. The idea is vertical and small, models that sit on a device and learn one user's patterns, rather than competing with frontier labs.

The technical content was interesting. The feedback he got was more useful, because it applies to every technical founder in every room, including me. In one conversation he had mentioned a tiny model he has today and a comparison to a model with trillions of parameters, and the listener could not see how he gets from one to the other.

You have to keep it very simple, so somebody sees step 1, then step 2, then step 3. If you talk about step 100, then somebody is going to question how you are going to go there.

• a fellow founder, giving feedback in the morning session

The fix was to anchor on something the listener already knows. Everyone knows a Tesla gets over-the-air updates; now imagine the car learning from you without waiting for the company to ship one. Everyone has heard of models learning from human feedback; now describe yours as a model that verifies and updates itself. Start from what they already know, then add one rung at a time.

This matters most for deep-tech and research founders, whose instinct is to lead with the most impressive number. The most impressive number is the one your listener trusts least. A good test: can a smart friend outside your field repeat your path back to you, rung by rung, after hearing it once? If not, the ladder is missing rungs, and an investor will notice the gaps before you do.

Sell fear, love or ego, not convenience

The best teaching moment of the morning came during a demo by a team building a wearable that reads deliberate eye and facial movements to control things. The product is genuinely clever. The first use case they showed was pausing a game and switching off a light with your eyes.

One of the more experienced founders in the room turned it into a live experiment. He asked five people: would you spend money just to switch off a light with your eyes? One person, maybe, said yes. "He's your early adopter." Then he changed the question: would you pay to make sure your elderly mother, who lives alone, does not have to get up and walk to a switch, and can call for help if she falls in the bathroom? Every hand went up.

Same device. Same sensors. Completely different sale.

You have to make sure that what you are selling is relatable, is either fearful, or it satisfies the ego. No other thing sells.

• a founder in the morning session

He went further. Scroll Instagram, he said, and you will see hundreds of products; most of them might even be useful, but you do not buy them, because they are not relatable and they are not about something you fear. Useful is not a reason to buy. A reason to buy is something that touches safety, status, or someone you love.

Two more lines from him that every founder should tape to a wall:

• Friends' yeses are worth very little. Friends are kind. Typical marketing conversion is a small single-digit percentage of the people who say nice things. Count what people do, not what they say.
• Always have the product in your hand. Even when you are just talking, hold it. People believe what they can touch. For software founders, the equivalent is having the working thing open on your phone, not a slide of it.

Try this on your own product today. Write down the use case you usually lead with, then ask: is this about convenience, or about fear, love or ego? A B2B founder can do the same thing. "Saves your team two hours a week" is convenience. "Stops you being the manager whose audit failed" is fear. "Makes your department the one the CEO holds up as an example" is ego. The product need not change at all; the sentence does.

Build recall on purpose

A job-platform founder got similar treatment on positioning. His one-liner made him sound like every other job marketplace, and the feedback was pointed: nobody in the room could recall even three competitors afterwards, let alone his difference, so how would anyone remember him?

"You want a high recall value," he said. "Whatever you say, your name stays in my mind." The advice had three steps:

1. Relate first. Name the category people already know, so they can file you somewhere.
2. Differ in one line. Say how you are different in a single sentence a listener could repeat.
3. Engineer recall. A memorable phrase, a small joke, a strong visual, even a slightly odd word. Someone pointed out that the silly things said on the first day of a programme are the ones everyone remembers a week later. Use that.

Hunt for the first objection

When the room turned the lens on our own mini-demo, the most useful thing was hearing, early, the objection we had underweighted. Someone who had spoken to many potential users told us that in our category, privacy is the first thing both sides raise, not a footnote at the end. We had thought about it from the buyer's side more than the end user's, and we changed how we explain the product that week.

Every product has a first objection. For a fintech it might be "is my money safe?", for an edtech "will my child just be on a screen?", for an HR tool "will my manager see this?". The founder's job is to know it before the customer says it, and to answer it in the first minute, not the last.

My co-founder Piyush said something in that session I want every founder to hear: he feels happier when people say no, or say they do not like the product, because that is where the insight is. "If they say the product is good, I'm not getting any improvement." Go into feedback sessions looking for the no.

Design for trust: never guess

Between sessions we did something that is hard to put in a pitch deck and easy to show: a live mock consultation for our own product, which listens to a doctor and patient and produces a structured clinical note. I played a patient with fever and stomach pain after eating street food (a Mysore bonda featured), Piyush played the doctor, and we switched between English, Hindi and a bit of Telugu.

The useful part was the argument afterwards over one field. The medicine dose had not been stated in the conversation, so what should the screen say? We settled on a rule that I think generalises to any product that fills in forms for people: never fill a field the user did not state. If it was not said, the field says "not stated" and asks for confirmation. And instead of a free-text box, offer the handful of options the user picks most often, because an expert who sees the common choices will spot the right one at a glance.

The broader lesson: in any product where a mistake has consequences (health, money, law, safety), trust is built in small, boring design decisions. A confident wrong answer does more damage than an honest blank.

Selling to government: lessons from Vignesh

The formal session of the day was with Vignesh, introduced by the organisers as a civil servant who has spent more than a decade building technology inside government, including work on the GST rollout. He was careful to say he is not an entrepreneur, he builds products inside government, and then gave one of the most practical talks of the week. Even if you never plan to sell to government, the first half is a masterclass in running any product at scale.

An unconventional path into govtech

The introduction was worth hearing on its own, because it is a reminder that careers in technology do not have to follow one track. The person introducing him had known him since school. As a student, Vignesh was one of a small group selected worldwide by the Planetary Society to be at the Jet Propulsion Laboratory when the Spirit and Opportunity rovers went to Mars. He later studied at Stanford, did summer stints at Google and Infosys, worked at Microsoft as a program manager, and then came back to India and joined the civil services, where he has spent roughly twelve years, including work with the GST Council on tax technology, intelligence and research. Along the way he has consulted with a number of startups on how to work with government.

That mix, product management at a big technology company and then a decade on the inside of the state, is exactly why the talk was useful. He could explain both sides of the table.

Zero to one hundred, not zero to one

He opened by reframing the usual startup arc. Founders talk about zero to one, then one to a hundred. In government, he said, "it's not 0 to 1 and then 1 to 100. It's literally 0 to 100." A national system has to work for everyone on the day it launches. Government platforms, he admitted cheerfully, "are not generally very glamorous. You don't have sexy UI, but you do have a large scale", and with that scale comes very little room for error.

Most founders will never face a launch like that, but the mindset transfers. If your customer is a large institution, a bank, a hospital chain or a state department, their tolerance for your "beta" is close to zero. Plan as if you are launching at a hundred, even when your team is sized for one.

Define success so precisely that it hurts

His first general lesson was to define what success means, both for you individually and for your company, before you start optimising anything. He then showed what that looks like in practice, with GST itself: a national deadline and a new website every business in the country would use to register, file, pay and get refunds. From that big picture, a founder's job is to drill down into highly quantifiable success. Not "the site works", but how many signed up, how many filed, how many paid, and, just as importantly, how many failed.

At national scale, even a tiny failure rate is thousands of people who could not register, or a large sum in payments that did not go through. A 99.9 per cent success rate sounds excellent until you multiply the remaining fraction by millions of users. So they measured failures as carefully as successes. "Approach it as an engineer would. Define your key success metrics and then work towards driving those metrics."

For any founder, the practical version is to pair every success metric with its failure twin. Sign-ups next to abandoned sign-ups. Orders next to refunds. Outputs accepted next to outputs the user had to correct. The failure column is where the product improvements are hiding. "These numbers will be different for each of you depending on your startup," he said, but the discipline is the same.

Reinvent, do not just improve

His second point: government has collected taxes for thousands of years, and the default instruction is "don't rewrite everything". But GST was new, which gave them room to rethink basics, like how an invoice is generated and what it tracks. His advice was to look at the assumptions your industry takes for granted and question them from first principles. Doing something slightly better, or the same thing in a different geography, generally will not cut it.

Persevere or pivot, and ignore the sunk cost

He described investing heavily in some early assumptions and then pivoting away from them "without looking at the sunk cost", which, he said, served them well for years afterwards. The hardest call a founder makes is when to stay the course and when to change it, and the advice you get is contradictory by nature: be stubborn, and also be adaptable. Both are right, at different moments. Your job is to know which moment you are in.

Why this is a good moment to sell to government

The second half of the talk turned to building for government as a customer. He noted that the room had founders in defence, cybersecurity and deep tech, all of whom might one day count the state as a client.

His framing of the opportunity was candid. Historically, a lot of government spending on the private sector in India has gone to things like roads and office supplies, not to incubating new technology. In the US, he said, labs work closely with young companies: a startup brings a solution and the lab handholds it through development. India did not really have that structure. That is changing. The defence forces now run annual challenges, departments host hackathons, and the appetite to work with early-stage startups has grown a great deal since he joined service. "It's a very exciting time to be building things for government."

Slow by design

This was the part I had never heard said so plainly. Government is not designed to be agile; it is designed to be stable. Ten people signing off on one thing is not incompetence, it is a deliberate choice to prioritise transparency over speed. So:

• Red tape is there by design. "You can't wish it away. You have to navigate that red tape."
• Winning govtech startups have great product and great hustle. If you do not enjoy navigating process, find the person who does and put them on the team.
• Beware the endless unpaid pilot. He had seen companies run unpaid proofs of concept for four or five years, with heavy custom development, and at the end the government did not buy.
• Once you are in, it is steady. A contracted vendor has a solid base for years, often more stable than a consumer business.

His one-line mantra for all of it:

You have to be very impatient when it comes to your product, move very quickly. But when it comes to expecting results from the government, you have to be extremely patient.

• Vignesh, on selling to government

The cautionary tale behind it: one company ran a four-year pilot and became patient about everything, including the product. The product at the end looked like the product at the start, and they lost. Results in government can take close to a decade, and in that time everyone you worked with will have moved to another post. Your product cannot stand still while you wait.

Where to knock

The question from the room was the one every founder eyeing government asks: where exactly do we knock, at the minister's office, at a decision-maker's desk, or somewhere else? One founder gave national digital health records as an example of a public platform a startup might want to plug into, and asked who the right person would be for that, or for defence, space or real estate.

His answer was that there is no single door: the Government of India, state governments and even foreign governments all have budgets, and working out which one is the toughest part. The practical paths he listed:

• Watch published tenders, RFPs and challenges that even remotely intersect with what you do. When a department wants a private company to build something (his example was an exam management system), it publishes the requirement and invites bids. Defence has its own innovation challenge programme (iDEX), and departments run annual hackathons and challenges that explicitly invite startups.
• Read the incentive clauses. Many procurement rules carry startup and MSME-friendly provisions, including a share of spending reserved for small enterprises; he told the story of a small Hyderabad vendor that got into a defence supply chain that way. These clauses are drafted into RFPs precisely so that government ends up doing business with companies like yours.
• Use the directories. Unlike a private company, who is who in government is public. You can find the right officer.
• Senior buy-in is not a cheque. Even after a senior person says yes, going from yes to money is a long process.
• Pricing can be the innovation. The most successful founders he had seen did free proofs of concept well, then moved to monetisation, and were creative about how they priced.
• Structured buys versus new ideas. Where a need is already defined in a tender, focus on delivering the product very well. Where you are bringing a new idea that nobody has asked for yet, expect to spend a long time persuading many people inside the system that it is worth doing.

Someone asked the uncomfortable question about corruption and shortcuts. His answer was calm: yes, there are corrupt people and companies in and around government; no, you do not have to be corrupt to do business with government, and a lot has changed in recent years. A genuinely strong product can win cleanly. I appreciated that he did not pretend the first half was untrue.

Look for the routine task inside a busy expert's day

After the talk we sat with an advisor who works in health AI and knows high-volume institutions closely. We asked him the question worth asking any experienced person in your target market: from where you sit, what is the lowest-hanging pain, the one a user would pay for without hesitating?

Volume is the enemy

His answer was not what I expected. In a high-volume setting, the problem is often not quality, it is volume. A professional with a huge queue cannot afford even two extra minutes per case on routine work. So look inside the expert's day for the routine steps a machine can do. His example was intake: staff are already trained on a flowchart of questions ("Why are you here today? Routine check-up or a complaint?"). "There's some algorithm. That is a very typical LLM use case."

The general move works in any profession. A lawyer's first client call, an accountant's document checklist, a teacher's attendance and homework check: wherever a trained person follows a fixed script, there is a wedge for software.

The customer who never comes back

In large for-profit institutions, the pain shifts to getting full value from each customer, and a big part of that is follow-up. People are told to come back or do the next step, and they do not, because nobody explained it clearly or they felt fine. His suggestion was an agent that patiently answers every question after the visit, on WhatsApp, because nobody wants another app, and whose goal is the customer's outcome and the business's outcome together, since in these cases they overlap. He was firm that the messaging should always lead with the customer's outcome.

Champion metrics

His most practical instruction: before any pilot, define ten to fifteen quantifiable numbers, measure them before and after, and let the ones that move become your champion metrics for every future sale. "Look, before we came in, this is what you did."

He also warned against the thing every early team is tempted to do: solve every problem. A solo practitioner, a large chain, a nonprofit and a mid-size institution all optimise for different things. Understand what each is trying to drive, then pick one.

Product is not a moat any more

Then he said the hardest thing anyone said to us all day, and he said it kindly. If he sat down with a set of AI agents, he could rebuild what we had built in about a week.

"Product alone is no moat," he said, "however nicely you've designed it."

The usual answer is "our moat is data". He told us about a language model his team had trained on organisational data: months of pre-training, mid-training and instruction tuning with a team of people. At the end they threw it away and went back to a stock frontier model, because training on a narrow domain made it lose general reasoning, and the frontier models kept getting better anyway. Training alone will not survive scrutiny as a moat.

What will? Operations and distribution. "Anybody can build this. That's not trying to discourage you, this is giving you the hard reality." Get the product to an acceptable threshold, then knock on doors until your deployments, relationships and workflows are the thing nobody can copy.

When we asked how to do in six months what might once have taken ten years, he said the ten-year era is gone. Tech companies have become like film production houses: you make a hit, and six months later everyone asks what the next one is. "There is no ten years now. There is only six months."

This is worth sitting with if you are a technical founder, because it inverts the instinct. The hours you spend polishing the product feel like progress, and some of them are. But in a world where a competent engineer with agents can reproduce your software quickly, every week you spend not talking to customers is a week in which your one durable advantage is not growing.

Pick a wedge narrow enough to pilot

In the early evening we pitched to a small group and asked them to be harsh. Piyush framed our month well: the mission is to get rejected, because every rejection is feedback, and even a one-degree change in direction matters.

The most useful part of that session, for any founder, was the discipline of stating the wedge in one workflow. Ours was a single moment inside a hospital visit where a patient is advised a next step and often drops out before taking it; our tool would notice that moment and alert the right person before the patient leaves. It is good for the customer, good for the business, and, most importantly, narrow enough to measure in a pilot.

We were also clear about what we were not doing: not rebuilding the systems the customer already runs, not becoming the owner of all their data, but a thin layer that feeds the existing system. For many B2B founders this is the more honest and faster position. You do not have to win the whole stack. You have to own one signal the incumbent cannot get.

The group's hardest question was about retention in early prototypes, and the honest answer taught me something general: early users dropped off not because the idea was wrong but because the output was inconsistent in real, messy environments. Your lab is not their workplace. Test where the noise is.

Piyush closed with a line about expert users that I think applies to any profession:

For you, it's very personal, because you are very sick. You are the forty-first patient he is seeing, and for him it is an ongoing cycle. Find the problems where the doctor actually feels the pain, where he would be willing to pay.

• Dr. Piyush Malik

Swap in "client" and "lawyer", or "student" and "teacher". The customer experiences your problem once; the professional experiences it forty times a day, and only the forty-times pains are worth paying for.

When an expert says "nice to have"

Late in the day we met a senior doctor who advises on AI in healthcare, and showed him a product idea from Piyush's past: a smart pen and specially printed paper that digitises handwriting in real time, so the user does not have to change how they work at all. It is an appealing idea, because so many professionals still work on paper.

He did not go easy on it, and his reasons generalise to any hardware or "invisible" product:

• Another device is a hard sell. He is tired of people arriving with yet another gadget. It has to be meaningful to the people using it, not just clever.
• The hard problem is often software, not hardware. Converting handwriting into correct text is the real challenge, especially specialist vocabulary that models have not seen enough of.
• The unit economics must be tiny, or no customer will pay for it at scale.
• Supplier dependency is a trap. If only a few overseas manufacturers can make your hardware, make sure your contracts let you switch, or someone else can buy the same thing from the same factory.
• Adoption needs a distinct, seamless experience. Right now it was nice to have, not must have.

And then the line that turned the meeting around: when the working software prototype is done, call me, and I will help build a good company. An expert's "no" often contains a conditional "yes". Listen for the condition.

I keep repeating an idea to Piyush that I will repeat here: the one-degree change. When a plane takes off, a one-degree difference in heading lands you in a different country. A single sentence from the right person at the right time can do that to a company.

"Where can I fail?" is the wrong question

The last conversation of the day was with an investor who knew our space well. His read on the business model applies to most B2B software: time saved gets paid. Any incremental time you save a customer, you will get a share of. Two minutes saved per case can mean one more case per hour.

His worry was sharper and just as general. A large premium customer and a small one will value the same product very differently, while your cost to serve both is roughly the same. How the market prices you, he said, you only learn after months of doing it for real. No spreadsheet will tell you in advance.

Then I asked the question I had been asking everyone that week: where can we fail?

"Everywhere, everywhere. I don't think that's the right question to ask. I think the better question to ask is what can you do first?"

So I asked the follow-up: what can we do in the next ten days that would otherwise take six months?

Just go to as many hospitals as you can. There is no substitute for that.

• an investor

Replace "hospitals" with your customers. It echoed the advisor from the afternoon and half the people we met that week: in this era anyone can build, so the difference is selling, distribution and hustle. The research and development can wait a little. The door-knocking cannot.

One more principle we took from the evening: with a large, prestigious customer, you often get one chance. Use big customers to scale, not to test. Test with customers who are generous with second chances, and arrive at the big ones ready.

Apply it to your startup

Friday's lessons came from very different people (founders, a civil servant, a health-AI advisor, a senior doctor, an investor), and they rhymed almost perfectly. Here is how I would turn them into a week of work, whatever you are building.

• Rewrite your lead use case around fear, love or ego, and test both versions on five people each. A hypothetical example: a cybersecurity founder who leads with "automated patching" might instead lead with "you will not be the company in tomorrow's breach headline".
• Draw your ladder from today's product to your five-year vision in three to five rungs, each anchored on something your listener already knows.
• Name your first objection and move its answer into the first minute of your pitch.
• Audit your moat honestly. Assume a strong engineer with agents can copy your software in a week. List what they could not copy: relationships, deployments, workflows embedded in customers' days, a brand with recall.
• Narrow your wedge to one moment, one signal, one action and one metric. If you cannot name the metric, the wedge is not narrow enough yet.
• Sort your customers into "forgiving, for testing" and "prestigious, for scaling". Do not spend your one chance with the second group on something that belongs with the first.
• If government is a buyer, start watching tenders and challenges now, read the startup clauses, and budget for patience on results but none on product.

Resources from the day

Who taught

• Vignesh, civil servant working on tax technology with the GST Council, on building products at national scale and selling to government.
• Fellow founders in the cohort, who ran the morning's peer demos and feedback (kept anonymous here).
• A health-AI advisor, a senior doctor who advises on AI in healthcare, and an investor, in smaller conversations (lessons kept, people anonymised).

Frameworks and ideas named

• Fear, love or ego: the three reasons people actually buy, and the five-person hand-raise test.
• The ladder: start from a known analogy (over-the-air car updates, models learning from human feedback) and add one rung at a time.
• Relate, differ, engineer recall: a three-step positioning check.
• Success metrics paired with failure twins, from the GST rollout.
• Persevere or pivot, ignoring sunk cost; reinvent from first principles rather than doing it "slightly better".
• Impatient with product, patient with results.
• Champion metrics: ten to fifteen numbers measured before and after a pilot.
• One moment, one signal, one action, one metric: a wedge narrow enough to pilot.
• "What can I do first?" instead of "where can I fail?".

Government entry points mentioned

• Published tenders, RFPs and challenges; iDEX for defence innovation; annual departmental hackathons.
• Startup India and MSME incentive clauses in procurement rules.
• Public government directories, for finding the right officer.

Tools and formats mentioned

• AI video and creator tools with version control for media, shot detection and reusable personas.
• An open-source content calendar generator that learns your company's tone and works with the model of your choice (OpenAI, Gemini or others).
• Saved prompts or skills in general-purpose assistants for writing posts in your own voice.
• WhatsApp as the follow-up channel customers already use, instead of another app.

What to take away

• Relatable, fearful, or flattering: merely useful products get nods, not purchases.
• Show the ladder. Start from what the listener knows and add one rung at a time.
• Pair every success metric with its failure twin, and read the failure column first.
• Big institutions launch at zero to a hundred, not zero to one. Plan for their scale and their low tolerance for error.
• Be impatient with your product and patient with results, especially with government.
• For government, watch tenders and challenges, read the incentive clauses, and use public directories to find the right door.
• Product is not a moat. Distribution, deployment and relationships are.
• Find the routine script inside a busy expert's day; that is where software wins first.
• Define champion metrics before a pilot, not after.
• Never guess on the user's behalf where a mistake has consequences.
• An expert's "nice to have" often hides the condition for their "yes".
• Ask "what can I do first?", not "where can I fail?". Then go and see as many customers as you can.

Try this

1. The five-person test. Write your product's use case as a yes/no question ("Would you pay to...?"). Ask five people. Then rewrite it around safety, status or someone they love, and ask five more. Compare the hands.
2. Draw your ladder. On one page, write where your product is today, where you want it in five years, and the three to five rungs in between. If you cannot fill the middle rungs, neither can your investor.
3. The failure column. Next to every metric you track, add its failure twin (sign-ups next to failed sign-ups, outputs accepted next to outputs corrected). Review the failure column first every week for a month.
4. Champion metrics sheet. Before your next pilot or trial, list ten to fifteen numbers you will measure before and after. Circle the two or three you believe will move most. Those are your champion metrics if they do.
5. The one-week copy test. Ask a technical friend how long it would take them, with AI agents, to copy your product. Whatever the answer, write down what they could not copy in that time, and spend the next month making that list longer.
6. Ten days, not six months. Write down one thing that would take six months if done "properly". Then write the scrappy ten-day version, and do it, starting with ten customer conversations this week.