Asher's Blog

A problem is often only as clear as what you can write down about it. While it remains in your head, confusion can disguise itself as complexity. You feel that something is wrong, everybody agrees that it is urgent, and the team begins discussing solutions, but nobody has stated precisely what is happening, why it matters or what would be different if the problem were solved.

Writing interrupts that ambiguity. It forces thoughts that feel complete in your mind to survive contact with language. The moment you try to explain the problem in a form another person can understand, missing evidence, hidden assumptions and contradictions begin to appear.

This is why I believe you should write a problem down before trying to solve it. In fact, you can often tell whether a problem is ready to be solved by reading what has been written. If the description is vague, the solution will probably be vague as well.

Conversation creates movement; writing creates precision

Talking is useful because ideas can move quickly. People interrupt, challenge assumptions and contribute information that one person did not possess. A good conversation can reveal possibilities that would not emerge through solitary thinking.

However, conversation can also create the illusion of agreement. Everybody leaves the meeting feeling that progress was made, but each person carries away a different understanding of the problem and the decision. The disagreement becomes visible only later, when people produce incompatible work.

Writing slows thought down enough to make differences inspectable. A written statement can be examined word by word. People can ask whether a claim is supported, whether a term means the same thing to everyone and whether the proposed measure actually proves success.

The objective is not to replace conversation with documents. It is to use conversation to explore and writing to consolidate. Talk until the important possibilities are visible, then write down what the organisation now believes, what it has decided and what remains uncertain.

Name the observable condition

Weak problem statements often contain judgments without describing evidence. “Marketing is not working,” “customers do not like the product,” “engineering is too slow” and “the team is not aligned” may express genuine frustration, but they are not yet specific enough to guide action.

A stronger statement describes an observable condition. Marketing generated a particular number of leads, but only a small percentage matched the target customer profile. A significant proportion of new customers failed to complete onboarding within a defined period. Product releases repeatedly missed their dates because requirements changed after development began. Two teams were working towards measures that encouraged conflicting decisions.

The written condition should identify who is affected, what is occurring, where it occurs, how frequently it happens and what consequence follows. Not every problem requires every detail, but the statement should contain enough evidence to separate fact from interpretation.

This distinction matters because different diagnoses produce different solutions. “Sales is weak” may lead to replacing salespeople. “Qualified opportunities wait an average of two weeks for a proposal because pricing requires repeated approval” points towards a process and authority problem. The first description invites blame; the second invites investigation.

Write what you know and what you are assuming

One of the most valuable things a written problem statement can do is separate facts from assumptions. Teams regularly treat a plausible explanation as though it were established truth.

A company may know that customer churn increased after a price change. It may assume that price caused the churn. The timing makes the theory reasonable, but customers may have left because service quality declined, a competitor entered the market or the new price exposed a value problem that had existed for much longer.

Writing “we believe” or “our current hypothesis is” protects the organisation from becoming prematurely attached to an explanation. It creates room for evidence to change the conclusion without making the people who proposed it appear incompetent.

A useful problem document can therefore contain three categories: what we know, what we think may be true and what we still need to learn. This simple separation improves the quality of the next action because the team can design research or experiments around the uncertain parts rather than arguing from confidence.

Define the consequence

Not every imperfection deserves immediate attention. Companies have limited time and resources, so the problem statement must explain why the issue matters.

What does the problem cost in money, time, trust, risk or missed opportunity? Does it affect a small inconvenience or a critical customer promise? Is the effect growing? What happens if nothing changes for another six months?

The consequence helps leaders choose among competing problems. A recurring error that affects few customers may still be urgent if it threatens funds or compliance. A widely requested cosmetic change may have little influence on retention or growth. Without the consequence, teams can prioritise whichever complaint is most recent or whichever stakeholder speaks most loudly.

Writing the cost also clarifies the level of investment a solution deserves. A company should not spend ten times the value of a problem merely because the proposed solution is interesting. Conversely, a problem that threatens business continuity may justify immediate and substantial intervention.

Define what solved means before proposing how

One of the most important questions in problem-solving is also one of the most neglected: how will we know that the problem has been solved?

Teams often begin with a preferred solution. They decide to build a dashboard, hire another employee, automate a process or launch a campaign. The solution becomes the project, and completion becomes the measure of success. Yet the original outcome may remain unchanged.

