🚩 The Hardest Challenge of Building a Deep Tech Venture is … Making Sure You Are Solving the Right One!
Many deep tech ventures start with a research breakthrough: a material, an algorithm, an improved process. The problem with this is that too often, the problem it solves is defined after the technology exists.
In deep tech, the problem–solution fit isn’t about what’s possible in the lab; it’s about whether the pain you’re addressing is urgent, valuable, and worth waiting years (and millions) to solve. Plus, in a world filled with rapid innovation cycles, it also matters whether you are targeting an opportunity others have neglected, and if you are significantly (and quantifiably) better than other potential competitors.
My recommendation is always to look for the root cause of the problem you think you are trying to solve. More often than not, what looks like a “problem” is often just a symptom of a deeper structural issue, for example: inefficient infrastructure, outdated regulations, broken incentives, or missing technology enablers. Solving the symptom may win you a few customers, but solving the root cause can change an entire market. The key is to ask why repeatedly until the answer stops being technological and starts being systemic. That’s where enduring deep tech companies are born.
Take desalination, for example. Many startups approach it as a cost problem: “How can we make desalination cheaper?” But if you look deeper, real constraints aren’t just energy efficiency; it includes brine disposal, infrastructure financing, and regulatory inertia. A cheaper membrane doesn’t fix those, but a business model that integrates waste valorization or modular financing might. The key is to ask why repeatedly until the answer stops being technological and starts being systemic.
That’s where enduring deep tech companies are born. From my time working at Deep Science Ventures, and contributing to the development of first-principle based ventures like NanoWeave, Lilliput, and New Water Labs, I’m a firm believer of defining a good problem first to ideate a great solution later.
But what happens if you are already thinking about a particular solution? Then before anything else, I’d recommend you validate you are working on the right solution, not to mention the right problem:
Start with the pain, not the patent 🚩
Define the system, not just the symptom 🌌
Quantify urgency 🚨
Validate before you build ⛯
Avoid “interesting” problems ⛔
Below you can find a framework to support you in navigating each of the items mentioned above.
1️⃣ Start with the pain, not the patent
Who experiences this problem most acutely?
What are they losing — money, time, reputation, resources — because it’s unsolved?
How are they solving it today, and what does that cost them?
If you can’t name a stakeholder and quantify their pain, you’re building around curiosity, not necessity. “Cool” science doesn’t guarantee a market; pain does.
2️⃣ Define the system, not just the symptom
In deep tech, problems live inside systems — energy grids, agricultural chains, supply networks. Mapping where the problem sits in that system clarifies:
Which players have the most to gain (or lose) from change.
Who controls adoption (buyers, regulators, intermediaries).
Where inertia or regulation will slow you down.
A well-defined system view transforms a scientific challenge into a business hypothesis.
3️⃣ Quantify urgency
How fast are customers trying to replace the status quo?
How expensive is inaction over the next 12–24 months?
What external drivers (policy, cost curves, climate pressure) make this problem unavoidable?
If your problem depends on wishful timing — “someday the market will care” — it’s not urgent enough.
4️⃣ Validate before you build
You don’t need a finished prototype to test a problem. You need evidence that people are trying to solve it already — through workarounds, stop-gap tools, or costly inefficiencies.
Ways to validate:
Customer discovery interviews (structured around pain intensity, not product features).
Willingness-to-pay signals (letters of intent, data-sharing agreements, pilot commitments).
Comparative benchmarks: are competitors raising capital or being acquired to solve the same issue?
Validation isn’t about surveys; it’s about evidence of economic pain.
5️⃣ Avoid “interesting” problems
“Interesting” problems attract researchers. “Painful” problems build companies.
Every deep tech founder faces the temptation to chase what’s intellectually novel. But investors and customers reward relevance, not brilliance.
The best ventures pair scientific edge with market inevitability — solving a problem that someone, somewhere, must solve now.
In short
Before investing years of research, talent, and capital, ask yourself:
What is the root cause of the problem I'm tackling? Is my solution the best possible solution to this problem?
If the answer is vague, it’s not the right problem. If the answer is measurable, you’re already halfway to product–market fit.
Comments