For most of my career and generally for any software engineer pre-LLM-coding-agents era, being able to build things felt like a superpower.
\nGive me a problem, enough time, and access to the right tools, and I could usually figure out a way to make something work.
\nThat ability has served me well as an engineer. It has opened doors, helped me lead teams, build products, start companies and turn ideas that existed only in conversations into software people could actually use.
\nFor a long time, I also thought it gave a significant advantage as a founder.
\nI’m beginning to think there is a trap in that.
\nThe best technical founders may need to become less impressed by what they can build.
\n\n\nEngineers are trained to solve problems.
\nWe see friction and immediately start decomposing it.
\nWhat system is responsible?
\nWhat API do we need?
\nCould this be automated?
\nHow should the data model work?
\nWhat happens at scale?
\nThere is satisfaction in taking something messy and turning it into something elegant, refined and structured.
\nBut the business of market solutions doesn’t particularly care about elegance.
\n
A technically interesting problem may not necessarily be an important problem.
\nA difficult problem is not necessarily a valuable problem.
\nAnd a product working exactly as intended is not proof that enough people care about it or want it.
\nI knew all of this intellectually but building has forced me to understand it differently.
\nWhen someone tells an engineer that something is inconvenient, we can hear a product requirement.
\nWhen a prospect tells a founder that something is inconvenient, I’ve learned that the more useful response might be:
\nSo what?
\nHow painful is it?
\nHow often does it happen?
\nWhat are you doing about it today?
\nWhat does doing nothing cost you?
\nWho inside the company cares enough to fight for this to change?
\nWill they pay to make it go away?
\nThose questions are increasingly more interesting to me now than whether I know how to build the solution.
\nThis is another thing I think technical founders have to unlearn.
\nCompliments.
\nYou spend days or weeks building something complicated. You show it to someone and hear:
\n“That’s really cool.”
\n“That’s impressive.”
\n“I can see how companies would use this.”
\nIt feels good.
\nEspecially when you know how much work sits behind what looks like a simple demo.
\nBut I’ve become much more interested in what happens after the compliment.
\nDoes the person immediately start describing where this would fit into their company?
\nDo they introduce someone else who needs to see it?
\nDo they ask how quickly they can start?
\nDo they ask about security or integration because they’re already imagining deployment?
\nDo they try to find budget?
\nDo they actually come back and use it?
\nOr do they tell you you’ve built something impressive and carry on with their day?
\nThose are very different signals.
\n\n\nOne of the more dangerous things about being a technical founder is that … the product can keep giving you dopamine even when the market isn’t giving you validation.
\n
There is always another feature.
\nAnother integration.
\nAnother workflow.
\nAnother architecture improvement.
\nAnother model to experiment with.
\nAnother clever way of solving the problem.
\nAnd because you’re building, it feels like you’re progressing.
\nSometimes you are.
\nSometimes you’re just extremely busy avoiding a much more uncomfortable question:
\nDoes anyone care enough?
\nThat is the question I’m learning to sit with for longer.
\nThe engineer in me still loves building.
\nI don’t think that will change.
\nBut I’m trying to become less impressed by the fact that I can build something.
\nThe more interesting questions now are:
\nShould this exist?
\nWho urgently needs it?
\nWhat changes for them if it works?
\nAnd what evidence do I have beyond the fact that I managed to make it work?
\nMaybe technical ability is most useful when it gives you the freedom to explore a problem quickly.
\nBut it becomes dangerous when it gives you endless reasons to avoid admitting that the problem might not matter enough.
\nSo these days, when I build something and my first reaction is:
\n“This is pretty impressive.”
\nI’m trying to follow it with a harder question:
\n“Yes. But does anybody actually need it?”
\nTill next time, here’s a picture of a Dragon built using Lego in Cardiff
\n