My conversation with Dillon Mulroy kept pulling me back to one phrase: make pain painful.
What I mean by that is simple. If your users are hurting, you should feel it too. If support is carrying recurring pain for your product, that should be visible to engineering. If customers are falling off during onboarding, that should not stay hidden in a dashboard no one checks. Dillon's version of product engineering is not just "care more." It is building the systems and habits that make care unavoidable.
Care Has To Become a System
Dillon has worked on everything from back-office tooling to developer platforms, and one of the things I liked most about this episode is that he did not reserve product thinking for flashy products. He talked about sitting with people using painful internal tools and wanting to make those workflows better simply because the pain was so obvious once you saw it.
That thread kept showing up in different forms throughout the conversation:
- observability
- customer interviews
- escalation reports
- onboarding metrics
- support conversations
None of those are glamorous on their own. Together, they become a feedback system.
Foundations Before Delighters
Another thing Dillon made clear is that good product engineering is not just about sprinkling in delightful touches. You need foundations and primitives first. If the core path is broken, confusing, or hard to trust, then surface-level delight is not going to save you.
I liked that because it puts product sense much closer to engineering judgment than a lot of people assume. The more you understand the system and the more clearly you can see where it is failing people, the better your decisions get.
The Best Homework in the Episode
If your company has a support team, go sit with them for a day.
That was one of the clearest takeaways in the conversation, and I think it is excellent advice. Dillon described support orgs as sitting on a gold mine of product information, and that feels exactly right to me. They see the recurring friction, the repeated confusion, and the problems users are motivated enough to report.
So the practical version of "make pain painful" is this: close the gap between engineering and the people who feel the product most directly.
