Start with one decision or task that people repeat often, define what "better" means in a number, and map the information it depends on. Choose the model last. Teams that do this ship AI features people actually use; on our Maslow project the result was an 80% reduction in hiring workflow time.
- Name the decision or task before you name the model.
- Map the information that decision depends on, and where it lives today.
- Decide up front where a person stays in the loop.
- Treat permissions, validation and review as product features, not clean-up.
Every few weeks someone asks us to “add AI” to their product. The request is fair. Customers expect it, competitors are announcing it, and the tools have never been easier to reach.
The framing is the problem.
“Add AI” describes a technology, not an outcome. And when the brief is a technology, the project quietly turns into a demo: impressive in a meeting, ignored a month later.
AI is the means. The decision is the brief.
Inside almost every business process there is a judgement someone makes again and again. Is this candidate right for the role? Which of these requests is urgent? What does this medical report actually say? Which technician should take this job?
Those judgements are where AI earns its place. Not because it replaces the person making them, but because it can do the slow part: reading, sorting, summarising, drafting, flagging. The person gets to spend their time on the part that needs a person.
So we start every AI conversation in the same place. Not with a model. With the decision.
What should you ask before building an AI feature?
- What decision or task should get better, and how will we know? Faster, more consistent, fewer errors, less manual effort. Pick one and make it measurable.
- What information does that decision depend on? Documents, conversations, records, history. Where does it live today, and who is allowed to see it?
- Where must a person stay involved? Some steps should be automated end to end. Others should only ever be suggested, with someone approving the result.
If a team can’t answer the first question, no amount of model tuning will save the project. If they can, the rest of the technical choices tend to follow.
The most useful AI feature is often the least visible one: the hour of reading it saves someone before they make a call.
What this looked like for specialist hiring
When we worked on Maslow, the brief wasn’t “AI for recruitment”. It was narrower and more useful: help hiring teams run better specialist interviews, and make the decision afterwards easier to defend.
That shaped everything. Preparation that gives interviewers structure before the call. Guidance during the conversation. A report afterwards built on evidence from the interview rather than memory. Each piece supports the same decision, and the result was an 80% reduction in hiring workflow time.
None of it started with choosing a model.
The unglamorous parts are the product
Here’s what rarely makes it into the demo: permissions, data boundaries, validation, and what happens when the AI is wrong. Who can see which records? What gets logged? When does the system hand over to a person instead of guessing?
We build these in from the first sprint. Bolting them on later is slower, more expensive and, in regulated areas like health, sometimes impossible. It’s also the difference between a feature people trust and one they quietly work around.
Where should a business start with AI?
Look for a workflow where the same judgement gets made dozens of times a week, using information that already exists but takes too long to read. That’s usually your first candidate.
Write down the decision. Write down what “better” means. Then talk about technology.
How to measure the impact
Set a baseline before you change anything, then track the same measures for at least a month afterwards. These are the numbers we use with clients:
| Metric | How to measure it | What good looks like |
|---|---|---|
| Time per task | Average minutes from start to finished output, before and after launch | Falls sharply in the first month |
| Adoption rate | Share of eligible tasks where the AI feature is actually used | Rises week on week, then holds |
| Accuracy or acceptance | Share of AI outputs accepted without major edits | High and stable; dips trigger review |
| Escalation rate | Share of cases handed to a person instead of automated | Matches the human-review rules you set |
| Cost per task | Total model and review cost divided by tasks completed | Lower than the manual baseline |
Frequently asked questions
What is the first step to adding AI to a product?
Name the specific decision or task the AI should improve, and agree on one measure of success, such as time per task or error rate. Choose the model and tools only after that is clear.
How do you measure the ROI of an AI feature?
Compare a baseline from before launch with the same measures after: time per task, adoption rate, acceptance rate of AI outputs, escalations to people, and cost per task. If time and cost fall while acceptance stays high, the feature is paying for itself.
When should a person stay in the loop?
Keep a person approving the result whenever a mistake would be costly, regulated or hard to reverse, such as health, finance or hiring decisions. Fully automate only repetitive, low-risk steps.
Why do AI projects fail?
Most stall because the brief describes a technology ("add AI") rather than an outcome, so nobody can tell whether it worked. Missing permissions, validation and review rules are the second most common cause.
