Problem first, tool last

A nonprofit leader goes to a conference, sees a demo and thinks: that could work for us. Within weeks a tool is chosen. Within months it's clear the tool doesn't fit the problem, and the organisation is managing sunk costs.

Our decision discipline starts by refusing that sequence. Clarify the problem before choosing any tool. It sounds obvious. In practice it's rare.

Why tool-first thinking is so tempting

The impact sector is especially exposed to it, for understandable reasons. Budgets are tight, teams are lean, and when someone hears about a platform that claims to solve a problem, the instinct is to move. Tools also carry narrative authority. They're tangible, they come with case studies, and they promise to compress complexity. A problem is messy and needs sustained conversation to understand.

Tools feel like progress. Problems feel like delay.

The damage follows a predictable sequence:

1. Scope creep starts early. The tool enables capabilities nobody asked for. The partner sees them and persuades itself they belong in scope. The timeline slips and nobody can point to when the agreement changed. 2. Feature bloat sets in. The team builds things adjacent to the problem because the problem was never defined crisply enough to say no. 3. Implementation fails quietly. The system is delivered and not used as intended. The partner is unhappy but can't say why. The build team thinks the technical work was right. Both are correct, and it doesn't matter.

The questions we ask first

When a partner arrives sure they need a data platform, our first move isn't a feature spec. It's three questions:

• What's happening today that shouldn't be?
• What does success look like, in concrete terms?
• Is this a software problem, or a process, conversation or role problem that software would only expose?

These conversations can be uncomfortable. A partner who's already imagined the solution may resist the reframing. A team member who could move faster by accepting it may be tempted to. The discipline holds until the problem is visible. Then tool selection becomes a real decision.

The same goes for scope and price. When there's pressure to agree a discount on work that hasn't been defined, we clarify the work first. Documenting three real scenarios with sample files feels slow in week one. It prevents months of rework.

Decide early, refine in the open

Problem-first doesn't mean slow. The opposite failure is waiting for certainty that never arrives.

Our rhythm is: name the problem, make a first attempt, put it in front of people, listen hard, adjust, move. When we needed to validate a new diagnostic tool for a partner, we skipped the six-month specification and asked one engineer for a working prototype by the end of the week, knowing it would be shaped by user feedback. What emerged over the next few weeks was better than any spec would have produced.

For a complex finance and operations system, we consolidated months of conversations into one requirements sheet, asked the partner to mark what was essential and what was missing, and only then ran technical validation. What the partner wants and what's technically feasible are separate conversations. Both happen, in that order, with clear gates.

A prototype that reveals a mismatch in week two is a gift. The same mismatch discovered in month five is a disaster.

Uncertainty is a design signal

In a lot of organisations, uncertainty triggers delay. People wait for more information or clearer direction. We treat it as a cue to test.

When something is large and unclear, we break it into one narrow question and a test that can run in days. When we needed a way to pull data from websites, the first step was researching and testing existing open-source tools ourselves, with a tight goal, before committing to build anything. Scope could grow later. Inside the test, it couldn't.

That boundary matters. Uncertainty doesn't mean "do whatever feels right". It means a small test that answers one question, run fast, followed by a decision about what's next.

Say what you don't know

It's hard to name uncertainty with a partner and stay credible. The framing we use is simple:

Here's what we know. Here's what we need to test. Here's how we'll test it in the next two weeks.

Partners respond to that. They'd rather hear "we need to prototype this first" than a guarantee on a feature nobody has built before. The first signals respect for the work. The second signals inexperience.

Hold boundaries while moving fast

The partners we qualify tend to be ready to move. Speed without boundaries is how good partnerships turn into scope creep, margin erosion and exhausted teams.

So scope changes are deliberate decisions. When a partner asks for changes after a call, we list them with effort estimates: two days for this, one day for that, five days for the other. The conversation shifts from "can you do this?" to "what does this cost in time?" People become more selective once they can see the weight of their requests.

Pricing works the same way. Discounting reflexively erodes margins and signals the work isn't worth much. It also takes away the team's room to do good work and push back when scope drifts. If a price only works with a steep discount, the fit is usually wrong.

None of this needs coldness. The message to partners is warm and clear at once: we want this to succeed, and we won't get there by being vague about what we're building, what it costs or who owns what.

Problem first. Tool second. Implementation third.

---

Previous: Why we tell prospects what we can't do. Next: When the project hits a wall.