LLMs are a revolution in cofounder relationships
Specifically, the technical/nontechnical divide
Typically, I think of product development as three stage cycle.1 They are:
Design
Build
Evaluate
The design stage is where you decide what you want to do. The build stage is where you actually create the product. The evaluation stage is more than just testing — it’s deciding, as a company, whether you like the results and whether you go back to the drawing board. If you’re doing a startup the right way, you’re also shipping early, so it will feed into your KPIs too.
In the earliest stages of a company, there is a common division of labor between technical and nontechnical cofounders: these stages end up looking like a sandwich. The nontechnical cofounder only really gets involved in the first and last stage, and the technical cofounder often handles the middle by themselves. Think Jobs and Wozniak: pretty separate roles with different strengths and parts of the process.
Both founders are involved in the design stage because the founders are both involved in the idea. Sometimes, you have a nontechnical cofounder who has some type of subject matter expertise, say a designer or lawyer, in which case their involvement in the design phase is even more critical because they have some type of special insight that goes into the spec.
The nontechnical cofounder is especially critical in the last phase too. While both founders need to be happy with the end product, often the nontechnical cofounder is driving sales, marketing, and other external functions that drive the objective inputs to the evaluation stage. And like before, if the nontechnical cofounder has some type of expertise, their input is particularly valuable in understanding the output and evaluating it.
But the the middle, building, is usually a solo task for the technical cofounder. The lack of involvement of the nontechnical cofounder in the building phase creates issues. The most obvious one is that, especially in the early days, the technical cofounder is even more understaffed and might have to do everything themselves. But most critically it’s a source of tension. The nontechnical cofounder isn’t involved in building, so they fail to develop empathy for what it means to build, making unrealistic asks and getting frustrated when things are harder than expected (especially with unexpected delays; it is difficult to get an intuition for what is “hard”). The technical cofounder sometimes feels like they are working on the only thing that actually matters and develops a sense of superiority, leading to myopia in building and resentment at being told what to do.2 This can boil over, and indeed, cofounder conflict is one of the top reasons early stage startups die.
LLMs change this in an important way: nontechnical founders, for the first time, are involved in the build phase.
With LLMs, the technical founder has lots of new things to do. There are vector databases to maintain, representations to manage, tuning to orchestrate, and more. But there are also prompts to engineer. Unlike everything else on this list, prompt engineering is done in pure English, so the nontechnical cofounder can actually get involved. From a pure division of labor perspective, divide-and-conquer logic alone can get the nontechnical cofounder involved in building.
In cases where the nontechnical cofounder has expertise, it is actually an advantage to assign the prompt engineering to them. They are the ones who are best equipped to translate their knowledge directly into prompts and quickly iterate based on the output. Plus, even the most nontechnical founders can learn at least a little Javascript or Python to create dynamic prompts. Suddenly, you will have nontechnical cofounders coding up full-fledged features alongside their technical partners.
The sandwich is thus transformed into a meatball where everyone is involved in the entire product process. This is better overall. The best founding teams are ones where everyone has at least some understanding and empathy for the entire process. This new paradigm will contribute to a whole new set of nontechnical founders who are more involved, more useful, higher agency, and more informed throughout the product development cycle. That’s better for the whole startup and the cofounder relationship as well.
Obviously, at a startup, everything bleeds together and is iterative. But this is still a useful way to think about the order of operations, roughly.
For the record, I have been blessed with a cofounder who does not think this way and has never made me feel this way. But this is an issue I’ve seen before, even if never stated explicitly.