What Becomes Possible Now?

Open the email screen in any CRM. It was built for one salesperson writing one email at a time, to the accounts worth the time. Put a "draft with AI" button on it and those emails get written faster. The button never asks whether the accounts that got no email at all should get one, because the screen has no place for them.

That is the shape of most first AI products: a summarize button on the ticket, a draft button in the CRM, a chat panel beside every app. They ship quickly, demo well and change surprisingly little.

The other kind of product is harder to see and worth far more. A new capability creates most of its value in work that used to be rationed, sampled or skipped because it cost too much, and has just become cheap, fast or easy enough to do everywhere. To find it, stop looking at your screens and look for thresholds: tasks whose cost, speed or required skill just fell far enough to change who can do them, how often, or for how many cases.

The big motor on the old shaft

There is a century-old version of this mistake. By 1900, American factories had been able to buy electric motors for nearly two decades, and motors still supplied less than 5 percent of the power driving their machines. Productivity didn't surge until the 1920s. A steam factory was built around one large engine turning a long shaft that ran the length of the building, with leather belts dropping power to each machine. Machines went wherever the belts could reach. The obvious first use of electricity was to swap the engine for one large motor and keep the shaft, the belts and the floor plan. That changed little.

The gain came with unit drive: a small motor in each machine. With no shaft to follow, machines could be placed in the order the work moved through them, and buildings could be laid out around the work instead of around the power.

Scroll sideways to see the whole figure

Now map it onto knowledge work. In a steam factory the scarce, expensive thing was power, and the shaft rationed it. In an office the scarce thing has been skilled attention: an analyst's hour, a lawyer's careful read, a reviewer's judgment. Much of every company's workflows, queues and screens is the shaft built to ration that attention. Who gets reviewed, which cases get a second look, which customers get a tailored answer: all of it assumes attention is expensive.

A screen is a record of what used to be expensive.

Adding a model to those screens is the big motor on the old shaft. It makes the rationed work a little faster and leaves the rationing in place.

The analogy breaks in two places. AI capability moves every few months, with the price of a fixed level of performance falling somewhere between 9 and 900 times a year depending on the task, so a redesign aims at a moving target. And rebuilding a software workflow is cheap where rebuilding a factory meant pouring concrete. What stays slow is the organization around it: who reviews, who answers for the result, how people are measured (Where the Saved Time Goes).

Why the bolt-on disappoints

A product team has good reasons to start with a bolt-on: it reaches existing users, is cheap to build and remove, and asks nobody to change how they work. Three things limit it.

It hands the user the hardest part of the job. A chat box asks the person to know what to ask, to phrase it, and to judge the answer. For most tasks the difficulty sits exactly there.

It speeds up a step that wasn't the bottleneck. If drafting a reply takes three minutes of a support case that then waits two days for an approval, a button that saves two minutes leaves the case as slow as before.

It inherits the old screen's assumptions about scarcity. The CRM screen encodes a decision about which work was worth a person's time, and the bolt-on accepts it without noticing.

The better starting point is the job the person is trying to get done (jobs to be done). A support manager's job is knowing her team treats customers correctly and fixing it fast when it doesn't. Framed that way, the question becomes "which part of this job did we never do, because it cost too much?"

Four thresholds

Value from a falling cost tends to arrive in jumps, at the points where a task crosses a line that changes someone's behavior. Four kinds of line account for most of what has moved.

Cost per task. Models read and write in tokens, chunks of text a bit shorter than a word, priced per million. As of October 2026, Anthropic's Claude Sonnet 5.5 costs $2 per million input tokens, so reading a ten-page document once costs about two cents. The threshold that decides a product, though, is the cost of the finished task, including retries, failures and the person who checks the result. That is usually far larger than the token bill.

Speed. When an answer arrives within a conversational turn, a capability can sit inside a live interaction instead of after it. Apple's Live Translation for AirPods, announced in September 2025, lets each person speak normally while the translation plays in the listener's ear. Machine translation is decades old. Translation fast enough to hold a conversation through is a different product.

