An alternative to a long build project: test one journey in two weeks

On-Off Group

October 2026

The alternative to a long build project is to take one customer journey, design and test it with real customers in two weeks, then build only what the tests supported. On a series of five-day design sprints for a large insurer, journeys that had taken six months or more were live in four weeks.

You are being asked to commit to a six month build, and you cannot yet prove the thing will work. There is a smaller first step: take one customer journey, design it, put it in front of real customers, and do that in two weeks.

You end up with a tested design, video of customers using it, and a number for how the current version performs. That last number is why you can answer your boss when he asks whether it worked.

You still build. You just know what you are building before the money goes out.

What the long build usually looks like

The scope document is agreed. The vendor has been picked. Other teams are now planning around the release date, and the onboarding flow you wanted to fix sits well down the backlog.

Meanwhile nobody on the project can tell you how long onboarding takes today. Branch staff have a rough idea. Someone once pulled a report. There is no before number, so when the new flow ships there will be no way to say whether it helped.

That is the pattern in most stalled work. Nobody chose badly. The first real contact with a customer happens after the money is spent, so everything written in the slides goes unchallenged until the build is done. By the time the flow is testable, the people who wrote the requirements have moved teams.

Two weeks of design and testing, then build

Pick one journey. Spend a week designing it with the people who own it, including someone from operations and someone from compliance, so the design is not fiction. Spend the second week putting it in front of real customers and fixing what breaks.

This is what a five-day design sprint is for, and it is worth reading what is a design sprint and what you have at the end of it before you plan one, because the output is a tested design and not a strategy.

On a series of these sprints for a large insurer, on customer-facing web journeys, journeys that had previously taken six months or more were designed and tested with customers in two weeks and live in four. That is 26 weeks down to 4. The client measured it. Completion rates on the new journeys rose 80 per cent, and the drop-off points that had been there before were gone.

One journey, not the platform

People will say one journey is too small to bother with. In practice one journey is the size you can actually finish and put a number against.

Pick the one with the most volume and the most complaints. Onboarding, a claim, a card replacement. Something with a clear start, a clear end and a turnaround time you can count in days or minutes.

Widen after. Once one journey is live and you have the before and after numbers, you can argue for the next one using your own customers, not a benchmark from another market. We wrote about that order of work in instead of a platform project, ship one customer journey, measure it, then widen.

Start with the platform and customers see nothing for a long time.

Get the before number in the first week

This is the part that gets skipped, and without it your boss has no reason to believe the new flow helped.

Before the design work starts, write down what the current journey costs a customer. Turnaround time from application to approval. How many customers who start the form finish it. How many calls the branch gets about it per week. Two or three numbers, pulled from whatever you already have, imperfect and dated is fine as long as you write down how you got them.

If the data does not exist, sit five real customers in front of the existing journey and time them. Five is enough to see where people stop. It also gives you video, which travels further in a management meeting than a percentage does.

Then you have a baseline. Four weeks later, the same measure on the new journey either moved or it did not. In the insurer work, the clear number was completion, and it went up 80 per cent. A small number you can explain holds up better than a big one you cannot.

When two weeks of design is the wrong thing to do

This does not fit everything. If the problem is a core system that cannot support the journey at all, two weeks of design will just produce a nicer picture of something you cannot ship. If nobody can name the customer task, start by naming it.

And if the question is bigger than one journey, if you want to know where the bank is losing time across the board, measure that first instead of running a sprint. Instead of hiring a strategy consultant, size the gap in two weeks covers how that is done.

One more warning. If there is an AI feature in the plan, put it on a journey that already works. Adding it to a broken flow automates the failure and makes the numbers harder to read.

What to do this week

Pick one customer journey with high volume and visible complaints, and write down where it starts and ends.
Write down two or three before numbers for it today, including turnaround time, and note how you got them.
If the numbers do not exist, book five real customers to use the current journey on video.
Name the people who must be in the design week: the journey owner, someone from operations, someone from compliance.
Agree with your sponsor, in writing, what number will be compared four weeks after the new journey goes live.

Questions people ask

What counts as one customer journey?
One end to end task a customer is trying to finish, such as onboarding a new account or submitting a claim. Not a platform, not a department, one task with a start and an end.

What do you have at the end of two weeks?
A tested design of the journey, video of real customers using it, and a before number on the current version so you can compare later.

Does this replace the build?
No. It decides what gets built. In the insurer work the journeys still went live, four weeks after the design was tested rather than six months after sign off.

What if the two weeks shows the idea is wrong?
That is the cheapest outcome available. You have spent two weeks instead of two quarters, and you know which part of the journey to change.

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 design sprints.