top of page

🚩 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. 


ree

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:


  1. Start with the pain, not the patent 🚩

  2. Define the system, not just the symptom 🌌

  3. Quantify urgency 🚨

  4. Validate before you build

  5. Avoid “interesting” problems


Below you can find a framework to support you in navigating each of the items mentioned above.

          Want to read more?

          Subscribe to thedeeptechcompass.com to keep reading this exclusive post.

          bottom of page