Ask HN: Should hard-tech founders join a problem or technology-first PhD lab?
I'm an engineering undergrad considering pursuing a PhD with the long-term goal of founding a hard-tech startup. I’m undecided about the specific area and only have a vague sense of what interests me -- industrial decarbonization, mining / mineral processing, and advanced materials are a few areas that currently seem exciting.
However, I'm unsure which type of PhD lab would provide better preparation: either a problem-first lab (e.g., like Yet-Ming Chiang at MIT) or a technology-first lab (e.g., your typical academic lab that focuses on novel science without a predetermined application, and where commercialization happens largely by chance — when a technology happens to have a valuable market application).
I've looked at advice online from successful hard-tech entrepreneurs, but the answers are conflicting. Some say to work backwards from a problem, but others argue that problem-first approaches often don't work since deep tech is inherently different: you often can't force a scientific breakthrough for a predetermined problem. Instead, they argue that most hard-tech companies are only founded because somebody made a scientific breakthrough and realized afterwards that there might be a commercial application. Indeed, the VC firm Pillar VC says that most deep-tech companies they know were "technology-first."
With that in mind, does anybody have any advice on which type of PhD lab to join?
In my totally uneducated opinion as a founder working on winding down my software company that can't differentiate anymore and considering finding someone in hard tech to partner with, I think problem first is a mistake. Problem first is appropriate for a business, but for a lab, I think it should be organized around the art of possible, deep specialization and capabilities first. You never know what valuable things will come out of that process. Once you have something promising, you can match it to problems and make a business case working backwards from you. Generally startups are the opposite, you want to organize them around a customer and a problem, but fundamental R&D != startups.
How does R&D get revenue? I don't know how it is for hard tech, but from my understanding of these "researchy small team" labs in software, what ends up happening is that you find a bunch of small contracts to solve, throw really smart people at it, with the intent that you slowly build up internal core tools on the contract's dime. It's much less "hey someone gave us a bunch of money, let's explore this core thing" rather than almost "grifting" in a sense (well, it's not grifting because you provide value, you provide the service, but it's not the idea of "pure applied research" anymore on your end).