By Michael Nagorski, Founding Partner, Double Loop Performance
The two earlier posts in this series argued that goal-setting frameworks — OKRs, EOS Rocks, Scaling Up’s Four Decisions — assume a problem has already been agreed on, and that the agreement is usually missing. Neither post answered the question a facilitator or team lead needs going into a planning cycle: what to ask, and in what order, to find the real problem before the room defaults to a target.
That is what this post covers. Not a new framework — a set of questions, in a deliberate order, that does the work the earlier posts described but never spelled out.
Order matters more than the questions themselves
Researchers who studied how experienced managers solve problems found two distinct mental modes at work during deliberation. One was framing — reshaping how the problem itself gets understood. The other was implementation — working through what happens once a solution is already chosen. Which mode a person defaults depends on where attention lands first. Point someone toward framing early, and they restructure the problem. Point them toward implementation early, and they skip straight to solving, whether the problem was framed correctly in the first place.
That has a direct, practical consequence. If the first question in a planning session is “what should our number be,” attention locks onto implementation before framing gets a chance. The sequence below holds attention on framing first before implementation takes its turn.
A second finding matters just as much. People who move straight into big-picture, abstract thinking while framing a problem tend to miss symptoms that do not fit the mental model they walked in with. Concrete observation must come first, to surface the full range of what is happening. Abstraction is only useful once that is done — it is what turns scattered observations into an explanation that holds together. Skip the concrete step, and whatever problem the group lands on tends to be whichever piece already matched what people expected to find.
Building the sequence on Map, not on a workshop template
DLP’s MEET model opens with Map: get complexity out of people’s heads and onto the wall, in silence, before anyone talks it through. That is the same instinct problem formulation needs, and it’s the logic behind the questions below — not four separate stations a group gets sorted into, but one continuous act of surfacing, ordered to keep the room honest with itself before it moves toward a decision.
Working through these questions individually and in writing, before any discussion, does what Map is designed to do: it makes the real shape of the problem visible before the loudest read on it becomes the only read on it.
Start concrete. What specifically happened — this week, this quarter — that made someone think there is a problem worth naming? Where does it show up: in a number, a complaint that keeps recurring, a deadline that keeps slipping? Who noticed it first, and who has noticed it since? Keep these narrow. The point is getting everyone to describe the same real thing before anyone starts to theorize about why it is happening.
Then evaluate for a hidden conclusion. If this got written down in one sentence, would it name a cause, a fix, or an actual gap? Has anyone in the room already said what the solution should be before there’s agreement on what is wrong? What would need to be true for a different explanation to look more likely than the one people are leaning toward? This catches a common problem-formulation mistake — stating the problem as a diagnosis or a solution wearing a different name. If the honest answer to the first question is “a cause” or “a fix,” the room has not formulated a problem. It has reached a conclusion and called it one.
Then make the gap something to which you could point. Where do things stand right now, in a number or a state someone could observe? Where do they need to be, described in the same concrete way? What is the actual distance between those two points, and by when does it need to close? Skip this, and nobody can make the comparison that makes a goal feel meaningful later. “Improve retention” does not survive this test. “Renewal revenue sits at 68% of target for Q3 and needs to reach 85% by year-end” does.
Then check whether the room agrees or just stops disagreeing aloud. If everyone here wrote this statement down on their own, would the words match? Who would push back on this framing if they felt safe doing it, and has anyone asked them directly? Is what is happening real advocacy, or people who went quiet because it was easier than raising an objection? This last check draws on how buy-in forms: judging an idea as sound and being willing to act on it are separate things, and a room full of nodding heads with no pushback and no real ownership usually means the group settled for agreement without reaching it. Skip this check, and the disagreement avoided in the meeting tends to resurface months later, mid-execution, when it costs far more to fix.
What this looks like in practice
Have people write their answers down on their own before any group conversation starts. This is the same principle behind Map — talking first lets whoever is most confident in the room define the problem for everyone else before quieter perspectives get heard. Writing first prevents that.
Stay concrete longer than feels natural. Teams jump to “the real issue is our culture” almost immediately, and that’s premature abstraction — the exact move that causes people to miss what does not fit the story for which they have already reached.
Keep the pace tight. Loose, open-ended diagnostic conversations tend to produce loose, unworkable problem statements. A clear time limit forces specificity that an open discussion rarely produces on its own.
Do not skip the last check because it feels like it is slowing things down. It is the fastest way to learn whether everything before it produced agreement, or just a document nobody wanted to be the one to challenge.
Why this matters right now
Most organizations move through Q3 and Q4 planning with this exact sequence backward: target first, problem later, if ever. Doing it properly costs almost nothing, and it catches disagreement early, as a short conversation, instead of catching it in December, as a missed number and an uncomfortable retro. None of this is a new methodology stacked on top of OKRs, EOS, or Scaling Up. It is the front door those frameworks already assume someone walked through.
Frequently Asked Questions
What questions should you ask before setting a goal?
Start concrete: what specifically happened that made someone think there is a problem, and where does it show up? Then check whether the problem statement secretly names a cause or a fix instead of a gap. Then state the gap in terms specific enough to measure. Then confirm the room agrees, rather than having simply stopped arguing about it.
Why do goal-setting frameworks like OKRs need a problem-formulation step first?
OKRs, EOS Rocks, and similar frameworks are built to turn an agreed-on problem into a target. None of them include a step for reaching that agreement. Without it, a team can set a precise, well-structured goal that is still aimed at the wrong problem.
How do you know if a team has only reached surface-level agreement on a problem?
Have each person write down the problem statement independently, without discussion. If the wording does not match, or if nobody in the room is willing to push back on the framing, the group settled for agreement without reaching it.
What is the difference between framing a problem and solving it?
Framing means understanding and restructuring what the problem is. Solving means working through the consequences of an answer already chosen. Teams that start with implementation questions — like what the target should be — skip framing and solve whatever problem they assumed at the outset, whether it was the right one.
About The Author
Michael Nagorski is the Founding Partner of Double Loop Performance, where he helps organizations unlock sustainable revenue growth through sales strategy, organizational transformation, and workshop facilitation. A three-time University of Delaware graduate with an MS in Organizational Development & Change, Michael brings 15+ years of experience across Fortune 500 sales organizations and consulting engagements. He writes about leadership, coaching, and the human side of performance at doubleloopperformance.com.
Contact Double Loop Performance or contact Mike directly through LinkedIn.