Problem Framing
“The discipline of defining problems clearly before solving them.”
The team is deep into solutions. Progress feels real. But there's a nagging sense that the problem statement everyone agreed to three weeks ago was never quite right.
Problem framing is a definition discipline. You challenge the initial problem statement, explore alternative framings, and align stakeholders on what you're actually solving — recognising that how you frame a problem shapes which solutions become visible.
The technique prevents the common trap of efficiently solving the wrong problem. Reframing often reveals that the obvious problem masks a deeper opportunity — or an entirely different question worth answering. Reach for it at the start of any project where the problem statement was inherited rather than interrogated.
Effective framing includes clear success criteria and explicit scope boundaries. The investment pays dividends throughout: rushing past this step leads to rework when the real problem surfaces mid-build. The failure mode is using framing as procrastination — endlessly redefining the problem to avoid the discomfort of committing to a direction.
Your next move: Write the problem your team is solving as one sentence, right now, without using jargon — does it match the problem the customer would describe, or are you about to solve someone else's question?
What it looked like for them
Paul Howley, UK mortgage lender, mid-2020s. A mortgage lending team had decided their problem was technology — slow processing, unhappy customers, NPS at minus eleven. The plan was a technology upgrade.
Howley — then at Yorkshire Building Society, now Chief Technology and Transformation Officer at Nottingham Building Society — stopped the technical work and went to sit with the team doing the actual processing. The friction wasn't a technology gap. It was a layer of unwritten conventions — "ghost policies" — that staff had built up over years to handle edge cases nobody had ever documented.
The workarounds had become the process. Fixing the actual processes rather than the technology pushed processing time down by twenty per cent and NPS from minus eleven to plus eighty. The technology the team had planned to buy was designed to solve a problem that didn't exist.
The problem that did exist was invisible until someone reframed the question from "what technology do we need?" to "what are people actually doing?" The reframing dissolved the original brief entirely.
“A stakeholder keeps changing their mind and I can't lock the scope.”