What Kills Digital Projects Before They Launch

A credit union launches a new digital loan portal. Online applications triple in the first quarter. The project is declared a success. Six months later, the numbers tell a different story: most applications are incomplete, completed ones required multiple attempts, and branch call volume has gone up, not down — members calling to find out what happened after they submitted.

The portal did exactly what the brief asked. It captured loan applications digitally. Every milestone was met. Every integration worked. The brief was satisfied.

The problem is that no one wrote “help members get loans” into the brief.

Two different briefs produce two different products

Every digital project begins with a brief. The brief defines what the project is for, what success looks like, and what the team is building toward. In financial services, that brief is almost always written around what the institution needs to accomplish.

These are not the same goals. They are not even asking the same questions. When the brief is built around the institution’s goals, the experience gets optimised for the institution’s workflow. A member arrives expecting to accomplish something. They navigate a system designed for something adjacent to that — but not quite it.

What an institution-first brief produces

The tell is in the details. An institution-first brief consistently generates the same set of experience failures, regardless of which institution produces it or what technology underlies it.

A loan journey that collects everything the institution needs to assess the application — but never tells the member whether they are likely to qualify before they invest twenty minutes filling in forms. Most members who would be declined abandon before discovering this. Most who would be approved are unsure enough to abandon too.

An account opening flow that ends at a submission confirmation screen, with no indication of what happens next, what is required from the member, or when the account will be active. The member calls the branch. The branch explains what the screen should have said.

A digital loan calculator that shows repayment amounts accurately but has no path from “I can afford this” to “I want to apply.” The member closes the tab and goes to a competitor.

A self-service portal that requires a phone call to complete. Not because the call centre failed. Because the portal was scoped to automate the form, not to complete the journey.

In each case, the institution built what was specified. The member’s goal was simply never part of the specification.

Why the brief gets written this way

It is not a failure of intent. Most institutions genuinely want to serve their members well, and most digital projects are initiated with that in mind.

The issue is structural. Digital projects in financial services are typically initiated by operations, finance, or technology — teams whose role is to improve institutional efficiency. The impetus is a cost to reduce, a volume to shift, a compliance obligation to meet. The project gets framed in those terms, and technology and product teams inherit the brief and execute against it faithfully.

Member experience enters the process late — usually at the design phase, when the underlying architecture has already been decided, or at UAT, when changing the fundamental logic of a journey carries a cost that projects rarely absorb. By then, the brief has already shaped the product. The member’s goal is an afterthought dressed up as a feature.

Rewriting the brief before the build begins

The fix is not a better design system. It is not more features added to a product built to the wrong specification. It is a different starting question, asked before requirements are written.

Instead of: What does the institution need to accomplish with this product?

Ask: What is the member trying to do, and what would make that feel straightforward?

The answers produce different requirements. A loan product scoped to “help members understand what they qualify for and apply with confidence” will look different from one scoped to “capture loan applications digitally.” The KYC steps are still there. The compliance disclosures are still there. But the structure, the language, and the logic of the journey are oriented around what the member is trying to achieve — not what the institution needs to collect.

This is the purpose of member journey mapping at the start of a project: not as a design exercise, but as a brief-writing tool. Before any requirements are finalised, before any architecture is agreed, document the journey the member is actually trying to make. Use that as the frame for everything that follows.

The metric that matters

Institutions that build member-first products measure success differently from the start. Adoption rates, completion rates, drop-off by journey stage, calls generated per digital transaction — not just applications submitted or forms digitised.

These metrics tell you whether the member accomplished what they came to do. Which is, ultimately, the only question that determines whether a digital product earns the trust and continued use of the people it was built for.

The institutions that are consistently ahead of their peers on digital uptake are not the ones with the most features. They are the ones that started with the right brief.