Before selecting an intervention, write the condition that would demonstrate resolution. If onboarding is the problem, perhaps solved means that a defined percentage of suitable customers becomes operational within a certain number of days without manual escalation. If payment reliability is the problem, solved may require a particular success rate, a maximum resolution time and a reduction in repeat incidents.

The definition should be connected to reality rather than to the team’s output. “The feature was released” proves that work occurred. It does not prove that customer behaviour improved.

Writing the success condition early also allows the team to reject attractive solutions that cannot plausibly produce it. The document becomes a decision tool rather than a record created after the decision has already been made.

A useful problem statement is narrow enough to act on

Large problems should often be divided before they are assigned. “Fix customer experience” is not an objective one team can own meaningfully. Customer experience may include onboarding, product usability, transaction reliability, support quality and communication. Each has different causes and evidence.

Breaking the problem down does not mean losing sight of the whole. It means identifying the part that can be changed while understanding how it relates to the wider system.

A strong statement might say: “Thirty percent of new payroll customers require support to upload employee data because the template does not match the records they already maintain. This adds an average of four days to activation and causes some customers to abandon onboarding. We will consider the problem solved when at least ninety percent of suitable customers can complete the upload without support and median activation time falls below the agreed threshold.”

That statement gives product, design, engineering and customer success something concrete to investigate. It does not prescribe the solution, but it narrows the search.

Writing exposes ownership gaps

When a problem is described clearly, another uncomfortable question appears: who owns the outcome?

Vague problems survive because responsibility can move between teams. Product believes operations should solve it, operations believes engineering created it, and engineering believes the requirements were unclear. Writing the full process often reveals that the problem exists at a handoff where nobody has end-to-end responsibility.

The document should name one owner who will drive the problem to resolution, even when several teams must contribute. Ownership does not mean doing all the work personally. It means ensuring that the next step is clear, dependencies are followed and the success condition is measured.

It should also identify the decision-maker. Some problems persist because the team has enough information but nobody knows who can choose between competing trade-offs. Writing that down can save weeks of polite but inconclusive discussion.

Keep the document proportional to the problem

The argument for writing is not an argument for bureaucracy. A small, reversible problem may need only a few sentences: the current condition, likely cause, next experiment, owner and success measure. A high-risk issue involving money, security or several departments may deserve a longer analysis.

The document is useful only if it improves thinking and action. If teams spend more time formatting presentations than investigating the problem, writing has become performance. Clear language in a simple document is usually more valuable than sophisticated language in a deck nobody can interrogate.

The writer should be able to explain the problem to an intelligent person who lacks the company’s internal context. Acronyms, vague references and assumed history conceal uncertainty. If the problem cannot be explained simply, the team may not yet understand it well enough.

Rewrite the problem as you learn

The first problem statement is a hypothesis, not a sacred text. Investigation may reveal that the issue is different from what the team initially believed. The document should change when the evidence changes.

This is one of the advantages of writing: it preserves the evolution of thought. Leaders can see which assumptions were disproved, why a proposed solution changed and what the organisation learned. That history prevents future teams from repeating the same investigation and helps the company improve its judgment.

After the intervention, compare the result with the written definition of solved. If the measure improved temporarily and then declined, the underlying system may not have changed. If one metric improved while another important outcome worsened, the solution may have displaced the problem rather than resolved it.

The document keeps the team honest because the standard was established before the result was known.

Clarity is part of the solution

Writing does not solve every problem, but it changes the quality of the problem you are trying to solve. It converts anxiety into an observable condition, assumptions into testable hypotheses and activity into a measurable outcome.

Before the next meeting about a persistent issue, ask someone to write one page. What exactly is happening? What evidence supports it? Who is affected? What is the consequence? What are we assuming? Who owns the result? How will we know when the problem is solved?

If those questions cannot yet be answered, that is not a reason to avoid writing. It is precisely what the writing has revealed: the organisation is not ready to choose a solution because it has not completed the diagnosis.

A problem becomes easier when its boundaries are visible. Write it down, read it carefully and remove every sentence that hides uncertainty behind impressive language. When the problem is finally clear on the page, the next intelligent action often becomes much easier to see.