Most AI feature requests arrive as a platform, not a workflow: "add AI to the dashboard." That sentence has no scope, no success metric, and no obvious first sprint. Our job before any prompt gets written is to turn it into one workflow, one measurable result, and a list of things we are explicitly not building yet.
Start with one workflow
We ask clients to describe the single worst hour of somebody's week — the ticket triage that takes forty minutes, the report that gets copy-pasted between three tools, the support reply that is 90% the same every time. That hour is the workflow. It is small enough to ship in a few weeks, and specific enough that we can tell, honestly, whether the feature worked.
"Add AI to the dashboard" becomes "cut ticket triage time from forty minutes to under ten, for the support lead, on the fifteen most common ticket types." That is a spec. It has an owner, a baseline, and a number to hit.
The measurable result
Before we touch a model, we agree on how success gets measured, and who measures it. Usually that is a before/after time study on a sample of real cases, not a demo. A demo can always be made to look good with a cherry-picked input. A time study on last month's actual tickets cannot.
Baseline: 42 tickets/day, avg 6.5 min triage each = ~4.6 hrs/day
Target: same volume, avg <2 min triage each = ~1.4 hrs/day
Guardrail: false-priority rate must stay under 3%That guardrail line matters as much as the target. An AI feature that saves time but silently misroutes 15% of urgent tickets is not a win — it is a new, quieter failure mode. We scope the guardrail metric alongside the speed metric from day one.
What we refuse to build first
Every AI scope has a second half — the version where it also drafts replies, also summarizes threads, also flags sentiment. We write that list down and refuse to build any of it in v1. Not because it is a bad idea, but because shipping five unproven things at once means that when something goes wrong, nobody can tell which of the five caused it.
- v1 does the one workflow, measured against a real baseline.
- v2 candidates go on a written list, not into the sprint.
- Nothing user-facing ships without a fallback to the old manual path.
After launch
The measurable result from week one becomes the thing we check monthly, not the thing we mention in the launch email and never look at again. Models drift, ticket mixes change, and a feature that hit its target in June can quietly miss it by October. We build the review into the retainer, not as an afterthought.
Found this useful?
Share it with someone who is planning a build.
