All notes

Define The Problem Before You Build The Plan

Before you add strategy, test whether the problem is clear enough to plan around.

Plans feel productive because they create shape. A roadmap, a strategy doc, a hiring plan, a launch calendar, a product spec. These things can be useful. They can also hide confusion. A plan built on a vague problem gives the team something to execute while the real issue stays untouched. Before making the plan bigger, improve the conversation that creates the plan. That is the part people skip. They want the document because the document feels like movement. It gives everyone something to point at. It creates tasks, owners, timelines, and the emotional relief of structure. But structure is not the same as clarity. If the first conversation is vague, the plan will inherit the vagueness. Teams and founders move too fast past the uncomfortable part. People nod at words that do not mean the same thing to everyone.

“We need better positioning.” “We need to scale.” “We need more consistency.” “We need a system.” Those phrases sound clear. They are not clear yet. Ask five people what “better positioning” means and you may get five different answers. One person means a sharper niche. One means a new website. One means higher prices. One means the founder needs to stop chasing every lead. One means the product is still unclear. If the language is vague, the plan will be vague with better formatting. The better conversation starts by removing the label. Can we 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 someone else should own.” Plain language exposes the actual constraint. It also makes weak thinking harder to hide. A useful planning conversation also names the tradeoff. Most serious decisions are not only about what we want. They are about what we are willing to stop protecting. More focus means fewer options. Better quality means slower throughput. More delegation means less control. Higher prices mean some people leave. Simpler offers mean some edge cases do not fit. If the plan does not name the tradeoff, the tradeoff will appear later as conflict.

There is usually an unsaid sentence inside the overbuilt plan. “I do not trust the team.” “The offer is not strong enough.” “I am bored with this business.” “We are afraid to choose.” “This partnership is not working.” The unsaid sentence is often the real starting point. You do not need to be dramatic about it. You do need to make room for it. A plan that avoids the real sentence becomes theater. Before building the full plan, write one page with five lines: The problem in plain language. The evidence that it is real. The tradeoff we are accepting. The part we are not solving yet. The next two moves. If that page is hard to write, the team is not ready for a bigger plan. The difficulty is useful information. It means the conversation needs one more pass.

A clearer conversation saves time because it prevents expensive certainty. The plan should come after the real problem has been spoken plainly.