I talked with Swizec Teller about product engineering for software that serves real businesses and non-developer users.
Swizec has spent years building in biotech, healthcare, and other domains where the user is trying to get work done, not admire your architecture. That made the conversation feel grounded in observation: shadowing experts, noticing workaround behavior, understanding existing habits, and putting new capabilities where people already look.
Learn the domain by watching work happen
A theme I appreciated is how much product sense comes from watching people use software in context. When you do not grow up inside a domain, you have to earn the mental model. Swizec's approach is practical: spend time with the people doing the job, notice friction they have learned to live with, and treat every workaround as a clue.
That is different from building for developers, where the user often shares your vocabulary. For many product engineers, the hard part is not implementation. It is understanding what "better" means for someone whose job is not software.
Define success before you ship
The second half of the episode turns that observation into a product loop. Swizec and I talked about defining success before you ship, measuring whether a workflow actually improved, and balancing long-range vision with what today's technology can support.
Software is valuable because of the user's new superpower, not because the implementation was clever. That line stuck with me. It is a good filter when agents make it tempting to build impressive things that do not change outcomes.
