The real work in software engineering is deciding how to represent all the details of the problem and its solution - the rest is just typing. The ability to understand abstract systems in this way is very rare. For most people, computers are magical objects that they don't understand. You can't ask people what problems they have that you could solve with a computer because they have very little idea of what computers are capable of: you can't talk about a concept of an app, you have to build it and put it in front of them before they can contribute to a conversation about it.

The days when a successful startup could be founded by a person who makes the thing and a person who sells the thing are over, because all the obvious ideas have been done. You need a third founder: the person with deep domain knowledge who knows what problems exist and which ones are worth solving.

I think the PULL framework in the post is an unnecessary formalism. My advice for finding ideas is to get out of the ecosystem of companies in the Big Tech or Silicon Valley traditions and go and work for tiny little companies where all the office staff work in the same room and your job is to modernise a C++ application that has a hard dependency on Microsoft Office 2003 and runs on a VM running Windows XP (which was the first programming job I got when I left teaching in 2021). Those businesses are full of problems that are easily solved with computers, but no one who knows how to solve those problems has discovered those problems yet.

> My advice for finding ideas is to get out of the ecosystem of companies in the Big Tech or Silicon Valley traditions and go and work for tiny little companies where all the office staff work in the same room and your job is to modernise a C++ application that has a hard dependency on Microsoft Office 2003 and runs on a VM running Windows XP (which was the first programming job I got when I left teaching in 2021). Those businesses are full of problems that are easily solved with computers, but no one who knows how to solve those problems has discovered those problems yet.

Agreed. Except: smaller companies tend to have much smaller budgets and be less tolerant when it comes to software pricing.

I would also say from experience that there is either a lot of commonalities in the types of issues that these companies face OR they have some very unique needs. In the former case one might as well abstract away and try to attack these problems in the general case. In the latter we need to hope that the niche can be big enough to be profitable.

Agree with so much of this!

Would just add that the best sales people have usually been folks with deep domain expertise, partially because they tend to have a pre-existing social network of potential users due to their work.