Diagnosis and delivery belong together.
Consulting tends to stop at the recommendation. Contracting tends to start without the diagnosis. North Focus combines both — because building is part of how we learn.
Between advice and execution
Most approaches to operational problems fall into one of two traps.
Recommendations without delivery
Advice that stops at the slide deck, leaving you to work out the how. The real problem stays underneath.
Delivery without diagnosis
Technology dropped on top of the problem — with the friction still underneath. You get a solution to the wrong thing.
Diagnosis and delivery, together
We remove the friction between thinking and building. Implementation is part of the learning, not a separate phase.
Most businesses don't need more technology. They need less friction.
How engagement works
One path. Start with a diagnostic — and if there is a fit, move into discovery and a focused sprint.
Diagnostic call
A short conversation to understand what's slowing you down — and whether there is a meaningful problem worth solving. You leave clear on how we would work together, with no obligation either way.
Discovery
We define the problem, the success criteria and the constraints — and take an honest look at what has already been tried, before anything gets built. The diagnosis shapes what we do next.
Focused sprint
A fixed effort that solves a real problem, deepens our understanding of the underlying constraint, and reveals the next responsible step. Not a transformation programme, not a software project — a clear, bounded piece of work.
Start with a diagnostic. It is the lowest-friction way to find out if there is a problem worth solving.
Book a diagnosticWhat a sprint might include
The scope depends on what the diagnosis reveals. Typical areas of work include:
Sprints are bounded and outcome-focused. We are not trying to transform your business — we are trying to remove a specific piece of friction and leave you in a better position to decide what comes next.
How North Focus does not work
These are patterns we have seen cause problems — and deliberately avoid.
- Vague transformation programmes with unclear endpoints
- Technology-first fixes applied before the problem is understood
- Slide decks without implementation
- Creating dependency — the goal is to leave you in a better position, not a reliant one
- Building before the problem is properly diagnosed
See what this looks like in practice.
See examples