Kidlin's Law

Most business problems arrive badly packaged. A senior leader says, "Sales are down." A customer-service director says, "The team is overwhelmed." A transformation sponsor says, "We need a new platform." A board asks why a strategic initiative is behind schedule.

Each statement may be true, but none is yet a useful problem definition. They describe symptoms, frustration, or a preferred response. They do not explain what is happening, where it is happening, who is affected, why it matters, or what evidence supports the concern.

Kidlin's Law offers a practical response: if you write a problem down clearly and specifically, you have solved half of it. The exact attribution is uncertain, but the principle is widely used in project management, requirements definition and problem solving1. Its value is not that writing magically produces an answer. Its value is that clarity removes the ambiguity that makes effective action impossible.

Why vague problems waste time

Vague problems create predictable management failures. Teams investigate the wrong issue, build solutions around the loudest opinion, collect data without a hypothesis and debate remedies before they agree on what needs to change. The result is activity without diagnosis.

Consider the statement, "Customers are unhappy." It sounds urgent, but it contains almost no usable information. Which customers? Unhappy with what? At what moment in their journey? How many customers? Compared with what baseline? What business impact follows?

A clearer statement might read: "Twenty-two percent of new enterprise customers abandon account configuration before completing identity verification, increasing support contacts and delaying time to first value by an average of six days." This statement does not yet solve the issue. It does something more important first:

it creates a shared object of analysis

Kidlin's Law works because the act of writing forces precision. If a team cannot state the problem in plain language, it is usually mixing facts, assumptions, causes, consequences and preferred solutions into one confused narrative.

The difference between symptoms and problems

A symptom signals that something is wrong. A problem statement defines the condition that requires action. Confusing the two is one of the most common strategic and operational errors.

"Revenue is declining" is a symptom. "Renewal revenue in the mid-market segment declined 14 percent in the last two quarters because customer-success coverage moved from named account managers to pooled support, increasing unresolved implementation issues" is a problem hypothesis. It contains a measurable condition, a population, a time frame, a possible mechanism and an impact.

The second statement may still require validation. That is acceptable. A good problem statement does not pretend to know everything. It makes explicit what is known, what is inferred and what remains uncertain.

This distinction matters because organizations often rush from symptoms to solutions. Declining revenue becomes a marketing campaign. Long call queues become a hiring plan. Delayed projects become a demand for a new governance tool. These responses may help, but they are guesses until the underlying condition is defined.

Write the current reality

A useful problem statement begins with observable reality, not emotion or blame. It should describe what is happening in terms that another person can verify.

Instead of writing, "Operations is failing", write, "Thirty-eight percent of purchase orders require manual rework after submission because requestors select incompatible cost-center and category combinations." The revised statement names the process, the error, the scale and the likely source of friction.

The wording matters. It removes loaded language and turns concern into a testable condition. It also creates a better starting point for cross-functional discussion. Finance, procurement and technology teams can disagree about causes while still agreeing on the observed failure.

A clear statement is not necessarily short because the issue is simple. It is short because the writer has separated the essential facts from the surrounding noise.

The six elements of clarity

A strong problem statement usually includes six elements.

1. Affected group: Who experiences the issue, such as customers, employees, suppliers, or a defined market segment
2. Observable condition: What happens in concrete terms, rather than how people feel about it
3. Process context: Where and when the issue occurs, including the relevant journey, business unit, product, or time period
4. Scale: How large the issue is, using volume, rate, trend, cost, delay, or another meaningful measure
5. Business impact: Why the issue matters, such as lost revenue, risk, poor experience, cost, or strategic delay
6. Boundary: What the statement does not claim, including untested causes and irrelevant scope

A practical format is:

[Affected group] experiences [observable condition] in [process context], causing [measurable impact] during [time period or trigger]

For example:

New subscribers abandon payment setup at a rate of 18 percent after the tax-information step, reducing trial-to-paid conversion and generating 240 monthly support contacts

The format does not replace analysis. It gives analysis a direction.

Writing exposes hidden assumptions

Teams often discover that they disagree only after trying to write the problem together. One executive believes the issue is demand. Another believes it is pricing. A third believes it is product quality. The act of drafting a shared statement makes these differences visible.

That is productive disagreement. It is much better to surface conflicting assumptions before spending money on a solution. A written statement can separate evidence from interpretation:

• Fact: Conversion from trial to paid use declined from 11 percent to 8 percent
• Fact: The decline is concentrated in customers using the mobile checkout journey
• Hypothesis: A payment-verification delay is contributing to abandonment
• Unknown: Whether the decline reflects a product change, market mix, or payment-provider behavior

This structure prevents a hypothesis from becoming a conclusion merely because it was stated confidently in a meeting. It also directs the next analytical step. The team now knows what must be tested.

Why teams jump to solutions

Solutions are psychologically attractive because they create a sense of progress. A new dashboard, platform, campaign, reorganization, or policy can be named quickly. The actual problem may be harder to define because it requires evidence, uncomfortable trade-offs and cross-functional inquiry.

