Lead · 7 chapters
Problem selection
Which business problems are genuinely LLM-shaped, using verifiability (5.7) as the primary filter, and killing the ones that aren't
Choosing the wrong problem can make excellent model and platform work economically useless; a credible rejection is often the highest-value engineering outcome.
Read these first
What you will know
Triage three business problems and record which are LLM-shaped and why
The fit depends on ambiguity, language-heavy inputs, and acceptable error handling rather than on whether an LLM can produce an output.
Use verifiability as the first filter
If correctness cannot be checked against a rubric, source, workflow state, or human decision, improvements become difficult to measure and bound.
Kill a proposed AI project with a stated reason
A useful rejection identifies the blocking condition, such as unbounded error cost, weak demand, or a simpler tool that performs better.
Compare an LLM proposal with a deterministic or workflow alternative using stated cost, latency, and error assumptions
The attractive demo may lose once retries, review time, integration work, and tail failures are included.
Redirect enthusiasm toward the problem next door that will work
Preserving the underlying business goal while narrowing scope often turns an untestable promise into a bounded, verifiable workflow.
Chapters
- 1
An answer nobody can check cannot be improved
Verifiability comes first because it decides whether the rest of the work is even possible: evals, regression tests, and any claim that version two beats version one. A generated SQL query can be executed against a reference result and checked at scale, while a strategy memo offers no such handle. Sort candidate outputs by what they check against: a rubric, a source passage, workflow state, or a decision a human already makes.
- 2
Ambiguity and error tolerance decide fit, not model capability
Every proposal passes the test of whether a model can produce plausible output, so that test separates nothing. Fit turns on two other properties: how ambiguous and language-heavy the input is, and how much error the output tolerates. You will triage four candidates on those grounds, including support email routed into nine queues that humans already misroute 6% of the time, and record which are LLM-shaped.
- 3
Errors you cannot detect are the ones that end a project
A rejection is only useful when it names the blocking condition. The strongest one is undetectability: 500 wrong outputs a week that nobody notices degrade a business process invisibly, and no amount of model work will surface them. Beside it sit unbounded error cost, demand nobody has evidenced, and a simpler tool that already performs better. You will write a rejection a sponsor can act on.
- 4
Rules first with the model on the residual changes the arithmetic
Two million documents a month at $0.0008 each and 96% accuracy looks like an easy win over rules at 91% and no marginal cost, but neither figure is the comparison. The real question is whether rules absorb the easy majority and the model only sees what is left, reaching 96% at a fraction of the spend. Latency changes shape in the same move: a rules layer answers in microseconds and the residual routed to a model does not, so the blended p50 and the p99 are two different arguments. Retries, review time, integration work and tail failures belong in the same total.
- 5
Keep the business goal, narrow the scope until it is checkable
"Read every ticket and tell us what to build" has no verifier and no owner of correctness. The version next door does: cluster and label tickets into a maintained taxonomy, publish volumes and trends, and let humans read the ranking. This chapter practises the move on three proposals, including security alert triage, weekly executive summaries from Jira, and contract entitlement questions, and shows which survive narrowing.
- 6
Three days should buy evidence, and a demo is not evidence
Asked for a yes, a no, or something else on an RFP drafting request within seventy-two hours, a demo built on two RFPs answers the wrong question. Spend the time locating the verifier, sizing volume and error cost, and testing the hardest inputs you can find. The same discipline handles a parity request against a competitor's demo, and leaves you a position to hold when the decision goes against you.
- 7
Being overruled is a position to hold, not a defeat to absorb
The claim that a competitor's feature is a demo rather than a product is unfalsifiable until you have used it yourself and found the inputs where it breaks, so collect that before the meeting rather than after. When the rejection loses anyway, four moves remain: narrow the mandate to the slice that has a verifier, attach precommitted review points and a spend ceiling so the decision stays revisitable, instrument the thing so its failure is legible rather than deniable, and record the disagreement as a record instead of a protest. Losing the argument is common enough that having none of these ready is the more expensive mistake.
External resources
- What We've Learned From A Year of Building with LLMsapplied-llms.org
Field report on which LLM problems pay off and which to refuse.
- A Field Guide to Rapidly Improving AI Productshamel.dev
A concrete process for finding whether your use case is tractable.
- The First Rule of Machine Learning: Start without Machine Learningeugeneyan.com
The baseline argument for killing problems that don't need a model.
- Knowing When Not to Use AI: AI Agents vs Rules vs MLIBM Technology
A decision tree for rules vs classic ML vs LLM on a given problem.