You may already know what you want to build.
A book. A business. A workshop. A course. A community. A new service. A tool for your team. Perhaps you have been thinking about it long enough that you can already imagine the name, the website, the people who might use it, and what the finished thing will look like.
That excitement is useful. Builders need enough imagination to see something before it exists.
But before you invest months of your life making the thing, ask a harder question:
What problem deserves this much of you?
A good idea is not automatically something worth building. You can spend months creating a beautiful solution to a problem people barely notice. You can build a course nobody finishes, a tool people admire but do not use, or a business whose founder spends more time explaining the product than customers spend wanting the result.
Sometimes the best thing an investigation can do is make the project stronger.
Sometimes it can save you from building it at all.
Let the problem earn the project.
You can love an idea before anyone needs it
Ideas arrive with energy.
You think of a program during a conversation and suddenly see the whole thing. You discover a technology and imagine the business you could build around it. Something happens in your life and you think, I should write a book about this. Someone shows you what they created, and you begin imagining your own version.
Soon you are researching.
There is nothing foolish about this. Many worthwhile things begin with curiosity, enthusiasm, irritation, imitation, or a possibility that refuses to leave you alone.
The trouble begins when enthusiasm for the solution prevents you from examining what is actually happening.
Once we fall in love with the book, we begin searching for people who need a book. Once we decide to create a workshop, every problem starts looking like something a workshop can solve. Once we decide that an app is the answer, we begin searching for places to put an app.
The direction has quietly reversed.
Instead of allowing reality to shape what we build, we start trying to persuade reality to need what we already decided to make.
Remove the thing for a moment
Try this with something you are considering now.
Name the thing you want to build.
Perhaps your answer is:
I want to create a course for new supervisors.
Now remove the course.
What is happening in someone’s life or work that makes you think something needs to exist?
Perhaps you notice a first-time supervisor who keeps taking difficult work back whenever an employee struggles. She wants the task completed quickly, so taking it back seems sensible. But every time she does, she becomes more overloaded while her team becomes more dependent on her.
Now we have somewhere more useful to begin.
Not with the course.
With the situation.
The course may eventually be the right thing to build. But now it has to earn its place.
People do not experience big topics. They experience moments.
Suppose somebody tells you:
“Our team has a communication problem.”
That sounds clear enough to start building. Communication matters, so perhaps you begin designing a program around active listening, feedback, empathy, body language, difficult conversations, presentation skills, and conflict.
Every topic may be useful.
But what is actually happening?
Perhaps supervisors give instructions and employees begin work without understanding the expected result. Perhaps meetings end with people carrying different versions of the decision. Perhaps employees notice problems but remain silent because disagreement feels risky. Perhaps customers receive different answers depending on whom they ask.
Those are different problems.
They may all sit beneath a large word such as communication, but people do not experience large words. They experience moments.
Someone receives an instruction and does not know what “done” means. A manager assumes silence means agreement. A customer waits three days because two departments each thought the other one had replied.
Now we can see something.
And when we can see the problem happening, we can begin investigating whether it deserves something built around it.
The first explanation is not always the problem
I once worked with a company that wanted help with team building. The visible concern was low team morale.
That was easy to accept. If morale was low, perhaps the organization needed activities that created energy, connection, and teamwork. We could have started designing from there.
Instead, we kept investigating.
Why did people seem disengaged? One explanation was that some employees felt undervalued. Why did they feel that way? One branch of the conversation pointed toward the quality and frequency of feedback they received from managers. As we looked further, questions emerged about how managers gave feedback, what structures supported them, and whether developing that capability had been treated as an important part of their work.
That did not magically prove that we had discovered the root cause of low morale.
Real problems are rarely that cooperative.
One why can produce several plausible answers. Different people may see different parts of the same situation. Workload, leadership behavior, recognition, unclear priorities, working conditions, team relationships, or other factors might also deserve investigation.
What mattered was that we stopped treating low morale as enough of a diagnosis to build against.
The investigation gave us a stronger place to work.
One important path led toward how managers gave feedback. That path was specific enough to examine, change, and test in actual work.
This is one reason I still use the 5 Whys in workshops. But I do not expect the fifth answer to magically hand me the truth. I allow plausible explanations to branch, compare what people are seeing, run another iteration when necessary, and look for the explanation that increasingly fits the evidence.
The discipline is not counting to five.
It is refusing to stop at the first convenient explanation.
Do not become attached to the explanation either
Builders know that becoming attached to a solution can cause trouble.
There is another attachment that is easier to miss: becoming attached to your explanation of the problem.
You see employees missing deadlines and decide they lack accountability.
Customers keep asking questions and you decide the website needs more information.
People do not use the new system and you decide they resist change.
Sales are slow and you decide you need more marketing.
Perhaps.
But those are explanations, not observations.
An employee missing a deadline is something you can observe. “Lack of accountability” is a story about why it happened. Customers repeatedly asking the same question is observable. “The website needs more information” is already a proposed explanation and solution.
The distinction matters because once you become attached to an explanation, you begin building around it.
A workshop for accountability.
More pages for the website.
Change-management training.
A larger marketing campaign.
The project can become expensive before the explanation has earned your confidence.
A useful aha is not a verdict.
It is a hypothesis worth testing.
The Familiar Play is to start with what we know how to make
Builders naturally begin from their capabilities.
A trainer sees a workshop. A writer sees a book. A software developer sees an app. A consultant sees an engagement. A content creator sees a video series. An entrepreneur sees a product.
There is intelligence in this. You should use what you know. Existing capabilities make building faster, cheaper, and less risky.
But expertise can also become a pair of glasses you forget you are wearing.
If I have spent years designing workshops, I can easily assume that a learning problem needs another workshop. Yet sometimes people already know what to do. The difficulty may be the system, the incentives, the tools, the manager, the workload, a confusing handoff, or the absence of a simple practice they can use when the moment arrives.
Building from capability asks:
What can I make?
That is a useful question later.
It is dangerous when it comes first.
The cost is not only wasted money
When we solve the wrong problem, we usually notice the obvious costs first.
Money gets spent. Time disappears. People work on things that do not produce the intended result. Features accumulate. Programs become larger. Marketing becomes harder because the builder must keep persuading people why the thing matters.
But there is another cost I find more interesting.
You can become very good at building something that should never have become this large.
That can happen to an individual as easily as to a company. You can spend years improving a service people rarely need, writing a book around a question readers are not asking, or maintaining a project because you have already invested too much to reconsider it.
The problem becomes even harder to question when other people have joined the project. There are now deadlines, budgets, meetings, roles, and reputations connected to it. What began as an idea has acquired weight.
Effort does not rescue a poorly chosen problem.
Sometimes it makes the mistake more expensive.
The real enemy is solution attachment
The enemy is not having ideas.
The enemy is becoming so attached to a solution that new information is no longer allowed to change what you intend to build.
This often becomes stronger after the project becomes public. You have told people you are writing the book. You bought the domain. You announced the program. Your team has spent three months building the system.
Now evidence becomes inconvenient.
Customers tell you they do not need the feature, so you explain why they should. Participants cannot use the framework, so you add more explanation. The problem appears to be somewhere else, but changing direction feels like throwing away everything already invested.
The builder begins defending the creation instead of serving the problem.
That is why the first discipline of building is not creativity.
It is seeing clearly enough to let reality disagree with you.
Change the question
Instead of beginning with:
What should I build?
ask:
What is happening that deserves to become different?
That question pulls you toward reality.
Who is experiencing the situation? What are they trying to do? What keeps happening instead? When does it happen? What does it cost in time, money, effort, trust, opportunity, confusion, delay, or something else that matters?
You are not looking for misery so you can manufacture a market.
You are looking for a difference worth making.
And not everything worth building begins with something painfully broken.
Sometimes the opportunity is a possibility that does not exist yet.
A teacher may see that students have stories but nowhere for those stories to reach readers. A parent may realize the family has stopped spending uninterrupted time together. An artist may notice that people in the community rarely encounter local work. An employee may see a simple tool that would make everyone’s weekly reporting easier.
Nothing has to be catastrophically wrong.
Something worthwhile could become possible.
That can also earn a project.
A problem worth solving has a person inside it
“Education needs improvement” may be true, but you cannot build against it.
“Filipino entrepreneurs need more support” may also be true, but it is enormous.
“Managers need leadership skills” gets closer, yet it still does not tell you what to build Monday morning.
Move closer.
A first-time supervisor is about to delegate a task but keeps taking the work back whenever the employee struggles.
Now we can see someone.
A small business owner answers the same customer questions through Messenger every evening because the information customers need is scattered across several places.
Now we have a recurring moment.
A teacher has students capable of writing useful stories, but their work disappears when the class ends because there is no place where readers can encounter it.
Now we see a possibility worth creating.
The closer you move toward a real person and a real moment, the harder it becomes to hide behind impressive abstractions.
Look at the cost of leaving it alone
Some problems are real but do not deserve a project.
That distinction matters because builders can become fascinated by almost anything that can be fixed.
A process contains three unnecessary steps. A website could look cleaner. An app could have another feature. Your community could hold another event. Your book could contain another chapter.
Possible does not mean necessary.
Ask what happens if nobody solves this.
Does someone keep losing hours every week? Does confusion repeatedly create rework? Do customers abandon the process? Does somebody lose access to something important? Does a meaningful opportunity remain unavailable? Does the same frustration return often enough that people have already invented awkward ways around it?
The consequence gives the problem weight.
You are looking for evidence that the situation spends something people actually care about.
Listen for workarounds
One of my favorite signs that a problem deserves investigation is that people are already trying to solve it badly.
They keep a handwritten list because the official system cannot show what they need.
They copy the same answer from an old Messenger conversation every time a customer asks the question.
They create personal spreadsheets because the official report arrives too late.
They ask the same colleague for help because nobody has documented what to do.
They put sticky notes on a monitor because the software does not remind them at the moment that matters.
A workaround contains evidence.
Someone cared enough about the problem to invent a move.
Do not immediately assume your job is to replace the workaround. Sometimes the workaround is already good enough. Sometimes it shows you that the problem does not justify a larger solution.
But pay attention.
People often reveal what matters through what they repeatedly do long before they describe it clearly in a meeting.
Worth solving does not mean you must solve it
You can recognize an important problem without becoming responsible for all of it.
Poverty matters. Education matters. Mental health matters. Climate change matters. Employment matters. The future of work matters.
These can become so large that saying you want to “solve” them sounds meaningful while giving you almost no guidance for what to do next.
Ownership needs a boundary.
Ask what part of the situation you are actually positioned to influence through your experience, access, skills, relationships, resources, or willingness to learn.
You may not fix education. You might create a reading practice that helps thirty students read every day.
You may not solve unemployment. You might build a way for one group of workers to show employers skills that currently remain invisible.
You may not transform the entire culture of an organization. You may help managers change one recurring moment where employees currently learn that speaking up is unsafe.
Ownership does not require pretending everything is within your control.
It asks:
What part of this can become my move?
You do not need a world-sized solution to serve a human-sized problem.
Do not hide the solution inside the problem
Listen carefully to the way people describe problems.
“We need a leadership workshop.”
“We need an app.”
“We need a new website.”
“We need to publish a book.”
None of those is a problem yet.
Each one already contains a proposed solution.
Once the solution enters the problem statement too early, every investigation begins pointing back toward what you already wanted to build.
Remove it.
Instead of “We need a leadership workshop,” describe what leaders are doing, what keeps happening, and why it matters.
Instead of “We need an app,” describe where people currently struggle and what makes the existing process difficult.
Instead of “I need to write a book,” ask what idea, decision, practice, or possibility you believe readers need help with.
A good problem can survive without knowing the product yet.
That gives the builder room to discover what should actually be made.
Let the problem earn the project
Before you build, see whether the problem can pass a simple test.
Can you point to a person who actually experiences it?
Can you describe a moment when it becomes visible?
Can you name a consequence that makes leaving it alone matter?
Can you find evidence beyond your own assumption—repeated incidents, workarounds, requests, behavior, observations, or other signs that something real is happening?
Can you identify possible explanations without becoming attached to the first one?
Can you define your boundary—the part you may realistically be able and willing to change?
And can you describe all of that without hiding your preferred solution inside the problem?
You do not need perfect certainty.
You need enough reality to justify the next investigation.
Try the Problem Worth Solving Play
Take one thing you have been thinking about building.
For the next ten minutes, put the product aside.
Write:
________ is trying to ________, but when ________ happens, ________. This matters because ________. The part I may be able to help change is ________.
Do not make it elegant.
Make it observable.
Suppose you want to build a course for new supervisors. You might write:
A new supervisor is trying to give meaningful work to former peers, but when deadlines become tight, she takes difficult tasks back instead of helping people work through them. This matters because she becomes overloaded while the team remains dependent on her. The part I may be able to help change is the moment when she decides whether to take the work back or help the employee find the next move.
That is very different from:
I want to build a supervisory course.
Now you have a person, a moment, a recurring pattern, a consequence, and a possible place where your contribution can enter.
Do not build the entire solution yet.
Investigate.
Ask what else could explain what you are seeing. Talk to people who live with the situation. Look for where their answers agree and where they branch. Notice what they already do when the problem appears.
Let reality make the statement more accurate.
An explanation has to earn the next move too
You may begin believing you understand the problem and discover that you do not.
That is useful.
Perhaps the situation is less important than you assumed. Perhaps another problem sits beneath the visible one. Perhaps several conditions reinforce each other. Perhaps people have already solved the problem in a way you had not noticed.
Perhaps your favorite explanation becomes weaker after you talk to someone closer to the work.
Good.
The purpose of investigation is not to protect the project.
It is to improve the next move.
When an explanation begins connecting several observations, treat it as a stronger hypothesis. Then ask what small change would allow reality to answer it.
If the change produces movement, the explanation gains credibility.
If nothing changes, investigate again.
If one part improves while another problem remains, you have learned that the explanation was incomplete.
This is not wasted effort.
This is building before the expensive building begins.
The first win is clarity about what deserves building
You have not built the product yet.
That is fine.
The first win is being able to describe a problem clearly enough that someone who lives with it can say:
“Yes. That is what keeps happening.”
Notice what that gives you.
You are no longer inventing for an imaginary audience. You know whom you are trying to help. You can see the moment where the problem appears. You understand why leaving it alone matters. You know which explanations deserve further testing and where your contribution may realistically begin.
From there, a different question becomes possible:
What should become possible instead?
That is where Start With a Promise, Not a Product takes the work next.
But do not hurry there.
A clear promise built on a poorly understood problem is still a weak foundation.
Follow the proof
This week, choose one problem you think deserves something built around it.
Do not sell the solution yet.
Look for the situation.
Talk to people who actually experience it. Ask what happens when the moment arrives, what they currently do, what makes that response seem reasonable, what the consequence is, and what they have already tried.
Listen especially for contradictions.
If one person gives you one explanation and someone else gives you another, do not rush to decide which one is correct. Ask what each person can see from where they stand. Follow the branches that keep appearing. Look for evidence that strengthens or weakens them.
Then decide what the problem has earned.
Perhaps it has earned a first experiment.
Perhaps it has earned another week of investigation.
Perhaps it has earned nothing more from you.
Walking away can be a useful result. You may have saved yourself months of building something that did not need to exist.
But if you can point to a real person, a real moment, a consequence that matters, evidence that the situation deserves attention, and a part you genuinely want to help change, you now have something more valuable than an exciting idea.
You have a problem worth serving.
And now the project can begin to earn its shape.
Next Steps
Return to Build Something when you want to see the complete movement from an important idea to something real, useful, tested, and shaped by proof.
Read 5 Whys: Don’t Stop at the First Explanation when the visible problem is clear but you need to investigate the explanations beneath it without forcing everything into one neat causal chain.
Continue to Start With a Promise, Not a Product when you understand the problem well enough to ask what should become possible for the person you want to serve.
Use Build the Minimum Lovable Version when the problem and promise are becoming clear but the solution has grown too large to test.
And when several worthy problems are competing for your attention, go to Choose What Matters and decide which deserves your commitment now.
Do not make your idea earn people’s attention. Let the problem earn your project.