Written by
The Bit Laboratory
Filed under
AI Strategy
Every product team we meet has an AI list. It is usually long, usually impressive, and usually organised around what models can do rather than what the business needs to happen. That ordering is the reason so much AI work stalls somewhere between a convincing demo and a line item nobody renews.
The engagements that create durable value start from a different question. Not what can the model do, but which decision inside this product is slow, expensive, or inconsistent today? Answer that honestly and the technical scope tends to shrink while the impact grows.
Start with the decision, not the capability
A decision has an owner, an input, a deadline, and a cost when it goes wrong. Those four properties give you everything you need to design an intelligent system: who it serves, what context it must retrieve, how fast it must respond, and how much accuracy you have to earn before anyone will trust it.
- /Which decision is being made, and by whom?
- /What information does that person gather before deciding?
- /How long does gathering take, and how often is it repeated?
- /What happens downstream when the decision is wrong?
When a team can answer those four questions in a sentence each, the AI surface almost designs itself. When they cannot, no amount of model quality will rescue the feature.
Retrieval beats reasoning more often than you think
In production work, the majority of perceived intelligence comes from context rather than cleverness. Clean, current, well-scoped data placed in front of a competent model outperforms an elaborate reasoning chain running on stale or ambiguous inputs. Before investing in orchestration, invest in the boring layer: source of truth, freshness, permissions, and structure.
Intelligence is rarely the constraint. Context, trust, and workflow placement almost always are.
Design for verification, not magic
Professionals adopt tools they can audit. That means showing sources, exposing confidence, allowing correction, and making the human contribution visible in the final artifact. A system that is right eighty percent of the time and transparent about the remainder gets used. A system that is right ninety percent of the time and opaque gets abandoned after the first surprising answer.
Scope the smallest useful version
The first release of an intelligent feature should do one thing that a specific person will notice within a week. A single summarisation step inside an existing screen, a draft that saves twenty minutes, a classification that removes a manual triage queue. Narrow scope is what makes evaluation possible, and evaluation is what earns the budget for the next step.
Ambitious programmes are usually a sequence of these small wins, sequenced so each one produces the data and the trust the next one depends on. Programmes that start with the full autonomous vision tend to spend their first two quarters building infrastructure nobody has yet validated a use for.
Measure the workflow, not the model
Model benchmarks tell you very little about whether a product is working. Time to first useful output, revision rate, task completion, and the proportion of work that reaches the end of the pipeline without escalation are far better signals. They also translate cleanly into the language of the people funding the work.
- /Time from question to a usable answer
- /How often the output is edited before it is accepted
- /Share of tasks completed without human escalation
- /Cost per completed task, tracked against the manual baseline
Plan for the failure cases before launch
Every intelligent system will be wrong in public at some point. The products that survive that moment are the ones where the wrong answer was cheap to catch and easy to correct: a review step on anything irreversible, a clear audit trail, a route back to a human, and language in the interface that never overstates certainty. Designing that path is not pessimism. It is what allows the useful eighty percent to ship at all.
AI is not a feature category. It is a way of shortening the distance between a question and a defensible answer. Treat it that way and the roadmap becomes shorter, sharper, and considerably easier to justify.
