Define The Problem Before You Build The Plan

Plans are seductive because they make uncertainty look organized.

A roadmap, a strategy doc, a hiring plan, a launch calendar, a product spec. All of those can be useful. I use them. I like structure when it is earned. But a plan can also become a beautiful place to hide confusion. Everyone gets a timeline, a few owners, a set of tasks, and the feeling that something serious is happening. The problem is still sitting there, untouched, but now it has better formatting.

That is the part people skip too quickly. Before the plan, there is a conversation where the actual problem has to be named. Not the polite version. Not the phrase that sounds good in a meeting. The actual constraint. What is not working? What keeps repeating? What are we afraid to choose? What are we pretending is a strategy problem when it is really a trust problem, an offer problem, a capacity problem, or a founder still holding work that someone else should own?

You can usually hear the vagueness in the first sentence. “We need better positioning.” “We need to scale.” “We need more consistency.” “We need a system.” Those are not bad sentences. They may even be true. But they are not clear enough to build around yet. Ask five people what better positioning means and you can get five different answers. One person means a sharper niche. One means the website does not explain the offer. One means prices are too low. One means sales calls depend too much on the founder. One means the product itself is still hard to describe.

If one phrase can carry five different meanings, the team is not aligned. It only feels aligned because everyone is using the same words. That false agreement is expensive. The meeting ends well. The document gets approved. The work starts. Then three weeks later the conflict appears, because one person thought they were changing the website, another thought they were narrowing the customer, and another thought they were finally raising the price.

The simplest test is to remove the label. Can you explain the problem in plain language without using the phrase everyone keeps repeating? Instead of “we need better positioning,” try: “People understand us after a live explanation, but the website does not make the offer clear.” Instead of “we need a system,” try: “Every job depends on one person remembering the next step.” Instead of “we need to scale,” try: “The founder is still approving work that another person should own.” Plain language is not less strategic. It is often the first time the strategy has anything solid to stand on.

Once the problem is plain, the next useful question is not “What do we want?” Most people can answer that. They want more revenue, more focus, better quality, calmer operations, sharper execution, less dependency on one person. The better question is: what are we willing to give up? More focus means fewer options. Better quality may mean slower throughput. More delegation means less control. Higher prices mean some people leave. A simpler offer means some edge cases do not fit. If the plan refuses to name the tradeoff, the tradeoff does not disappear. It waits until the work is underway and then shows up as friction.

There is also usually a sentence nobody wants to say. “I do not trust the team.” “The offer is not strong enough.” “I am bored with this business.” “We are afraid to choose a niche.” “This partnership is not working.” You do not need to turn every planning session into a dramatic confession. That is not the point. But if the honest sentence is not allowed into the room at all, the plan gets built around a softer story. Then the softer story has to carry work it was never strong enough to carry.

That is why I like a small page before the full plan. Not a deck. Not a strategy monument. One page. The problem in plain language. The evidence that it is real. The tradeoff being accepted. The part we are not solving yet. The next two moves. If that page is hard to write, good. The difficulty is useful. It tells you the team is still negotiating with reality and should not pretend the bigger plan is ready.

A better problem definition saves time because it prevents expensive certainty. It stops people from spending months executing against a sentence they never properly understood. The plan should come after the real problem has been spoken plainly. If you cannot say it simply yet, the next move is not a bigger plan. The next move is a better conversation.