Prototype before business case: build a rough version people can try
Before you write the business case for an AI idea, build a rough working version and watch someone try to use it. Building it shows you what the slides left out, and you get a real answer in days instead of months.
If your AI idea has been sitting in scoping meetings for a month, this is about getting it in front of real users instead. The question on the table is usually the same one. Do we write the business case first, or do we build something.
Our answer, from running these sessions with banks and insurers since 2015, is to prototype before business case. Build a rough working version, put it in front of five people who would actually use it, then write the business case with what you learned.
Below: what the stuck version looks like, what to build instead, how rough is rough enough, and what number to measure first.
The scoping meeting that keeps getting rebooked
It usually goes like this. Someone writes the idea up in a PowerPoint. Ten slides, a rough cost, a paragraph about the benefit. The meeting spends its time on the wording of the benefit paragraph, because nobody in the room can settle it. The next meeting is booked. Two more people are invited. The slides get longer.
Nothing wrong with anyone in that room. The problem is that the questions being argued about cannot be answered from slides. Will branch staff trust the output. Will the model get the customer's name wrong when the middle name is on the form. How many steps does the person doing this today actually take. Those answers live in the work, not in the estimate.
So the scoping carries on, the calendar fills, and after six weeks there is still nothing anybody outside the room has touched.
Build the rough version first
A prototype here does not mean production code. It means a working thing, on a screen, that one person can attempt a real task in. A prompt wired to a form. A single screen with the three fields that matter and a fake back end. Enough that someone can try it and get an answer out, right or wrong.
Building it takes hours, not a quarter. And the build itself does the work the meeting could not. You find out the field you assumed exists is stored in two systems. You find out the prompt needs the account type to be any use. You find out the output is fine but nobody knows what to do with it next.
Building the thing shows you what the slides left out.
Five real users, watched, not surveyed
Once the rough version exists, book five people who do the task for a living. Branch staff, claims processors, whoever it is. Give them a real case, not a demo script, and watch them use it. Do not explain. Do not rescue them when they pause.
Five is enough. The same problems keep showing up after two or three people, and by then you know what to fix.
What you are looking for is the moment they stop. Where they stop is the thing your business case has to account for. If four of the five paste the output into an email and then rewrite it by hand, your feature saved nobody anything and you now know that before you spent the budget.
If it works, you have something better than a benefit paragraph. You have a short video of a person doing the task faster, and you can show it to your boss.
Get the before number while you still can
The most common gap we see is no baseline. Someone asks whether the pilot worked and the honest answer is a shrug, because nobody wrote down how long the old way took.
Do it while the prototype is still rough. Pick one number. Turnaround time on the flow, steps to complete, percentage of people who finish without asking for help. Measure it on the current process, with a stopwatch if you have to, across ten real cases.
That number then does two jobs. It sizes the gap, so you know whether this is worth building at all. And it gives you the before, so the after means something.
A series of five day design sprints with a large insurer put customer facing web journeys live in four weeks where the old route took twenty six or more. Completion rates on the new journeys went up 80 per cent and the previous drop-off points disappeared. That claim only holds up because the client had measured the old journeys first.
Write the business case last, and make it shorter
By this point most of the business case is already written, and it is shorter. You are not arguing about whether people will use it. You have watched five of them try. You are not estimating the saving. You have the before number and the after number from the prototype sessions.
What you are asking for is also smaller and easier to approve. You are asking to improve a rough version that already exists and already does part of the task, not to fund a new platform.
The usual objection is that finance will not fund a build without a case. Fair. But a rough version can be built with the tools your team already has, before anyone signs off budget. The expensive commitment comes once you have the evidence.
The design sprint we ran with Meralco runs the same steps in five days, if you want to see it done as a workshop.
What to do this week
- Pick the single task your AI idea is meant to help with, and name the one number it should move.
- Time the current way across ten real cases. Write the number down before you build anything.
- Build a rough working version of the idea. One screen, one task, fake data is fine.
- Sit with five people who do the task and watch them try it. Say nothing while they work.
- Rewrite the business case around what you saw, including the parts that did not work.
More on AI prototyping
- Prototype or production build: which to commission next
- What building an AI feature with us involves and how long it takes
- Instead of buying AI licences for everyone, train one real task first
- What a custom workshop is and how we build one with your team
- What it means when On-Off Group builds software with your team
- Everything on AI prototyping
Questions people ask
Why not just write the business case first?
Most people arrive with the idea written up in a PowerPoint, and once they start building, the slides turn out to be wrong. A rough version tests the idea against a real person instead of an assumption.
How rough is rough enough?
Rough enough for someone to try the task it is meant to help with. If they can use it and you can watch what happens, it has done its job.
What do I show my boss afterwards?
A working thing someone used, plus what changed. Take a baseline number before the pilot, like turnaround time on the current flow, so you can say whether it worked instead of shrugging.
Where can I see more of this work?
More workshop scripts, and the projects they came from, are at onoffgroup.com.
On-Off Group trains teams, tests products with real customers, finds where a transformation has stalled and builds what gets it moving, for banks, insurers and enterprises in the Philippines, since 2015. How we help with ai prototyping.
