Chapter 12

The Smallest Thing Worth Paying For

Vision Is Not a SKU

One of the easiest ways to make a capable product hard to buy is to describe it at the altitude of the company rather than the altitude of the purchase.

The company may be building an AI operating system for agencies, an intelligent platform for professional services, or a unified workspace that eventually replaces five disconnected tools. The vision includes analytics, automation, collaboration, integrations, agents, and a roadmap that ends somewhere near the peaceful elimination of manual work. That may be a perfectly good vision. It is not yet something a buyer can purchase.

I have run into this distinction repeatedly in enterprise AI work. The strategic vision can legitimately be large: connect information across systems, reduce repetitive analysis, keep humans in control of important decisions, and gradually automate more as confidence grows. That picture matters because it tells the technical team what to build toward and shapes architecture, governance, and which capabilities should be reusable. Then somebody has to decide what to do first, and that decision happens at a very different altitude. The first useful implementation may involve one recurring workflow and one specific improvement. Instead of asking whether the organization wants a broad AI platform, the decision becomes whether it is worth using the system to gather the information for this particular workflow, perform a defined analysis, and put the result in front of a human who still decides. The second description sounds less impressive on a strategy slide. It is considerably easier to say yes or no to.

That is what I mean by vision is not a SKU. I use SKU loosely: the identifiable commercial object, metaphorically on the shelf, that a buyer can choose to purchase. A vision answers What could this product eventually become? A sellable unit answers What are you asking this buyer to pay for now? An agency owner is not required to purchase the founder’s direction. That owner might be willing to pay for a much smaller object: take the monthly client-reporting process that consumes several hours of senior time and make the next cycle substantially easier. If that works, the broader platform still exists and the architecture has not been amputated. The founder has simply separated what the company intends to become from what a buyer has enough information to purchase today.

The separation matters even when everything being discussed already exists in the software. You can stop selling the roadmap and still ask the buyer to swallow too much of the current product at once. A mature application might support twelve workflows today, and the breadth that makes it strategically attractive makes the first purchase harder to reason about. Which teams are involved, which workflows change, which systems need access, who owns implementation, what counts as success? Soon the buyer is no longer evaluating one useful change. They are evaluating your entire theory of the future, which is a large burden to place on a first purchase.

Builders resist narrowing because it feels like hiding the sophistication of the product. When you have built something flexible and technically substantial, describing one use case can feel almost dishonest. But there is no commercial virtue in requiring the buyer to purchase every capability at once so that all of the engineering receives equal recognition. The first transaction is not an awards ceremony for the codebase. A product can contain many capabilities while the proposition selects one reason to begin. The strongest first purchase often looks almost disappointingly specific from the founder’s side: one workflow, one class of problem, one result worth obtaining. That specificity does not make the ambition smaller. It creates a place where the ambition can encounter evidence. And once you stop asking the buyer to purchase the vision, the next problem is where to draw the boundary around the thing you are asking them to buy.

Smallest Valuable Outcome

Once you start narrowing an offer, it is possible to become very efficient at removing the reason anyone would pay for it. This is the part of “start small” that gets lost. Small reduces ambiguity, implementation burden, and the number of assumptions that must be true at once. Small is not automatically commercial.

Imagine an application that helps consulting firms prepare client deliverables: gathering source material, organizing it, generating a draft, checking it against requirements, tracking revisions. The founder sensibly decides the first offer should be narrower, and it becomes: automatically rename and organize the source files before the consultant begins. That may work beautifully. It may also save seven minutes. You have created a small outcome, not a small outcome worth paying for. The distinction I care about is smallest valuable outcome, not smallest possible feature. Keep narrowing until the purchase becomes easier to understand, and stop before the result stops mattering.

Value does not live inside the feature. The same improvement can be trivial in one setting and important in another, which is the economic-pain argument from Part II and does not need rebuilding here. The point now is that the first thing you sell must inherit enough importance from the underlying problem to survive being separated from the larger vision. Suppose you have built an application for property-management companies whose long-term product categorizes maintenance requests, detects missing information, routes work, communicates with tenants, and reports across the operation. There are many ways to make that smaller: automated categorization, a dashboard of requests by type, summaries of tenant descriptions. All useful. But suppose the recurring operational problem is that emergency requests sometimes sit too long because tenants describe them vaguely and the request enters the ordinary queue before anyone recognizes that water is currently entering an apartment. Now a narrower outcome has consequence: the product reviews incoming requests, flags those that appear to need immediate attention, explains why, and puts them in front of a human before normal routing continues. It does not solve maintenance operations. It may solve enough, because you can draw a credible line from the outcome to something the buyer already cares about: response time, property damage, tenant experience, escalation risk. That line is what prevents narrowing from becoming trivialization.

