When everyone can build, the differentiator is understanding
I’ve spent the last decade in software — starting at an agency, growing a team, moving into engineering leadership, and eventually making a full transition into product management. Each stage felt like a natural progression at the time. Looking back, they trace a line that points somewhere interesting for anyone building software companies right now.
The observation is simple, and I think it has real implications for how startups should think about their edge: AI is making the cost of building software collapse. And when building gets cheap, the questions that were always important but easy to defer suddenly become the only ones that matter.
The arc
Agency work teaches you execution. You learn to translate a client’s request into something working, on time, within scope. The craft is real and the discipline is valuable. But the feedback loop is short and someone else is always defining the problem.
Moving into a product company — one with a real user base, real retention problems, real competitive pressure — changes the questions you’re allowed to ask. Suddenly “can we build this” is the easy part. The hard part is “should we, and for whom, and what does success actually look like.”
I was an advocate of product-minded engineering for years before I formally moved into product. The industry was already signaling it — shifting left, team topologies, product-led growth. The message underneath all of it was the same: the people closest to the code need to care about the outcome, not just the output. When I finally made the full transition to PM, it wasn’t a departure from engineering. It was the logical conclusion of taking that idea seriously.
The shift that’s happening now
AI changes the economics of building faster than most org structures can respond to. A PM with a technical background can prototype a full interface before the first design review. An engineer can ship a feature that would have taken a sprint in an afternoon. A small team can now do what used to require a large one.
That sounds like good news — and it is, for execution. But it surfaces a problem the industry has been papering over for a long time: most teams are much better at building than they are at understanding what to build and why.
When building was expensive, being slow to validate an idea had a natural excuse. Now it doesn’t. The cost of exploring is low enough that there’s no reason not to test assumptions early, show prototypes before specs are written, and involve the people who understand the problem domain before a line of code is committed. The teams that do this well will move faster and waste less. The teams that use AI to simply execute faster will just build the wrong thing more efficiently.
The prediction
When every startup can spin up an app in a weekend, the product itself stops being the moat. The moat becomes the depth of understanding behind it — the domain knowledge, the user relationships, the judgment about which problem is worth solving and which solution actually fits.
This is not a new idea. It’s what good product thinking has always been about. What’s new is that AI is removing the last excuse for not doing it. The barrier was never really technical. It was always about whether teams were willing to slow down enough to understand the problem before rushing to solve it.
The companies that will differentiate in the next few years are the ones that treat that understanding as the actual work — and use AI to handle everything else.
