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 problem definition.
Bad plans often start with false agreement
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.
Run the plain language test
Before a bigger plan, ask:
Can we explain the problem in plain language without using the label?
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.
Build the plan around tradeoffs
A useful planning pass does not ask, “What do we want?”
It asks, “What are we willing to give up?”
Most serious decisions require a tradeoff:
- 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.
Look for the unsaid sentence
Every overbuilt plan has an unsaid sentence inside it.
“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.”
The unsaid sentence is often the plan’s real starting point. You do not need to be dramatic about it. You do need to name it. A plan that avoids the unsaid sentence becomes theater.
Use a one page pre-plan
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 problem definition needs one more pass.
A clearer problem definition saves time because it prevents expensive certainty.
The plan should come after the real problem has been spoken plainly.