Approach
From a fuzzy problem
to a decision that sticks
We start with the decision, not the model. Then we find what is blocking it, build the smallest useful intervention and make sure it works in practice.
It’s often not the model
Teams usually come with a data problem. What they need is a better decision.
Our capacity planning isn’t working. We need a better forecast.
-
What people ask for
Improve the forecast
-
What we examine first
- Decision
- Which decision needs to improve?
- Signals
- What information is already there?
- Constraints
- What is blocking a better decision?
- Action
- What can the team change?
-
What we may build
- A model
- A decision rule
- A workflow
- A dashboard
- Or something simpler
The model is only one possible intervention. We build what the decision needs.
The method
Four phases
One decision at the center
Every phase works on the same question: which decision needs to get better? Each one ends with something concrete you keep.
Frame: clarify the decision
Before touching any data, we pin down which decision is failing, who makes it and what it costs when it goes wrong. Getting this right keeps us from solving the wrong problem.
Key questions
- Which decision is failing, and how often is it made?
- Who makes it, and with what information?
- What does a wrong decision cost?
You leave with
A one-page decision brief that everyone involved agrees on
Diagnose: find the real constraint
We test the situation against the evidence. The aim is to locate where the problem sits: in the data, the analysis, the decision rule or the way people act on it.
Key questions
- What does the data show?
- Is the problem the data, the model, the rule or the workflow?
- What is missing, and does it matter for this decision?
You leave with
A written diagnosis with the evidence behind it and a recommended next step
Design: choose the simplest intervention
We lay out the realistic options, test them against scenarios and constraints, and pick the simplest one that meaningfully changes the outcome.
Key questions
- Which options are open to the team?
- What are the trade-offs under real constraints?
- How does each option perform across scenarios?
You leave with
A recommended option, the scenario comparison behind it and a first working version
Embed: make it stick
A good decision rule is worthless if nobody uses it. We build it into the team’s daily work, give it an owner and set up a way to tell whether it is working.
Key questions
- Who owns the new rule or tool?
- How does it fit the existing workflow?
- How will we know it worked?
You leave with
A tool or rule in daily use, with an owner and a way to measure impact
Different projects, different depth
Not every problem needs all four phases. Compare the four ways to start
-
Diagnostic
Frame → Diagnose
1–2 weeks
-
Proof of concept
Diagnose → Design
2–4 weeks
-
End-to-end project
Frame → Diagnose → Design → Embed
4–12 weeks
-
Ongoing support
Design → Embed
1–2 days per week
Common questions
before we start
Ask us something else
What do you need from us to start?
Three things: one person on your side who owns the decision, read access to the data and reports behind it (an export is fine to begin with), and two or three short conversations with the people who make or live with the decision. We handle the rest.
What if the diagnostic shows we don’t need a bigger project?
Then the diagnostic has done its job. You keep the written diagnosis, the evidence and the recommended next step, and you pay only the fixed fee agreed at the start. Often the fix is a change to a threshold, a rule or a workflow that your team can make itself.
Who will we work with?
The people who scope the work also do it: the analysis, the models and the build. There is no hand-off to a junior team after the first meeting.
Do you work with our existing data team?
Yes, and we prefer to. We usually pair with one analyst or engineer on your side, work in your repositories and tools, and hand over code and documentation as we go. Your team can run and change what we build without us.
What happens to the code and models when you leave?
They are yours. We work in your repositories and tools and document as we go, so code, models, data and notes stay with your team. Nothing depends on software or licences of ours.
How is pricing structured?
A diagnostic (1–2 weeks) is a fixed fee, agreed in writing before we start. A proof of concept or a project is priced per scope, with its phases and decision points written into the offer. Ongoing support is a monthly retainer for an agreed number of days, typically one or two per week. There is no open-ended hourly billing.
Can we skip the diagnostic and start with a project?
Yes, if the decision, the data and the owner are already clear. We then start with a short scoping session and write down the decision, how success is measured and the first phase before anything is built.
Tell us which decision isn’t working
That’s all we need to begin framing the problem.
Discuss a problem