Build before you over-plan.

Every founder I meet has a plan. Some have a very good one. The plan is rarely the problem. The problem is that a plan can be improved forever, and a product cannot exist until someone stops improving the plan.

There is a point in every project where another week of strategy returns less than a week of building would. It arrives earlier than most people expect. You can usually feel it: the conversations start to repeat, the documents get longer, and the questions that remain are the ones only a customer can answer.

What planning is for

Planning is for deciding what not to build. It should produce a short list of things the product must do, a shorter list of things it must never do, and a clear idea of who will pay for it and why. If a plan does that, it has done its job. If it also contains a roadmap for year three, that part is fiction, and everyone knows it.

What building is for

Building is for finding out whether the plan was right. The first version is not the product. It is the instrument that measures the plan. That is why it should be small, and why it should reach real customers quickly. A version that takes a year to ship measures a plan that is a year old.

The rule I use

When a team asks whether to keep planning or start building, I ask one question: what would we learn from another week of planning that we could not learn faster from a rough version in front of a customer? If the answer is nothing, we start building. Strategy still matters. But eventually someone has to ship, and it should be sooner than it feels comfortable.