This is why many problem statements are actually solution statements in disguise. "We need a customer relationship management [CRM] system" may really mean, "Sales teams cannot see a reliable, current record of account activity across channels, leading to duplicate outreach and lost follow-up." The first statement narrows the answer before the question is understood. The second makes several solutions possible, including process changes, data governance, workflow redesign, training, or technology.

Writing the problem well protects teams from solution bias. It does not prohibit preferred solutions. It simply requires the solution to earn its place through evidence.

Kidlin's Law in consulting

Consultants use a version of Kidlin's Law whenever they create a project charter, diagnostic question, issue tree, hypothesis, or executive problem statement. The discipline is especially important because clients often commission work around a stated solution rather than an agreed problem.

A consulting team might be asked to design an operating model, select a technology platform, reduce costs, or improve commercial effectiveness. Before accepting the requested answer as the assignment, the team should clarify the underlying condition.

For example, a request to "reduce operating cost by 15 percent" could hide several different problems: unprofitable customer segments, duplicated work across functions, low automation, expensive service levels, poor demand forecasting, or uncontrolled vendor spend. Each requires a different analysis and a different intervention.

The consultant's role is not to reject the client's request. It is to turn it into a problem statement that supports better decisions. A clearly written issue becomes the anchor for scope, stakeholder interviews, data requests, workstreams and recommendations.

Kidlin's Law in product and technology

Product and technology teams are especially vulnerable to unclear problem definition because technology offers many visible solutions. A team can quickly decide to build a feature, replace a system, add artificial intelligence [AI], or automate a workflow before confirming the user problem.

A stronger product statement names the user, the job to be done, the obstacle and the impact. For example: "Field technicians cannot close service visits without returning to a laptop because the mobile workflow does not support required photo evidence, causing same-day invoice delays and manual re-entry."

This statement is specific enough to guide design, but it does not dictate the answer. The product team might improve the mobile interface, simplify evidence requirements, integrate a camera workflow, or change back-office processing. The solution remains open until research and testing identify the best option.

Digital transformation succeeds when technology is connected to a defined operating problem. Without that connection, teams risk digitizing confusion rather than improving performance.

Kidlin's Law in leadership meetings

Leadership meetings often become less useful when participants bring issues verbally and expect the group to diagnose them in real time. The discussion may become emotional, political, or overly broad. A written statement changes the quality of the conversation.

Before escalating an issue, ask the sponsor to provide a one-paragraph problem brief. It should state the current condition, evidence, affected stakeholders, business impact and decision required. This requirement improves preparation without creating unnecessary bureaucracy.

It also reveals whether an escalation is ready. If the owner cannot state the problem clearly, the right next step may be investigation rather than a leadership decision. If the owner can state it clearly, the leadership team can focus on trade-offs, priorities and action.

Writing is therefore a governance tool. It protects senior time by separating problems that need executive judgment from problems that need better diagnosis.

A practical five-step method

Kidlin's Law becomes operational when teams apply a repeatable writing method.

1. Capture the raw issue: Write the concern without editing, including facts, frustrations, symptoms and stakeholder perspectives
2. Separate facts from interpretation: Mark what can be verified, what is assumed and what remains unknown
3. Draft one precise sentence: State the affected group, observable condition, context, scale and impact
4. Define the boundary: Specify what is outside scope and avoid naming a solution unless it has been validated
5. Test the statement: Give it to an informed colleague and ask whether they understand the issue, why it matters and what evidence would confirm or reject it

A useful test is whether the statement can survive three questions:

What exactly is happening? How do we know? Why does it matter? If the team cannot answer each question, the statement needs refinement

The limits of the law

Kidlin's Law should not be misunderstood. Some complex problems remain difficult after they are defined. A precise statement does not eliminate political conflict, resource constraints, uncertainty, or technical complexity. It does not replace analysis, experimentation, or leadership judgment.

What it does eliminate is avoidable confusion. It turns a diffuse concern into a structured question. It helps teams identify missing data, disagree productively and choose analysis that matches the real issue.

The principle is particularly useful in uncertain environments. When the answer is not known, clarity about the question becomes even more valuable. Teams do not need certainty to define what they are trying to understand.

Define before solving

The deeper lesson of Kidlin's Law is that problem definition is part of problem solving. It is not administrative preparation. It is the first substantive act of strategy, consulting, operations and product management.

Leaders should therefore make written problem statements routine. Use them before approving investments, starting projects, commissioning consultants, launching digital initiatives, or escalating operational risks. Require the statement to be specific enough to test and broad enough to avoid premature solution bias.

The discipline can feel slower at the beginning. In reality, it saves time by preventing teams from solving the wrong problem with impressive effort. A clear statement does not guarantee a good solution. But without one, even a well-executed solution may be irrelevant.

• 1Kidlin's Law