Skill. When a non-expert can produce work that used to need a specialist, the set of people who can do the task changes, and so does the buyer: a product manager who builds a working prototype, a shop owner who gets a supplier contract explained clause by clause. These products live or die on whether the person can check the result with the skill they already have.

Scale. When the next case costs almost nothing, a task done for a sample can be done for every case. Organizations have built whole functions around sampling, which is why this threshold hides the largest changes.

Checking every call

Take an illustrative contact center, with round numbers. It handles 200,000 calls a year. Its quality team reviews a 2 percent sample, 4,000 calls, checking compliance (was the required disclosure read, was the refund policy applied correctly) and coaching the agents. Each review takes a trained analyst about fifty minutes, roughly $50 of loaded time. The program costs $200,000 a year.

Suppose 1 percent of calls contain a real compliance breach: 2,000 a year. The sample sees about 40 of them. The rest surface later through a complaint or a regulator, or never.

Now redesign the job instead of the screen. A model listens to every call and checks it against the written policy, at a deliberately generous $0.50 a call. It flags about 10 percent of calls for a person, who spends about twenty minutes, $20, confirming or dismissing each flag. Averaged over all calls, that's $2 of human review plus $0.50 of model. Assume the model catches 90 percent of real breaches.

It goes up two and a half times, to $500,000. Everything else changes more. The cost of checking one call falls twentyfold, from $50 to $2.50. The team finds about 1,800 breaches a year instead of 40, forty-five times as many. Holding the old budget flat, it could check 40 percent of calls and find about 720. Doing the old review on every call would have cost $10 million, which is why nobody did.

Scroll sideways to see the whole figure

Three things in this arithmetic apply well beyond call centers.

The product changed category. A sampling program produces an estimate, weeks later, of how compliant the team was. A system that checks every call produces events about this call, this agent and this customer, today: a refund for the customer who was misquoted, coaching on the actual call, evidence for a regulator. That is a different product with a different buyer, compliance and operations rather than the QA lead. It also checks something narrower, named policy items instead of the analyst's judgment of tone, so decide on purpose which parts of the old review you keep.

The model stopped being the constraint early. Make the model ten times cheaper and each check falls only from $2.50 to $2.05. Double the flag rate to 20 percent and it rises to $4.50.

Once the model is cheap, the review rate sets the price of crossing a threshold.

That tells you where to spend the engineering: on the precision of the flags and the speed of the review screen, not on a better model.

Human work grew. The quality team used to spend about 3,300 hours a year on sampled reviews. The new flow needs about 6,700 hours of flag review, plus whoever acts on 1,800 findings. A redesign that crosses a scale threshold usually moves the bottleneck to the people who handle what the system finds. And those people will dismiss about nine flags in ten, which is exactly the setting where reviewers drift toward rubber-stamping (automation bias). A fast way to dismiss, and a periodic check on what got dismissed, are part of the product.

Where thresholds hide

The call example came from one question. Five together cover most of the places worth looking.

What did people stop doing because it cost too much? The help center never translated for smaller markets, the survey comments nobody reads, the research large accounts get and small ones don't. This is latent demand, invisible on paper because nobody writes down what they decided against. Ask what people would do with an extra analyst.

What is done only for the top 1 percent of cases? Legal review above a contract value, due diligence on the largest suppliers, a senior engineer reviewing only critical changes. The test is whether the cases below the line hold value nobody could afford to reach, or were left alone because nothing there matters. Only the first is a product.

What is done once a year that could be done all the time? Annual audits and quarterly supplier reviews are periodic because they're expensive; the risk arrives whenever it likes. When a check costs cents, it can run whenever something changes, and the product becomes monitoring instead of a report.

