The atomic problem. The smallest thing worth solving.
The smallest version of a problem that is still worth solving: a sentence with a number in it, an owner near it, and a system behind it. Isolate that, and most of the roadmap around it turns out to be ceremony. It is the one idea the whole firm is built on, and the case for why it beats the programme and the bloated MVP alike.
What an atomic problem is
It is rarely on the first slide. The problem that actually moves the business is usually buried: in the risk register, in the appendix where someone quantified the leakage, in a footnote written by the one analyst who watched the process run.
An atomic problem is that buried thing, pulled out and stated plainly. Small enough to say in a sentence. Concrete enough to carry a number. Owned by a person with a name. Backed by a system you can actually change. If it cannot be reduced to that, it is not yet a problem you are ready to pay to solve. It is a programme.
Why the industry avoids it
Two business models reward the opposite. When the work is billed by the hour, your unsolved problem is what the vendor gets paid for, so the meter has every reason to keep running. When the work is funded as a programme, it has to be big enough to clear a steering committee, which makes it too big to ever finish. Different roads, same destination: motion without a finish line.
The measured data agrees, even from the firms that sell the big engagements. Bain finds that ninety percent of the value in a transformation comes from less than five percent of the roles. McKinsey finds that even the transformations that succeed leave about a third of the value on the table, and that most of it is lost early, in target-setting, before anyone builds a thing. The value was never in the sprawl. It was in the one part everyone dressed up until it disappeared.
How we work it
One problem, five moves. Each one hands you something you keep.
- Isolate. We sit in the noise and find the one problem whose answer changes the business. You hold: a one-page problem map
- Strip. Everything else is set aside. What remains is a single requirement, stated in one sentence, with a fixed price against it. You hold: the atomic problem statement
- Build. Our own team builds it, outside your process. No steering committees, no timesheets, software dropped weekly. You hold: working software
- Prove. You get the working solution and the evidence that it does what the sentence promised. You hold: the evidence pack
- Own. Code, infrastructure and documentation transfer to you. Your team runs it without us. You hold: everything
The three things you keep
An atomic problem leaves a paper trail. Three artifacts, each one a thing you own, not a slide about it.
- The one-page problem map (from Isolate), The whole situation on a single page, with the one problem worth solving circled.
- The atomic problem statement (from Strip), One sentence. One number. One owner. One system. The thing we price against, and the thing you hold us to.
- The evidence pack (from Prove), The working software, plus the proof that it does what the statement promised. The thing itself, and the numbers around it.
What it replaces
For corporates: vs the transformation programme
A programme is a hundred problems in a trench coat, sized to survive governance. An atomic problem is the one of them with a number attached. Keep the programme if you like. We will solve the sentence hiding inside it.
For startups: vs the bloated MVP
The MVP has quietly become a small platform, built before the market has spoken. An atomic problem is smaller and braver: the one flow that tells you whether any of it is real. Build the question, not the platform.
Bring us one problem.
Not a roadmap. Not an RFP. One problem, and the number that would change if it were solved. We will tell you the answer, the price, and the weeks.
