Do you have an execution problem, or a clarity problem?
Some plans stall because delivery is hard. Others stall because the decision underneath them was never made. Telling the two apart changes what you do next.
A convincing roadmap can conceal an unresolved decision
You have probably seen this roadmap. You may have written it. A platform modernization with milestones, assigned teams and a proposed target architecture. The steering deck is tidy and the first quarter is already staffed.
Then someone asks which business bottleneck the initiative removes, or why a new platform is preferable to improving the existing one. The answer depends on who you ask.
The project looks ready for execution. Its central decision is still open.
Are we struggling to deliver the plan, or have we planned before establishing the direction?
The two situations call for different leadership. Treating the second like the first is how capable teams execute a plan well and still arrive somewhere nobody needed to go.
Teams feel it first. In DORA’s 2024 research, people who described their organization’s priorities as unstable also reported lower productivity and more burnout.2 When an initiative keeps changing course because its central decision was never settled, that instability is what the people doing the work live with.
What to ask before you choose an approach
What are the consequences of acting, delaying, or choosing badly?
Weigh business outcomes, exposure, dependencies and how reversible the choice is. Importance is about consequences; urgency is only about timing. Project size and executive attention are weaker signals than they look.
How well do we understand the outcome, constraints, trade-offs, and a credible path forward?
A detailed document or a confident sponsor does not establish shared clarity. The organizational researchers Richard Daft and Robert Lengel described two different ways a situation can be unclear. Under uncertainty, people lack information, and more data helps. Under equivocality, people hold competing interpretations of the same facts, and the work is reaching a shared one.1 A single decision can suffer from both.
Do we need another answer, or agreement about the question?
“We need faster onboarding.”
More data will not settle this. The group first has to agree which of these it means, because each one points to different work.
Clear enough to authorize what?
You never need certainty, only enough understanding to justify the next commitment. A team can understand a business bottleneck well enough to run a narrow test while still lacking the grounds to fund a complete replacement.
Investigating, testing, migrating one workflow and replacing a platform are separate decisions, and one initiative can hold all of them at different levels of clarity. That is why the matrix works best on individual decisions rather than whole initiatives.
The Importance × Clarity matrix
Put the two questions on axes and you get a simple grid. It won’t make the decision for you, but it keeps apart two questions that usually get answered as one, and each quadrant suggests a sensible default. Scroll to walk through them, or select a quadrant to jump to it.
- High importance · Low clarity
Frame the problem and establish direction
What must we understand before committing?
- Example
- The board asks for an AI strategy. Nobody can yet say which decisions it should change.
- Common mistake
- Producing a delivery plan to show momentum. The plan becomes the thing everyone defends, and the open decision goes underground.
- Next move
- Name the decision that would most change the plan, then do the smallest piece of work that makes it defensible.
- High importance · High clarity
Organize execution
What capacity, ownership, and sequencing will delivery require?
- Example
- A core database reaches end of support in eighteen months. The target version, migration path and owners are agreed.
- Common mistake
- Reopening settled decisions because the work got hard. Difficult is not the same as unclear.
- Next move
- Staff it, sequence it, measure it. Track the few assumptions that could still move the plan.
- Low importance · High clarity
Delegate, standardize, or automate
Who can handle this with appropriate oversight?
- Example
- Certificate renewals for internal services, already scripted and monitored.
- Common mistake
- Keeping it on a leader’s desk because it is familiar. Senior attention spent here is taken from somewhere else.
- Next move
- Give it an owner, write down the standard, and automate what repeats.
- Low importance · Low clarity
Decide cheaply, defer, or discard
Does resolving this deserve our attention?
- Example
- A recurring debate about which internal documentation tool the teams should prefer.
- Common mistake
- Treating every open question as a project. Some ambiguity is cheaper to live with than to resolve.
- Next move
- Make a reversible call, set a date to revisit, or drop it.
The examples depend on context. A certificate renewal is routine housekeeping until it guards the payment gateway for your largest customer. Look at the consequences to find the quadrant, whatever the task is called.
An approved architecture is not a settled decision
I learned this on a modernization initiative I helped lead. Names and specifics are left out.
As you scroll, the figure tracks two things that are easy to treat as one: confidence in the technical approach, and clarity about the broader commitment it serves.
- 01 · Initial direction
A credible business case
We began with a credible business case: improve developer productivity, hosting economics, and the customer experience.
EstablishedA business case for modernizationStill depended on assumptionsDeveloper productivity would improveHosting economics would improveCustomer experience and performance would improve - 02 · Context changes
An acquisition changes the question
An acquisition changed the context. Integrating with the new parent company’s existing cloud platform offered capabilities we could reuse and a compelling strategic rationale.
EstablishedA new parent company with its own cloud platformStill depended on assumptionsIts capabilities could be reusedThe strategic rationale would hold up commercially - 03 · Architecture approved
A clear technical approach
I helped take that direction through architecture review, and we had resources committed to deliver it.
That gave us a clear technical approach. It did not settle every question about whether the integration was the right choice.
EstablishedThe integration architecture passed reviewResources were committed to deliver itStill depended on assumptionsCommercial overlap would justify the integrationProduct requirements would serve both sides - 04 · Reassessment
Revisiting the business case
When we revisited the business case, the commercial overlap and product fit were weaker than we had expected. Making the integration work would require substantial changes without enough shared benefit to justify the direction.
We changed course toward a more independent hosting approach.
EstablishedCommercial overlap was weaker than expectedProduct requirements did not benefit both sides equallyThe direction changed to more independent hostingStill openImportant deployment questions
We had established how the integration could work more clearly than we had established why that particular integration should be pursued.
The review did what it was meant to do: it tested whether the architecture could work, and it could. Whether the integration made commercial and product sense was a separate question, and an approved design made it easy to treat as settled. On the matrix, they were two decisions in different places.
Changing direction did not resolve every uncertainty. It changed which decisions we could defend, and which questions still needed work.
Keeping the second decision visible
Before a piece of work starts, say which decision it is meant to inform. “Discovery” stops being a phase on a roadmap and becomes a question with an owner. Sometimes the answer is that the work should stop, and that is a good result.
Then write the decision down: what you chose, why, and what you traded away. A few lines is enough, and engineers will recognize it as an architecture decision record.4 When the context shifts, as it did for us, you can see which reasons have fallen away and which parts of the plan still stand.
How leaders misread the matrix
- 01
Mistaking urgency for clarity
A deadline establishes when a decision matters. It does not establish the right decision.
- 02
Mistaking agreement on a solution for agreement on the outcome
People can back the same solution for incompatible reasons: moving to the cloud for lower cost, faster hiring, one customer’s requirement, or a cleaner story for an eventual sale. When researchers surveyed 228 software organizations about their requirements problems, hidden requirements, communication with customers and moving goals were among the issues practitioners ranked most critical.3
- 03
Treating low clarity as a reason to wait
Under immediate exposure, an unfamiliar production incident or a fixed date, the right next commitment may be to stabilize or ship a constrained fix, then revisit it as evidence arrives. Further investigation earns its place when it could change the next decision or its safeguards.
- 04
Treating a placement as a fact
Where a decision sits is a judgment, and people will disagree about it. That disagreement is useful. When two people put the same decision in different quadrants, you have found it before spending money on it.
Clarification and execution can run alongside each other. The distinction matters most where you are about to make a commitment that is expensive or difficult to reverse.
Choose your next move
If you recognized your own roadmap somewhere in this article, start by naming the decision underneath it. If the direction is clear enough for the next commitment, get on with delivery. If it isn’t, work out what would make it defensible: evidence, alignment between the people involved, a bounded experiment, or a conversation with someone outside the situation.
Have an important problem without a clear path forward? Bring the messy version.
A place to think out loud. No polished brief. No obligation to turn it into a project.
The Importance × Clarity matrix is a leadership heuristic, not a validated assessment. These sources inform the distinctions it draws; none of them tests it.
- [1]Conceptual model · 1986Organizational information requirements, media richness and structural designRichard L. Daft and Robert H. Lengel. Management Science 32(5).
- [2]Survey and modeled relationships · 2024Accelerate State of DevOps Report 2024DORA. Associations from respondent reports; not causal.
- [3]Practitioner survey · 2017Naming the pain in requirements engineering: contemporary problems, causes, and effects in practiceDaniel Méndez Fernández et al. Empirical Software Engineering 22.
- [4]