Why we ask for the problem, not the solution
Most intake forms invite organisations to describe a product. The useful question is narrower.
When you ask an organisation what technology they need, you get a description of a product they have seen elsewhere: an app, a dashboard, a chatbot. It is a reasonable answer to a badly framed question, and it almost always points away from the actual constraint.
The question we ask instead is narrower. What limits how many people you reach this month, and what happens if that stays unchanged for two more years? Answers to this are specific, unglamorous and immediately actionable: our cause lists are checked by hand, our camp data arrives three weeks late, advisory reaches a tenth of our members.
What limits how many people you reach this month?
This framing also protects the organisation. If the honest answer is that the bottleneck is funding, staffing or policy, software will not help, and we would rather say so in the first week than build something that gets used twice.
It changes what we build, too. Half of the deployments we are proudest of are not what the organisation would have asked for. They are smaller, closer to the existing routine, and almost invisible in a photograph.
Four questions we ask at intake
What limits how many people you reach this month? Which part of that is a data or software problem rather than a funding or staffing one? What would you stop doing if this were solved? And who inside your organisation would own the result after we leave?
Key points
- Asking for a solution returns a product someone saw elsewhere.
- Asking for a constraint returns something specific and testable.
- If the real constraint is funding or staffing, say so in week one.
- The best deployments are smaller than what the organisation would have requested.
Why the fourth question matters most
Ownership after handover is the single strongest predictor of survival we have. An organisation that cannot name the person who will run the system in two years does not yet have a deployment; it has a pilot with a longer timeline. We would rather surface that in the first conversation than discover it in the eighteenth month.
Questions this raises
What if the organisation genuinely does not know its constraint?
Then the first engagement is a field visit and a data-readiness read, not a build.
Do you ever build what was originally asked for?
Sometimes. Roughly half the time the stated ask survives the first four questions intact.
How long is intake?
One conversation, then a two-week field and data read before anything is committed.