Do Tomorrow's Work Tomorrow

Over the past few years, I've had the opportunity to mentor multiple startups and speak to founders from different parts of the world. They work in different industries, come from different backgrounds, and are trying to solve very different problems.

But I keep seeing the same mistake.

Founders start doing tomorrow's work before they have finished today's.

They create a business plan, prepare a pitch deck, build financial models, think about pricing, speak to manufacturers, look for designers, and plan their go-to-market strategy. From the outside, it looks like serious progress. The business starts to look complete before it has even become specific.

The problem is not that any of this work is unnecessary. Most of it may eventually be needed. The problem is the order in which it is done.

At the beginning, a founder usually does not need a more complete business. They need a clearer problem.

A founder may notice something that feels broken and form a vague idea of a solution. The problem may even be real, but there is still a lot to understand. Who experiences it? How often does it happen? What does it cost them? What are they doing about it today? How badly do they want it solved?

Instead of investigating those questions, founders often make the solution more elaborate.

I understand why this happens. It is easier to spend a week refining a financial model than to ask a potential customer whether they would actually pay. It is easier to create a pitch deck than to hear that the problem is not painful enough. It is easier to build something privately than to put an unfinished idea in front of someone who might reject it.

Preparation feels productive. Customer conversations can make you uncomfortable.

One founder I spoke to had spent months preparing almost everything. They had a business plan, a financial model, a pitch deck for investors, and a detailed game plan. They believed they had a solution people were willing to pay for.

What they had not done was properly understand what customers actually needed.

Once they started speaking to people in the market, they realised that their original idea was too broad. They became more specific about what needed to be worked on, and their go-to-market effort became much clearer. The time required was cut almost in half.

That was not because they suddenly became more efficient at executing the same plan. It was because they stopped trying to solve everything and found the part that actually mattered.

They also realised that they were getting bored with the work they had originally planned to do. That may sound unrelated, but I don't think it is. When you spend months building an abstract business around a vague problem, you may eventually discover that you do not want to spend years working on the solution.

You are not only testing whether the market wants the idea. You are also finding out what you are committing yourself to.

I've made a similar mistake myself.

For one of my early projects, I had an idea for a hydroponics pot. I made a business plan, found manufacturers, and started looking for designers to build the product. I was doing everything that made the idea feel real.

But I had not asked whether it was important enough for anyone to buy.

Before spending money on manufacturing, I spoke to people in the market. There was interest. People understood the idea and were willing to consider it. But the interest was not strong enough. It was a good-to-have solution, not a must-have one.

That experience changed how I think about early-stage work.

A solution being possible is not enough. A solution being interesting is not enough. Even a solution being liked is not enough.

When I speak to potential customers, I want to understand whether they have already tried to solve the problem. What did they try? What happened? How much time or money is the problem costing them today? What would change if it were solved? How urgently are they looking for an alternative? The answers are more useful than "That's a great idea."

Everyone will tell you that your idea is good. They may genuinely like it and still never use it. The stronger signals are concrete: an introduction to the decision-maker, a serious commitment of time, a letter of intent, an advance payment, or some other action that shows the problem matters.

These signals are not perfect. The user may not be the buyer. Someone may have a real problem but no authority or budget to purchase a solution. But there should be some evidence that the problem matters enough for someone to act.

You also do not need to build the final product to start learning. You can create a simple brochure, draw a basic flow, prepare a rough explanation, or manually deliver what you think the product might eventually do.

The point is not to prove that the solution is finished. It is to make your thinking concrete enough for the real world to challenge it.

If people like the idea but do not change their behaviour, the idea may not be important enough. If their feedback is vague, the problem may still be vague. If several people describe the same problem, explain what they have already tried, and show serious interest in your proposed solution, you may have found something worth exploring further.

The output of this stage is not necessarily a product.

It is specificity.

You start with a broad thought and gradually learn what actually needs to be built, for whom, and why. Only then do the next layers of work become useful. Pricing becomes easier when you understand the value you are creating. A financial model becomes more meaningful when you know who is likely to pay. A go-to-market plan becomes more focused when you know exactly which customer and problem you are targeting.

There are exceptions, of course. Deep-tech, medical, financial, and infrastructure companies may need serious research and technical work before a complete product can exist. But even in those cases, founders should try to understand the need before spending years perfecting a solution.

Research should reduce uncertainty. It should not become a comfortable way of avoiding the market.

The same is true of moving fast. Moving fast is not about doing everything immediately. It is about completing the right work for the stage you are in.

At the beginning, your job is not to make the company look ready. It is to understand what deserves to be built.

Do tomorrow's work tomorrow.

It will still be there. And you might understand it much better by then.