A proposed solution often arrives before the problem is clear. Use this five-part method to separate symptoms from the constraint worth solving.
“We need a new HR system.”
That sentence sounds like a problem statement. It is a proposed solution.
The underlying evidence might be that managers cannot see staffing capacity, new employees receive inconsistent onboarding, payroll corrections are rising, or leaders lack the data needed for workforce decisions. Those conditions may share a cause. They may require different responses. Buying software before defining the problem makes the organization discover the distinction during implementation, when the cost of being wrong is higher.
Strong execution begins with a problem the organization can actually examine.
A symptom is an observable sign that something is not working: missed deadlines, customer complaints, turnover, slow decisions, margin pressure, or inconsistent delivery.
A constraint is the condition that limits the result. It may be unclear ownership, missing capability, competing measures, a broken handoff, insufficient capacity, or a decision that leadership has not made.
The difference matters because several symptoms can come from one constraint, and one symptom can come from several causes. “Communication is poor” could describe missing information, unresolved authority, inconsistent leadership, or a process that requires too many handoffs.
Naming the symptom more forcefully does not make the constraint clearer.
Before selecting a solution, write the problem in five parts.
Start with facts that another person could verify. Use dates, patterns, decisions, delays, defects, customer behavior, or financial effects.
“Teams are misaligned” is an interpretation. “Four product commitments were changed after delivery planning, and no single role owned the tradeoff” is evidence.
Evidence keeps the conversation attached to the work.
Describe the consequence for customers, people, economics, risk, or strategic progress.
The impact helps leaders decide whether the problem deserves attention now. It also prevents a visible irritation from outranking a less visible constraint with greater cost.
Define the part of the organization, workflow, customer journey, or decision in which the problem appears. Note where it does not appear.
If one region onboards consistently and another does not, the contrast contains useful information. If delays occur only when three functions share a decision, the boundary narrows the search.
Broad language produces broad solutions. Boundaries make testing possible.
Every diagnosis contains a belief. The team may assume people lack training, customers resist a change, managers need more authority, or a platform cannot support the process.
Write the assumption down. Then identify the smallest piece of evidence that would strengthen or weaken it.
This is often the point where a preferred solution stops looking inevitable.
Problem definition can become an endless group exercise when no one owns the choice. Name the person responsible for interpreting the evidence, selecting the next test, and deciding whether to act.
Input can be broad. Accountability should be clear.
Return to the HR-system example. A more useful definition might be:
During the last two quarters, managers in three growing teams could not see approved roles or start dates in one place. Eleven onboarding plans were rebuilt after hiring decisions, delaying productive starts and consuming operations time. We believe the main constraint is fragmented decision ownership and data, but we have not tested whether a shared workflow can resolve it before replacing the platform. The chief people officer owns the next decision.
That statement does not reject new technology. It shows what the technology would need to change and which operating choices must accompany it.
The next test might be a two-team workflow using existing tools, a review of where approvals stall, or a comparison with a team that onboards reliably. The test should reduce uncertainty before the organization commits to a large solution.
Choose one issue that has appeared in more than one meeting. Give the group 20 minutes and separate the conversation into five columns:
Do not debate solutions until the columns are populated. At the end, ask whether the original request still addresses the condition you have defined.
Often it will be part of the answer. Rarely will it be the entire answer.
The purpose of diagnosis is not analysis for its own sake. It is to give the organization a problem specific enough to act on and a test small enough to learn from.
When leaders separate evidence from interpretation, define the impact and boundary, expose assumptions, and assign the decision, execution improves before the formal initiative begins. The work is connected to a condition the organization understands.
That is how change moves beyond a launch and becomes part of how the business operates.
If an important initiative keeps solving the visible symptom without changing the result, explore how NWC works, consider strategy execution consulting, or begin with an organizational maturity assessment. If you would like to talk it through, start a conversation.
Shay designs the operating structures, roles, and rhythms that turn a strategy into everyday work, and writes on defining the right problem before designing the fix.
Operational maturity shows up in ordinary work: how priorities hold, who makes decisions, and whether customers receive consistent value. Here is how to see where the operating model is helping the strategy—and where it is getting in the way.
Jared Kinchen
An operating model begins to strain when decisions slow, priorities multiply, and delivery depends on individual rescue. These nine signals show where ambition has outgrown the way the business works.
Jared Kinchen
A strategy can be right and still fail in the operating model. A holistic view shows where structure, leadership, resources, and delivery need to change together.
Jared KinchenTwenty to forty-five minutes with a senior practitioner. No deck.