Pilot applications openWe’re listening to early-stage support needs.Start an application →
Apply for support

Field note

Listening before building is a delivery discipline.

Discovery is not a courtesy meeting before the “real” technical work. It is where a team learns whether the assumed problem exists, who experiences it and what a responsible response must preserve.

01The failure pattern

A solution arrives before the problem is shared

A team hears that records are disorganised and proposes a database. But the underlying problem may be unclear ownership, inconsistent definitions, poor connectivity, fear of monitoring or a reporting requirement that nobody can explain. Digitising the visible process can make the deeper failure faster.

02What listening produces

Discovery should create decisions, not only notes

Useful discovery identifies intended users, excluded users, current workarounds, information flows, constraints, harms, decision rights, success measures and the smallest responsible next step.

A shared problem statement An evidence-backed priority A map of current work Known risks and assumptions An accountable owner A decision on what not to build
03Power

Listening must change who can shape the response

If only funders, managers or technologists define success, the process is incomplete. People doing the work and people affected by it need a safe, accessible way to influence the scope and challenge assumptions.

04Exit test

The first technical decision may be to stop

Discovery can show that training, a policy change, a simpler form, clearer roles or removal of an unnecessary process will create more value than new software. Choosing not to build is a valid delivery outcome.

05Ubuntu Gale practice

What we will record before approval

Every proposed project requires a challenge statement, affected users, current process, constraints, risks, intended outcome, evidence plan, owner and a reason the proposed response is proportionate.