ยท 4 min read

Write the problem statement first: how we make ideas earn their way

Framework diagram of staged founder investment in an idea. Explore with conversations and napkin math, validate with prototypes and feedback, then commit with product, team and outside capital. Each stage must earn the next.

Key takeaways

  • An idea is a problem space plus a solution space. A technology or product without a qualified problem is only half an idea.
  • A strong problem statement names who feels the pain, what it costs them and why it matters now, and contains no solution.
  • Founders are the first investors in every idea. Stage your time and money the way an investor stages capital, and make each idea earn the next step.

Many failed ventures do not fail because the team could not build. They fail because the team built something for a problem that was never clearly defined. The fix is unglamorous: write the problem statement before anything else, and make every idea earn more of your time before you give it.

This is how we start new companies in our studio, and it is a habit any founder can adopt.

What counts as an idea?

We use a simple equation: an idea is a problem space plus a solution space. If either side is missing, you do not yet have an idea. A clever technology looking for a use is a solution in search of a problem. A painful problem with no credible way to solve it is a cause, not a company.

Founders tend to fall in love with the solution side first: a new material, a sensor, an autonomy stack, a business model that worked elsewhere. We ask them to set it aside and define the problem on its own. One well-defined problem space can support many solution spaces, and each pairing becomes its own candidate venture. You only see those options if the problem comes first. We wrote earlier about why pain and urgency come before pricing power, which is the next step after the problem is written down.

What makes a strong problem statement?

A problem statement is one or two sentences that make the problem impossible to misread. A strong one does four things:

  1. It is specific about the constraint. Not that maintenance is hard, but which maintenance, on what equipment, under what conditions.
  2. It names who feels the pain. A defined group of people, not everyone.
  3. It states the cost. Time, money, downtime, safety risk, lost contracts or reputation.
  4. It contains no solution. No product, no feature, no technology.

Here is a hypothetical example from the kind of industrial setting we work in. A weak version: Port operations are inefficient. A stronger version: Container terminals lose crane hours every week because maintenance crews cannot see wear on critical components until a failure stops the line, and each unplanned stop delays ships waiting at berth. The second version tells you who feels it, what it costs and why it is urgent, and it leaves room for very different fixes, from sensors to service contracts to new maintenance schedules.

Comparison table of weak and strong problem statements across four tests: specific constraint, who feels the pain, what it costs, and no solution inside. Hypothetical examples.

The test we use is blunt. If someone reads the statement and still has to ask what exactly you are solving, it is not done.

Is the idea worth investing in?

Before any building, an idea should show three things at once:

  • Deep, valuable pain. A real, urgent problem people are motivated to fix, and ideally already pay to work around.
  • A large or fast-growing market. Enough people or organizations feel it, or the number is growing quickly because the environment around them is changing.
  • Founder-market fit. The founder has a real reason to win: experience, access, insight or an obsession that will last years.

When all three converge, the idea has earned a closer look. When one is missing, it has not, however exciting the technology is.

How should founders stage their own investment?

Founders are the first investors in every idea, and their currency is time, attention and money. Founders should stage that investment the way a professional investor stages capital.

  • Explore (think pre-seed): customer conversations, quick experiments and back-of-the-napkin math.
  • Validate (think seed): prototypes, deeper analysis and honest feedback from people who know the industry.
  • Commit (think Series A): build the product, form the team and raise outside capital.

Each stage has to earn the next. If an idea fails early tests, move on quickly and keep your notes; problems you set aside often come back when conditions change.

Framework diagram: three stages of founder investment in an idea. Explore with conversations and napkin math, validate with prototypes and expert feedback, commit with product, team and outside capital. Each stage must earn the next.

Two traps sit on either side of this path. The first is over-investing too early: falling for an idea, telling everyone, spending money and quitting a job before the problem is validated. The second is the opposite: collecting dozens of half-formed ideas and never maturing any of them far enough to compare. Both waste the scarcest resource a founder has, which is focused attention.

What this means for founders and investors

For founders, a written problem statement is the cheapest risk reduction available. It aligns co-founders, sharpens customer conversations and makes the pitch obvious. It also makes it easier to walk away from the wrong idea early.

For investors, the problem statement is the first diligence document. A team that can state the problem crisply, explain who pays for it and show staged evidence has already done the work most pitches skip. We pair this with the capability milestones we use to retire technical risk once a solution is chosen.

We think nothing should get a team, a budget or a pitch deck until the problem is written down and has survived the first gate. That discipline separates durable companies from interesting experiments.

Frequently asked questions

What makes a good startup problem statement?

It is specific about the constraint, names a group of people who feel the pain, describes what the problem costs them in time, money, risk or reputation, and explains why it matters now. It says nothing about the solution. If a reader still has to ask what exactly you are solving, it needs another draft.

Should a problem statement mention the product?

No. Keep the solution out. Once a solution is in the statement, every later choice is framed around it, and you lose the chance to compare different ways of solving the same problem. One well-defined problem can support several solution spaces, each with its own business model.

How do founders avoid over-investing in an idea too early?

Treat your own time and money like staged capital. Start with conversations and back-of-the-napkin math, move to prototypes and deeper validation only if the early signals are good, and commit to building a team and raising capital only after that. Cut ideas quickly when the evidence does not support the next stage.