Jaime Hing III

Start with a problem, not an idea

I spend some time scrolling through my social media. Aside from finding the next funny meme, which I enjoy, I also see developers announcing their next big thing, and almost all of them start from the same place: “I built X, Y, and Z”. I rarely see: “I keep running into this problem X, so I built solution Y.” That difference matters more than most people realize. Because ideas are exciting, problems are exhausting, and the latter powers startups.

My most expensive mistakes started with ideas

Early in my career, I built things because they sounded smart: interesting systems, elegant architectures, products that looked impressive on paper.

It took me years and a lot of abandoned projects than I'd like to admit to realize that building something "cool" is not the same as building something useful. Useful things get pulled into the world. Cool things have to be pushed.

Engineers are vulnerable to idea-chasing

We, as software engineers, are trained to appreciate elegance. We like clean abstraction, elegant architectures, performance improvements, and interesting technical challenges.

But users do not normally reward elegance. They reward relief. They do not care how clever your system is. They care whether their day gets easier. I am not saying we should build a mediocre system in the long run. Some of the most commercially successful products are just okay, but solve someone else's problem.

A boring solution to a painful problem will outperform a brilliant solution to a trivial one every time.

The problem should annoy you first

If a problem does not personally frustrate you, you will struggle to stay motivated once the excitement wears off. Startups are not just bursts of creativity, or maybe yes, until the motivation wears off. Startups are long stretches of persistence. There will be months where nothing feels exciting, only difficult.

What carries you through that period is not passion for an idea. It is the intolerance of the problem. You keep going because the broken thing still exists.

The shift from builder to operator changes how you see problems

Earlier in my career, I mostly evaluated ideas through a technical lens: Can this be built? Is this elegant? Does this website load in less than 20 milliseconds? Is this scalable? Later, after being responsible for actual outcomes: revenue, reliability, customer trust, payroll, the questions changed to:

• How expensive is this problem today?
• Who is losing money because of it?
• What breaks if this does not get solved?
• How often does this problem occur?
• How desperate are people for a fix?

Operators do not optimize for novelty. They optimize for the removal of pain and friction. Once you have lived on that side, idea-first thinking starts to feel detached from reality.

Validate the pain or problem, not the product

Before building anything, try to understand the problem deeply:

• Who experiences it repeatedly?
• What do they do today to solve or alleviate the pain?
• How much time or money does it consume?
• Are they already paying for imperfect solutions?
• What happens if nothing changes?

If people are already spending effort or money to solve the pain, that could be a signal. If they say, “That would be nice to have,” you might have found noise.

Your best opportunities are probably close to you

You do not need to discover a hidden market in a distant industry. Look at environments you already understand: Your work, hobbies, industry, or community. You already know the constraints, the jargons, and the hidden inefficiencies. People who do not experience the pain see ideas, while others who experience the pain see where things are actually broken.

If you are stuck, stop hunting for ideas

Audit your own life or someone you know:

• What do you or they regularly complain about?
• What activities or tasks feel unnecessarily difficult?
• Where do you constantly and repeatedly lose or waste time?
• What workarounds have you tried to solve problem x?
• What would you gladly pay to eliminate the friction or pain?

Your startup idea is far more likely to come from irritation than inspiration.

Build relief, not just impressive things

Ideas fade when they stop being exciting. On the other hand, problems persist until they are solved. So if you want to build something meaningful:

Don't ask, "What would be cool to launch?"

Ask: "What would people be relieved to never deal with again?"

Relief creates adoption, and adoption creates businesses. The world does not need more clever products. I am not talking about innovation, because innovation is good. The world needs fewer broken systems, and you can start there.

Final Note

Once you identify a problem you want to solve, and think the initial potential market might be small from the start, that's just a start. You validate within your network if the people you talk to are experiencing the same problem, and let them try your solution. Over time, you might find yourself building more features that could solve adjacent problems to the original problem, and that could be one way to grow the market.