Redgum Book a conversation →
Where to startProof of value

Where to start.

The most common question we’re asked isn’t “can you build it?” — it’s “where do we begin?”
The answer is smaller than most people expect, and that’s precisely why it works.

Why the starting point matters more than the plan

Most businesses come to technology wanting solutions: a system to buy, a process to automate, a problem to make disappear. The trouble is that automating the wrong thing just gets you to the wrong place faster. The businesses that build lasting capability start differently — with a small investment in discovery, mapping what’s actually happening against what should be happening, before a single line of code is written. (Not sure anything needs to change at all? The warning signs are usually visible a year before they’re painful.)

That sounds slower. It isn’t. Taking time for proper discovery delivers quick wins sooner and more often than rushing straight to solutions, because you build the right things in the right sequence. The “slow” road is the shortcut.

Why the first build should be almost embarrassingly small

A proof of value is the smallest build that delivers a measurable improvement — not a pilot, not a throwaway prototype, but a real working piece of the business that makes one thing demonstrably better. The point is not modesty. The point is belief. A big transformation asks everyone to trust a plan for a year before anything changes. A small win asks them to trust it for weeks, then pays them back — and that belief becomes the raw material every later release is built from.

One demands faith. The other builds it.

When operations hit a bottleneck, the temptation is to architect the perfect solution — map every process, design the ideal system, plan the comprehensive rollout. What happens next is familiar: the project turns political, timelines stretch, and teams lose faith before they see a single result.

The quieter path wins. Pick one painful workflow. Build the smallest thing that helps. Ship it in weeks, not quarters. People use it immediately — because it solves a real problem, and because they helped design it. Then they ask for the next improvement, and the big transformation happens anyway: one earned step at a time.

Ink drawing of a vast tangled machine beside one small working build, with the next stages sketched in red

The same problem, two ways to spend a year.

The big overhaul

Demands faith
  • An 18-month timeline
  • A 200-slide business case
  • Perfect on paper
  • Politics, delays and drift
  • Teams lose faith before they see results

The small release

Builds faith
  • Delivered in weeks
  • One real problem solved
  • Users involved from day one
  • Relief felt immediately
  • Teams ask for the next one

The boardroom loves a comprehensive plan. Your team needs a working solution — and the small release is the one that builds the confidence to keep going.

The full argument, in two essays

The two long-form pieces this thinking comes from.

The seven questions that find your first win

Run these with your team before you build anything. The right first project answers yes to most of them.

1

Does it fix something people complain about daily?

Real frustration beats theoretical efficiency.

Why this matters →Close ↑

Your first win should remove friction people actually feel. If nobody mentions the problem in normal conversation, choose something else — relief that goes unnoticed builds no belief.

2

Can one person test it without training three departments?

One user role, one workflow, one measurable outcome.

Why this matters →Close ↑

Complexity kills momentum before you see results. Keep the scope small enough that a single person closest to the problem can prove it works.

3

Will it improve data quality as a side effect?

Better information compounds into better decisions.

Why this matters →Close ↑

Bad data creates bad reporting, which creates bad strategy. The best first wins quietly clean up the information every later decision will stand on.

4

Can you measure the difference in one week?

Pick something observable — time saved, errors reduced, clarity gained.

Why this matters →Close ↑

If you cannot measure it quickly, you cannot prove it worked — and proof is the entire point of a proof of value.

5

Does it build a foundation for the next improvement?

Each layer should make the next decision easier, not bigger.

Why this matters →Close ↑

Isolated fixes create isolated benefits. The right first win is a first layer — something the second and third releases can stand on.

6

Will the person using it help design it?

Co-creation drives adoption. Order-taking drives resistance.

Why this matters →Close ↑

The people closest to the problem know where solutions stick. When they help shape the build, they champion it; when it’s handed down, they route around it.

7

If it works perfectly, what gets unlocked next?

Success should create appetite, not satisfaction.

Why this matters →Close ↑

A good first win grows your backlog from user requests, not meeting-room speculation. If you can’t name what it unlocks, it’s a dead end dressed as a quick fix.

Struggling to answer question one? That’s what discovery is for. Two places to look: where value actually hides in your business — Identifying the True Value — and where your customers feel the friction first — The Customer Progression.

Before you brief anyone, run the checklist

A ten-point discovery checklist, slide by slide. Swipe through — if you can’t tick the boxes, you’re not ready to build.

Cover slide: The Discovery Checklist — de-risk your next build
Most builds fail before they start — nobody mapped reality before the requirements
Process clarity checklist: map the process in ten minutes, walk every handoff, know where work stalls
Value clarity checklist: one measurable improvement, done in two weeks, ask the people who will use it
People and adoption checklist: frontline users in the room, resistance surfaced, a safe place to practise
Risk checklist: which workarounds keep things running, what could break mid-build
Slow down to go faster — 45 minutes of discovery prevents six weeks of rework
Run it before you build — Redgum
1 / 8

The thinking behind the checklist is in The Discovery Investment — and the whiteboard session it describes looks like this:

Ink drawing of two professionals mapping a process on a whiteboard, with the future process sketched in red beyond its edge

What a first win feels like.

One of our teams watched a client get three hours of every working day back from a single small build — not a transformation program, one workflow, done properly. The full story is in How We Saved 3 Hours Per Day.

Three hours a day is the measurable part. The part that matters more: the next three ideas came from the team, not from us. That’s the win behind the win — the moment a business stops being sceptical of change and starts asking for it.

Ink drawing of a small machine tidying a flood of paperwork while a professional wheels her bike out the door in daylight

And when it’s ready — ship it.

The last trap on the way to a first win is the oldest one: polishing. Organisations that demand perfection before release are often not protecting quality — they’re avoiding the moment of truth. The highest standard is a system that improves in contact with reality, and the fear dressed up as standards has its own essay: The Fear of Shipping.

Ship the small thing. Learn. Bank the win. Then build the next layer.

Ink cartoon of a team toasting a tiny working machine while an enormous dusty master plan leans forgotten in the corner

Where it leads

Every first win opens the same door: the second win. Layer by layer, small builds compound into something no big-bang transformation could have delivered — and that compounding is a story of its own.

Next: The long game — capability that compounds → All insights → Book a conversation →