First Week Plan
A day-by-day template for the first week of a real business, starting with the first conversation.
The first week of building a company is not about building a product. It is about validating that the problem you intend to solve is real, painful, and worth paying for. Most founders spend their first week setting up tools, designing a logo, and drafting a business plan. The founders who make progress in their first week spend it in conversation with people who have the problem they think they are solving.
In short
- • Write a single sentence that describes the problem you are solving for a specific person. Not the solution. The problem. 'Small business owners spend 10 hours per week manually reconciling their bank statements because existing accounting software does not integrate with their payment processor.' That sentence is testable. You can ask ten small business owners if it describes their experience.
- • If you cannot write this sentence, you do not have a problem definition yet - you have a solution looking for a problem. Go back to the observation that made you want to start the company. What did you see? What did someone say? What did you experience? The original observation is the seed of the problem statement. Nurture it until it is specific enough to test.
- • Contact ten people who might have the problem. Ask one question: 'Does this describe your experience?' Show them the sentence you wrote on day one. Listen to their response. If eight or more say yes, you have a validated problem. If fewer than five say yes, refine the sentence and try again. The threshold is 60% confirmation - anything below that means the problem statement is too vague or too narrow.
Day one: define the problem precisely
Write one sentence describing a specific problem for a specific customer.
Use:
Customer + situation + problem + consequence
Example:
Small business owners spend hours reconciling payment data because their accounting and payment systems do not share the information they need.
The example is a hypothesis, not a fact. Replace it with your own observed evidence.
The goal of the first day is not to create a clever statement. It is to make the assumption precise enough to test.
Days two and three: investigate the problem
Speak with people who plausibly experience the problem.
Ask about the last time it happened:
- What triggered it?
- What did you do?
- What did it cost?
- What did you try already?
- Who else was involved?
- What made the current solution acceptable or unacceptable?
Do not use a fixed “eight out of ten” or “60%” threshold as proof of validation. Ten conversations can reveal useful patterns, but the quality and relevance of the evidence matter more than an arbitrary percentage.
Look for repeated behaviour and consequences, not agreement with your wording.
Days four and five: map the alternatives
For each conversation, record what the person uses today.
The alternatives may be:
- another product;
- an internal process;
- a spreadsheet;
- a person doing the work manually;
- doing nothing;
- accepting the problem.
Then ask why the current approach is tolerated.
If the problem is painful but the existing solution is acceptable, the opportunity may require a materially better outcome. If nobody has tried to solve the problem, investigate whether the problem is actually urgent enough to support a business.
What you should have at the end of the week
You should be able to state:
- the customer situation you are investigating;
- the recurring problem you observed;
- the consequences of that problem;
- the current alternatives;
- the assumptions still untested;
- the smallest next experiment.
You do not need to have “validated the business” in five days. You need to have reduced uncertainty enough to choose a better next test.
The decision test
At the end of the week, ask:
- What did people actually do, not just say?
- Did the same problem appear independently?
- Is the consequence meaningful?
- Is someone already spending money, time or attention on the problem?
- What remains an assumption?
- What is the cheapest credible experiment that could test the next important assumption?
- What result would make us stop, change or continue?
If the evidence is weak, the answer is not to manufacture confidence. Narrow the customer, sharpen the problem, or run another test.
Research and evidence
Y Combinator's early-stage guidance supports talking to users, launching and learning from real behaviour. The specific sequence above is SOE editorial synthesis; it is not a validated five-day formula.
Evidence boundary: A short discovery sprint can improve understanding, but it cannot by itself prove product-market fit, repeatability or market size.
Use this on a real decision
Problem: What uncertainty are we trying to reduce?
Evidence: What did real people do or report from recent experience?
Options: What can we test next?
Trade-off: What will the test cost in time, money and attention?
Next action: What is the smallest credible test?
Review point: When will we interpret the result?
Take it into your work
Do something with what you just read.
Save it for later, mark the passage that matters, or open your SOE workspace and keep thinking.
Takeaways
What to carry forward
- → Do not pitch during these conversations. Do not mention your product. Do not try to sell anything. The goal is pure problem validation. The most dangerous thing you can do in a problem-validation conversation is explain how your product solves the problem before you have confirmed that the problem exists. If the prospect says 'I do not have that problem,' you have just saved yourself months of building something nobody wants.
- → After validating the problem, ask the same ten people what they have tried to solve it. Their answers reveal two things: the existing solutions in the market and the gaps those solutions leave. These gaps are your opportunity. If no one has tried to solve the problem, the market may not exist yet. If everyone has tried and found something that mostly works, your job is differentiation, not invention.
- → By day five, you should have: a validated problem statement, a list of at least five people who confirmed they have the problem, a list of at least three existing solutions they have tried, and a hypothesis about what would make a solution better than what exists. That is more than most founders have after a month of working in isolation.
The first week is about learning, not building. Define the problem. Test it with ten people. Understand the solution landscape. Do not open a code editor, do not design a logo, do not write a business plan. Talk to people. The fastest way to waste a year of your life is to spend the first week doing anything other than validating that the problem you want to solve is real.