So the question is not “What is the least our product can do?” That produces demo features. It is “What is the least we can promise while still changing something important enough that a buyer could rationally spend money to get the change?” Rationally does not mean a financial model proving a 6.4-times return. People buy convenience, confidence, and relief from annoying work all the time, and a $20 utility does not need to rescue a corporation from existential risk. But the expected value has to make sense relative to the cost and effort of the purchase. A $19 self-serve tool can survive on a modest outcome because buying it requires little money, little trust, and no organizational disruption. A $20,000 annual product that needs access to company systems, training, and security review needs a much stronger result. The offer cannot ask for enterprise-grade commitment in exchange for a nicely organized folder. Small is relative to the transaction, and the combination you are usually looking for is narrow scope with substantial consequence.

This also corrects a builder’s habit of confusing completeness with value. We see a product that performs one part of a workflow and think, That is incomplete. The customer may consider that one part the reason the whole workflow is painful. If an analyst spends three hours gathering information and twenty minutes making the judgment, a product that eliminates most of the gathering is highly valuable even though the analyst still decides. If a manager spends half a day discovering which projects are in trouble and ten minutes deciding what to do, surfacing the exceptions may be enough. The commercially meaningful unit is not the complete workflow. It is the smallest intervention that changes enough of the workflow to matter, and no formula identifies that point. You investigate the buyer’s current behavior, the consequence, the alternatives, and the effort the purchase requires, then make a judgment and test it. If buyers understand the narrow outcome and consistently react as though solving it is not worth the money, the slice may simply be too small, and you may need to include another part of the workflow or attach the result to a more important consequence.

Narrowing is not a contest to see how little you can deliver. That matters especially when founders talk about a “first slice,” because the phrase can become permission to offer a weak version of the product. The first slice should be smaller than the vision. It should not feel like the vision after somebody removed all the useful parts.

First Slice Versus Stripped-Down Product

There is a bad version of narrowing that looks almost identical to the good version from inside the backlog. The team removes features, scope shrinks, the first version ships sooner, and everyone agrees they are being disciplined. Then the customer discovers that the one thing they needed was among the items removed.

A stripped-down product is created by subtracting features. A first slice is created by preserving a result. Imagine a company building an AI application for reviewing insurance claims. The long-term system ingests documents, extracts information, compares claims against policy rules, detects inconsistencies, recommends a disposition, drafts correspondence, and maintains an audit trail. The team starts smaller, reasonably, by removing document retrieval, exception handling, policy comparison, and the connection to the claims system. What remains is a screen where an employee pastes claim text and receives an AI-generated summary. Technically that is an MVP. Commercially it may be the least important part of the workflow: the employee still gathers the information, compares it with the policy, decides, documents why, and moves everything into the existing system. The product proves the AI can read a claim. It does not change enough of the work to matter.

Now imagine a different first implementation. The product handles one clearly defined class of claim, ingests the documents already available for that type, extracts the required facts, checks them against a limited set of known rules, identifies missing information, and presents a recommendation with the evidence behind it. Anything outside the defined conditions goes to a human. That system supports fewer claim types, has fewer screens, and is less impressive in a demo built to show the breadth of the architecture. But it completes something. That is the quality I want from a first slice: commercial completeness inside a narrow boundary. Not feature-complete, not fully automated, not ready for every customer; just that the defined buyer can receive the defined outcome without discovering halfway through that the missing pieces are precisely the ones required for the outcome to exist. Builders know the technical version. You can implement ninety percent of a workflow and have nothing usable because the missing ten percent sits on the critical path. Authentication is a small share of most applications by line count, and “everything works except logging in” is not generally treated as a successful release strategy.

Engineers see breadth in capabilities: more integrations, more formats, more workflow coverage. Buyers experience completeness through the job they were trying to get done. Software for an agency’s monthly performance reports that supports only Google Ads can be a sensible boundary if a meaningful group of buyers runs campaigns mainly there and the product takes them from raw data to a report they would otherwise spend hours preparing. Software that supports every advertising platform but omits the client-facing report because report generation is complicated is broader and less buyable. If the customer can complete the job, a narrow product feels surprisingly complete. If they cannot, a broad product feels unfinished.

This matters particularly with AI products, because “human in the loop” can be thoughtful scope control or a polite way of saying the software stops before the difficult part. Human judgment often belongs in the process, and a first slice can be valuable precisely because it gathers evidence, performs repetitive analysis, surfaces exceptions, and leaves the final decision where it belongs. But the handoff has to make sense. If your assistant saves an analyst ten minutes preparing for a task and then requires forty minutes of cleanup because its output cannot be trusted, you have not created a bounded workflow. You have created an intern with unusual electricity costs. The same rule applies to self-serve SaaS: a narrow product can ask the user for setup and judgment, but it cannot outsource so much of the promised outcome back to the customer that the solution becomes another ingredient in the old process.

