One reason I wanted to talk with Jamon Holmgren is that he has spent years in a version of software work that forces product problems into the open. When you are building with clients, stakeholders, and teams who are not all technical, you find out pretty quickly whether the problem is actually understood.
That made this episode feel especially practical to me. Jamon was not talking about product engineering as a trendy label. He was talking about the day-to-day realities that make projects succeed or fail: bad requirements, missing feedback loops, UX details nobody owned, and teams optimizing implementation before they had enough clarity.
The Work Before The Code
One of the ideas I kept coming back to in this conversation is that product engineering has a lot to do with translation.
Jamon described the role as a bridge between stakeholders who do not have the technical context and the implementation work that eventually has to happen. That means more time gathering requirements, demoing, testing, reviewing, and tightening the spec before you disappear into code. It also means not treating stakeholder feedback as noise. The successful projects he described were the ones where the team insisted on getting the software in front of the right people early enough to learn from it.
That landed for me because it is easy to hear “implementation is getting cheaper” and assume the hard part is going away. But in practice, cheaper implementation just makes fuzzy thinking more expensive. If the requirements are weak, if the wrong stakeholder is driving everything, or if the people who actually use the software were never brought into the conversation, you can move fast in exactly the wrong direction.
Durable Skills Are Human Skills
Another part of the conversation I appreciated was how Jamon framed durability. The long-term value is not just getting better at a single tool or workflow. It is building judgment that survives tool shifts.
That shows up in a few different ways here: noticing when requirements are really just solution guesses, knowing when to slow down instead of piling on complexity, and being willing to spend time on UX and polish because those details decide whether software feels trustworthy to the people using it. Jamon also made a strong case that experienced engineers still have a meaningful role in an AI-heavy workflow because they can translate between the human problem and the shape of a good implementation.
I thought that was a helpful way to put it. Product engineering is not some soft skill detour away from engineering. It is the part that helps technical knowledge land in the right place.
The Best Homework In The Episode
The clearest takeaway in the whole conversation came at the end: sit down with a non-technical person and watch them use something you built.
I like that advice because it is so concrete. You do not need a research org or a fancy process to learn something useful. You just need to pay attention. Watch where they hesitate, where they double-click, where they get ahead of the interface, where they assume something should work differently, and where they recover in ways you never intended. That kind of observation will usually teach you more than another round of abstract debate about what users “probably” want.