Where does a person translate between two formats? A conversation into a structured record, an emailed order into the ERP, a policy into a checklist. The input exists, the output format is known, and a person can check one against the other. Clinical notes are the best-studied case: in two randomized trials published in late 2025, AI scribes that listen to a visit and draft the note saved doctors a modest amount of time, and the clearest effect was on how the work felt. The doctor still signs the note, a cheap check because she was in the room.

Can the result be checked cheaply? This last question filters the other four. Capability grows fastest where success is cheap to check, because that's where models can be trained and tested at scale (Why Progress Arrives Unevenly), and the same property decides where products are safe to build. Where checking costs as much as doing, the call-center arithmetic collapses: if every call still needed a person to listen in full, each check would cost $50.50 and no threshold would be crossed at all.

Look for work that was rationed, sampled, postponed or copied by hand, then ask whether the result can be checked cheaply.

Where people go wrong

Two mistakes recur, and one objection deserves a straight answer.

Building on a threshold everyone crosses at once. A threshold crossed by a new model is crossed for every company with an API key, and the lab's own app can make it a default. The test I'd apply: if the model got twice as good tomorrow, would this product get better or become unnecessary (A Product That Improves With the Model)? In the call example, what lasts is everything around the model: the policy encoded as checks, the review screen, the connection to the call platform, the workflow that acts on findings.

Mistaking the demo for the threshold. A demo shows the model can check a call. Whether the threshold is crossed depends on error rates at volume, where small changes in the flag rate move the result by multiples. Usage surprises too: in one of the scribe trials, doctors given the tool used it in about a third of their visits or fewer, a number no demo would have predicted.

"The incumbents will just add it." Often true. When a capability fits inside the incumbent's workflow, pricing and existing buyer, the incumbent adds it and wins on distribution (Distribution Beats the Better Model). Most bolt-ons fall here, which is one more reason not to build a company on one. The objection weakens when the redesign hurts the incumbent's own business. A vendor paid per QA seat cuts its own revenue by selling a product that checks every call with fewer people, which gives a newcomer room to sell what the incumbent can't copy without damage (counter-positioning). The same happens when the buyer changes, when the job spans several systems no single vendor owns, or when the product must answer for its misses. The factory history fits: unit drive was easiest to adopt in a building designed from scratch, and a new entrant has nothing to tear out.

I don't know which thresholds next year's models will cross. The method for finding them doesn't depend on knowing.

What to do

Read your screens as a map of old scarcity. Write down what nobody does today because it costs too much: rationed, top 1 percent, periodic, copied by hand.

Do the arithmetic with the human in it. Cost per finished task, including the review rate and the minutes per review, at the volume you'd actually run. If the model's cost hardly matters to the answer, good: you know where the design effort goes.

Test the idea in a week or two on real cases. Take 50 past cases whose outcomes you know, including the ten ugliest, and write down what counts as correct before looking at any output (Build an Evaluation From Your Own Work). Run the whole flow, model and human review together, and measure what it catches, how often it flags, how long each flag takes and what a finished check costs. If the numbers clear the line, build it. If not, the evaluation set shows which number to work on.

Then test the demand separately. Show the person who would receive the output a week of real results and ask what she would do with them. If nobody has time to act on them, the threshold was real and the product wasn't.

A company's existing screens are a careful record of what used to be scarce. That makes them the best place to look for what no longer is.

Check yourself

Why did early electric motors change so little in factories?

Factories swapped the steam engine for one big motor and kept the shaft, the belts and the floor plan. The gain came with a small motor in each machine and a layout built around the work.

In the call-center example, why does the model's price barely matter?

Making the model ten times cheaper only moves each check from $2.50 to $2.05. The review rate sets the price, so the effort belongs in the precision of the flags and the speed of review.

Why ask whether the result can be checked cheaply?

Where checking costs as much as doing, the arithmetic collapses. If every call still needed a person to listen in full, each check would cost $50.50 and no threshold would be crossed.