One practical test is to describe the first slice without mentioning what is missing. Not to hide limitations, which you should not do, but to see whether the slice has a positive identity. “We don’t have team collaboration yet, advanced analytics are coming, and only three integrations are supported” describes absence. “For independent recruiters using Gmail and LinkedIn, the product takes a candidate conversation through follow-up preparation and produces the next-message draft with the relevant context attached” describes a bounded job. The limitations still matter, but they are boundaries around the proposition rather than holes through the middle of it.

This is also why I am cautious about letting minimum viable product answer the commercial question. Viable depends on what you are trying to learn. A technically viable prototype may test whether a workflow can be automated. It may not test whether someone will pay for having it automated. If the question is whether a buyer values the result, the version in front of them needs to produce enough of that result for the response to mean something; otherwise you cannot tell whether the buyer rejected the outcome or rejected finishing most of the work themselves. You do not need the whole product. You need the whole reason to care, inside a smaller boundary. The next question is what to learn from that slice, because a small implementation can be paid for and still teach you almost nothing if the pilot was designed only to prove the software can run.

Pilots That Teach

A pilot can look like progress while producing surprisingly little information. The product gets installed, a few people use it, someone creates a shared document titled Pilot Success Criteria, which is usually a good sign and occasionally an early warning that nobody knows what success means, and at the end everyone agrees the exercise was useful. Then the founder still does not know whether the customer would buy.

Technical teams design pilots around technical uncertainty. Can the integration handle the customer’s data? Can the model handle the documents? Can it run inside the security constraints? Those are legitimate questions, and in enterprise products sometimes necessary ones. But proving the product can work is not the same as learning whether the result matters enough for the buyer to continue, and the first question consumes the second with remarkable ease. Everyone focuses on access issues, field mappings, prompts, and permissions, and when the workflow finally runs with real inputs, the relief feels like success. Technically, perhaps it is. Commercially, you still need to know what changed.

Suppose a finance team pilots an invoice-review application on one category of invoices for four weeks. The software extracts the information, flags unusual items, and presents each for review. At the end the team can answer Can the product process these invoices? Now ask the questions that determine whether the pilot taught you anything about the business. Did reviewers catch problems sooner? Did they stop doing work they used to do manually? Were the flags accurate enough to be trusted? Did employees simply add the pilot to their existing process for four weeks? If the software disappeared tomorrow, would anyone care? And is someone prepared to continue under real commercial terms? A pilot that cannot approach those questions is an extended demonstration, which is fine as long as it is not promoted into evidence it did not produce.

This is why I prefer pilots with an explicit uncertainty attached. Before it begins, I want to know what we do not know and what behavior would resolve it. The uncertainty might be product value: we believe this workflow will save enough analyst time to matter. It might be trust: we believe reviewers will accept the recommendations if the evidence is visible. It might be commercial commitment: we believe the buyer will pay the proposed amount if the agreed result is achieved. Those are different pilots on identical software, and the mistake is letting the pilot become a protected environment where the product accumulates praise without confronting the decision you care about.

Free pilots are especially vulnerable. Removing price is useful when the purpose is to isolate another uncertainty; if you need to learn whether the workflow works at all, a full contract before either side understands the implementation makes little sense. But free removes one of the conditions the business needs to survive. A department will happily join an experiment that costs no budget, employees tolerate setup for something described as temporary, and people can sincerely like the result while remaining entirely undecided about whether it deserves a line item. The pilot was not fake. It tested a world in which the product was free. If willingness to pay is one of the uncertainties, price eventually has to enter the experiment, whether as a paid pilot, an implementation fee, a conditional agreement, or an explicit statement of the post-pilot terms. The structure varies. The principle does not: do not design the pilot so the buyer can complete the entire experience without confronting the condition you most need to understand.

The other common failure is a pilot that is too broad. A founder eager to impress lets the customer test several departments, multiple workflows, and half the roadmap, every week brings another request, and by the end the team has learned many interesting things and still does not know which result made the buyer care. A smaller pilot has a cleaner causal story: one buyer, one recurring problem, one bounded workflow, one expected improvement. That does not mean every pilot should be artificially tiny; a data platform that needs three systems connected before it produces anything should not pretend one connection is a meaningful pilot because one is easier. The boundary should follow the outcome.

Finally, a pilot should have an exit. Not merely an end date. If the agreed result appears, what is the next commercial step? A paid subscription, another workflow, a defined annual agreement? If nobody can answer that before the pilot starts, it can conclude successfully and fall into an organizational void where everyone liked it and nobody owns what happens next. That is how promising pilots become permanent experiments, and another place where builders can stay busy while the commercial question waits politely outside. The best pilots compress uncertainty by exposing something both sides had to imagine to enough reality that the next decision becomes clearer. The boundary should be large enough to produce a meaningful result and small enough that the result still has a clear owner. Once that boundary is set, the next unresolved part of the decision is the number attached to it.