The Problems Worth Building Around

Working across companies changes the way you notice problems.

One client has a messy handoff and it looks like a process issue. A second company has almost the same workaround. Then a third team is paying for three separate tools to patch the same gap.

At some point, the problem stops looking local.

It starts looking like a pattern.

Patterns deserve attention, not immediate companies

We see recurring problems around translating vision into execution, keeping teams aligned through growth, communicating strategy clearly, and connecting knowledge that has been scattered across documents, meetings, and tools.

Those patterns are interesting because they appear in different industries and at different stages.

But recurring doesn't automatically mean venture-scale.

Founders can fall in love with the recognition itself: we've seen this three times, therefore someone should build a startup. The better question is whether people care enough about the problem to change behavior.

Look for workarounds

A frustrating inconvenience produces complaints.

A meaningful problem produces workarounds.

People build spreadsheets. They create strange Slack rituals. They hire someone to manually reconcile information. They pay for multiple products and stitch them together. They create internal documentation around a flaw because they've stopped expecting the underlying system to improve.

Those behaviors are useful signals because they show cost.

Time, money, attention, risk, or frustration is already being spent. The question becomes whether a better solution can earn some of that value.

Durable problems tend to be human

Technology changes quickly. Coordination doesn't.

The software people use to communicate will change. The need to understand who owns a decision won't. AI will reshape how work is produced, but trust, clarity, accountability, and judgment will still matter.

That's why we're especially interested in problems around communication, decision-making, execution, and organizational context.

The tools can evolve aggressively because the underlying need is likely to remain.

Prove the problem before the product

Before writing code, we want to know whether the problem is frequent, painful, expensive, and underserved.

How often does it happen? Who feels it most? What does it cost when nothing changes? What are people doing now? Why haven't existing tools solved it? Is the problem important enough that a team will adopt a new behavior?

Those questions are less exciting than designing the first interface. They're also cheaper than spending a year building a product for a problem people were only mildly annoyed by.

The goal isn't to prove our idea is clever.

It's to prove the problem deserves a company.

The problem has to hold your attention

There's one more test that doesn't fit neatly into market research.

Do we care enough to live with it?

Companies take years. The first version will be incomplete. Distribution will be harder than expected. Customer needs will complicate the elegant thesis. The problem has to remain interesting after the novelty of having an idea is gone.

The best opportunities tend to keep pulling us back. We notice them in other conversations. We keep sketching better ways the system could work. We become more curious instead of less.

That's usually a better beginning than deciding we want to start a company and searching for a problem to justify it.

Start narrow enough to learn something true

When a problem appears across industries, the instinct can be to design for everyone immediately. That usually makes the first product vague.

A better starting point is often a specific group feeling the pain intensely enough to try something new. If founders are losing strategic context as teams grow, for example, the first useful product might serve one stage of company, one recurring meeting, or one transition where that loss becomes obvious.

Narrowing the first use case doesn’t necessarily shrink the ambition. It creates a place where the team can learn whether its assumptions are true. A large market thesis becomes much more useful after a small group of real people has had the chance to disagree with it.

Distribution belongs in the problem

A problem can be painful and still make a difficult business if there’s no credible way to reach the people who feel it. That’s why we think about distribution early.

Where do these people already gather? Who influences the decision? Is the buyer the same person experiencing the pain? Does adoption require changing one person’s behavior or an entire organization’s workflow?

The best product idea in the room still has to travel into the market. Understanding that path is part of proving the opportunity, not a marketing problem to solve after the build.