We Need Product Focused Engineers, Not Just Feature Builders

In my last piece I wrote about a nagging question: are we skipping end user validation now that AI lets us ship features before lunch? The more I sit with that question, the more I think the fix isn't a process, a checklist, or a slower sprint cadence. The fix is who we hire and how we grow the people already on the team.

This is the reason we need product-focused engineers: people who can develop and architect a system, and who also carry the discipline to ask whether what they're building solves the right problem before they start writing code. That's different from engineers who take a work item, build it out exactly as written, and move on to the next card. Product-focused engineers sit close enough to the customer to know when a work item is solving a real problem and when it's solving the wrong one.

That distinction used to matter less, because building software was slow and expensive enough that a lot of validation happened by necessity. A feature took weeks, so there was time for a product manager to dig into the problem, time for a designer to test it, time for the team to catch a bad assumption before too much got built on top of it. AI took most of that time away. It didn't take away the need for the validation that used to happen inside it.

Years ago, I moved out of a product manager role and into an engineering team, specifically to bring product thinking closer to the code, so the reasoning behind a feature didn't get lost between the decision and the build. That move closed the distance between the people building the software and the people who had to live with what it did or didn't do for the customer. AI is pushing every engineering org toward needing that same kind of person, and it's pushing them toward needing fewer engineers overall, which raises the stakes on who those remaining engineers are.

Fewer engineers doing more, faster, only works if the ones left in the room can do more than execute. They need to be in front of the customer, or close enough to someone who is, to catch a wrong assumption before it ships instead of after. They need to spend real time validating and digging into the problem instead of just writing the feature and calling it done. An engineer who can architect a clean system but can't say why a feature matters to the person using it is just going to ship the wrong thing faster.

That's the shift I think matters more than any tool or model upgrade. The engineering org that comes out ahead is the one where the engineers left standing after the shakeout can bridge the gap between the business need and the code themselves, without waiting on someone else to hand them the problem already validated.