Every AI-assisted feature makes the same trade: it produces output faster, and it hands the human a new job — deciding whether that output is right. Most teams ship having measured only the first half of that trade. Here is the arithmetic, a model you can run against your own feature, and the break-even accuracy it has to clear before it counts as a productivity gain at all.
Sit through enough AI product demos and you notice they all end at the same frame. The output appears. Somebody says "and that took four seconds instead of forty minutes." Everyone nods. The demo stops there — which is precisely where the actual work begins.
Because in the real workflow, the next thing that happens is a human reads the output and tries to decide whether it is true. If it is a status report, they check whether the RAG ratings match reality. If it is a set of user stories, they check whether the acceptance criteria are complete or merely confident. If it is a meeting summary, they check whether the one decision that mattered actually made it in.
That checking step is not overhead you can optimise away with a better prompt. It is the product, from the user's side. And it gets paid on every single item — the ones the model got right as well as the ones it got wrong, because you cannot know which is which until you have looked.
This is the verification tax. It is the reason a feature can be demonstrably faster at generating and still leave the team no better off — sometimes worse. And it is the single most under-specified requirement in AI product work I see, both in the corporate programmes I run and in the product teams I sit with.
Ask a team building an AI-assisted feature what time saving it delivers and you will normally get a figure for generation. Ask them two more questions and it usually goes quiet:
Without those two numbers, "saves four hours a week" is a marketing claim, not a requirement. It cannot be tested, so it cannot be missed, so nobody is accountable when it turns out to be untrue.
Three findings worth holding together. None of them says the models are bad. All of them point at the space between the model and the person who has to use its output.
Research from BetterUp Labs and Stanford Social Media Lab found that 41% of surveyed workers had received AI-generated work that looked finished but lacked substance — "workslop" — costing colleagues close to two hours of rework each time it landed.
BetterUp Labs / Stanford, in HBR, Sep 2025MIT's GenAI Divide: State of AI in Business 2025 reported that 95% of the enterprise GenAI pilots it examined produced no measurable P&L impact, and attributed the gap to flawed workflow integration rather than model capability.
MIT NANDA initiative, 2025In the same BetterUp/Stanford work, 62% of employees reported feeling pressure to produce AI-enhanced output, while only 28% believed it actually improved the quality of decisions.
BetterUp Labs / Stanford, in HBR, Sep 2025Read these as directional, not precise. The 95% figure comes from 52 executive interviews, 153 survey responses and 300 public deployments, and it has been fairly criticised for the leap from that base to a headline percentage. I am not using it as a measurement. I am using it as a signal that points the same way as the rework data and the same way as what product teams describe privately: the gap sits in integration and verification, not in the model. If you want a number for your own feature, you have to measure your own feature — which is what the next section is for.
This is deliberately simple arithmetic. Its value is not sophistication — it is that it forces you to name the two costs teams leave out, and it produces a threshold you can hold a feature to.
| Term | What it is | Who usually measures it |
|---|---|---|
| Tmanual | Minutes for a competent person to do the task unaided. | Rarely measured — usually asserted from memory, and usually overstated. |
| Tgen | Minutes to set up, prompt and generate. Includes gathering the context the model needs. | Always measured. This is the demo number. |
| Treview | Minutes to read the output and decide whether it is trustworthy. Paid on every item. | Almost never measured. |
| Tfix | Minutes to repair or redo an output that failed review. | Almost never measured. |
| a | Acceptance rate — the fraction of outputs that survive review without repair. | Confused with model benchmark accuracy, which is not the same thing. |
The two amber terms are the verification tax. Note where they sit: Treview has no coefficient — it is not discounted by accuracy, because you pay it whether the output is right or wrong. Only the repair cost is scaled by the failure rate.
Set N to zero and solve for a, and you get the number I think belongs in every AI feature's requirements document:
Below a*, the feature costs your users time. Above it, the feature gives time back. If Tgen + Treview already exceeds Tmanual, a* lands above 100% — meaning no achievable accuracy rescues that feature, and the design has to change rather than the model.
Pick a scenario, then drag the numbers to match your own feature. Watch the verdict, and watch how far your acceptance rate is from the break-even line. The preset values are illustrative starting points to argue with — replace them with timings from three real users and the model starts telling you something true.
The short-task trap. A 10-minute task, generation nearly free, review 6 minutes. Even at 88% acceptance it saves half a minute — and needs 83% just to break even.
The dangerous quadrant. Repair costs more than the task itself. At 60% acceptance the feature is underwater — drag acceptance up and watch where it crosses.
Where it genuinely works. Long task, cheap structured review, cheap repair. This one pays at any accuracy. It is the shape worth building first.
Sit with three users. Have each do two items by hand and four with the feature, and time four things separately: context-gathering, generation, review, and repair. You will not get statistical significance and you do not need it — you need to know whether review is 2 minutes or 20, because that single number decides whether the feature is viable. Teams routinely discover their review time is three times what they assumed.
Each lever attacks a specific term. That is the point: once you have the equation, product decisions stop being taste arguments and start being arithmetic arguments.
A general assistant produces output whose correctness is expensive to establish. A bounded feature — "extract the four commitments made in this call, with the timestamp for each" — produces output a user can verify against a source in seconds. Narrow scope is not a limitation you apologise for. It is the mechanism by which review gets cheap.
Cuts TreviewFour labelled fields with a source link on each are faster to verify than four hundred words of fluent prose, even when the prose contains the same information. Structure, provenance, per-field confidence, and a visible diff against the source material all convert a reading task into a checking task. Prose hides errors. Structure exposes them.
Cuts TreviewThe worst repair experience is the one that forces the user to start over: they discard the output, lose their own context, and pay the full manual cost on top of what they already spent. Edit-in-place, regenerate-this-section-only, and never overwriting the user's own draft are not polish. They are the difference between Tfix being 5 minutes and 40.
Cuts Tfix"I could not find this in the documents you gave me" is a good output. A confident, well-formatted, wrong answer is the worst output your feature can produce, and it is expensive twice over — once in the repair, and again in the permanent tax it adds to how carefully users read everything afterwards. Specify an abstain path and treat silent guessing as a defect.
Protects effective a & TreviewAcceptance rate is the only quality number in the equation, and it is not the model's benchmark score — it is the share of your outputs on your inputs that a real user accepts unchanged. Current practice for measuring it is well established: build a golden dataset of roughly 50–200 hand-labelled examples covering your task types, deliberately weighted toward edge cases and adversarial inputs rather than the happy path, and tag each failure with a category — retrieval miss, reasoning error, format violation, safety breach — so the failures aggregate into something you can act on. Then wire it into delivery: a fast heuristic subset on every change, and a full judged run nightly. Feed every production failure back into the set. Teams shipping prompt or model changes without that gate are not moving fast; they are moving blind, because the most common source of quality regressions reaching users is a silent one nobody was testing for.
Raises a — and makes the claim defensibleAn eval suite is also the only artefact that lets you honestly answer a sponsor asking "is it getting better or worse?" Without one, that question has no answer, and the conversation defaults to whoever spoke most recently about a bad output they saw. That is a governance problem long before it is a technical one.
Standard NFRs — performance, security, scalability, availability — still apply unchanged. These are the additional ones, and the reason they get missed is that they have no equivalent in deterministic software. Every row here should be a number or a named behaviour in your requirements document, not an adjective.
| NFR | Why it behaves differently here | What to actually specify |
|---|---|---|
| Acceptance target | Benchmark accuracy is not user acceptance. Only the latter appears in the productivity equation. | Target a ≥ X% measured on named golden dataset v.N, reviewed by role Y |
| Latency budget | Generation is slow and variable, and users abandon before they verify. Perceived latency matters more than total. | p95 time-to-first-token ≤ X s; p95 completion ≤ Y s; streaming required |
| Provenance | The main driver of review cost. Unsourced claims force the user to re-derive everything. | Every factual field carries a source reference resolvable in one click |
| Abstain behaviour | Silence is cheap; a plausible fabrication is expensive. The default must be explicit. | Defined refusal/abstain output when confidence or coverage is below threshold |
| Reproducibility | The same input can give different output. Support, audit and debugging all depend on being able to reconstruct a past result. | Prompt version + model ID + parameters logged per generation, retained N days |
| Regression gate | Quality can degrade with no code change at all — a prompt tweak or a model upgrade is enough. | Deploy blocked if golden-set pass rate falls more than X points below baseline |
| Rollback | You need to revert behaviour without reverting the application. | Previous prompt + model version pinnable and restorable within X minutes |
| Unit cost ceiling | Cost scales with usage in a way traditional features do not. Success can be unaffordable. | Cost per action ≤ ₹X; per-user monthly cap and alert threshold defined |
| Data boundary | Prompts routinely carry the most sensitive context in the system. | What leaves the tenant, retention period, redaction rules, training-use stance |
| Human accountability | Somebody signs the output that reaches a customer, an auditor or a regulator. | Named reviewer role per output class; review recorded, not assumed |
If you already work from the free NFRs Checklist on this site, treat these ten as an AI-specific annexe to it rather than a replacement — the existing performance, security and scalability rows do not change just because a model is involved.
Tick what you can genuinely answer today. Anything unticked is not necessarily a blocker — but it is a claim you are currently making without evidence, and you should know which ones those are before you present the feature as a productivity win.
An AI-assisted feature does not become a productivity product because the output arrives faster. It becomes one when the total time — generate, verify, repair — is reliably lower than doing the work by hand, and when you can prove that with numbers you measured rather than numbers you hoped for. Everything above is scaffolding for that one sentence.
The equation, the levers, the NFR annexe and the launch gate are my own framing, built from project delivery work rather than from any of the sources above. The preset numbers in the interactive model are illustrative and should be replaced with your own measurements before anyone quotes them.
Browse the article map by topic, or scan the full list.
Free · Article index 🎯 ProductMaturity model, weighted tool-selection framework, four governance guardrails and a 90-day rollout roadmap.
₹1,999 · PDF + XLSX 🧭 SchedulingBuild the network diagram yourself, then drag the sliders until the critical path moves.
Free · InteractiveI run this model with product and PMO teams as a working session — your feature, your numbers, your requirements document at the end of it. Also available as a module inside corporate AI-PM workshops.
Book a Session ↗ Get the free NFRs Checklist