Product Engineering - Back to the Basics

It's funny how advice goes in circles. Lately there's been lots written about "Product Engineers." Now that AI makes coding faster and cheaper, the advice goes, engineers must look beyond writing code and get involved in product decisions—understanding how features impact the user experience and the business.

Only, that sounds awfully similar to what agile software development was supposed to be about. Engineers were always meant to be problem-solvers first, with tools and methods coming second.

What happened? "Agile" got hollowed out and software engineering became software delivery. The product owner orders code and gets it delivered, with the delivery person having neither care nor clue about the final purpose—the way your DoorDash driver couldn't care less what food you ordered and why.

Building software well requires deep understanding of what it's going to be used for. This is especially true when building for non-technical stakeholders: you know the business purpose, but you can't weigh the technical trade-offs. That's the engineer's job—and it only works if they understand your problem as well as you do.

AI has sharpened this reality. When writing code gets cheaper, the bottleneck shifts to judgment: knowing what to build and why. The engineers who thrive now are the ones who were always thinking this way.

For founders, that's good news. The industry is rediscovering what good engineering looks like—which makes it easier to spot. When you're evaluating technical help, ask how they'd approach understanding your problem before writing a line of code. If the answer jumps straight to tools and frameworks, you're talking to a delivery driver.