We spend a lot of time talking about empathy for our users, but some of the most important empathy I’ve seen in software happens between the people building the product.

I’ve spent my career working between Product and Engineering, and today I lead teams across both. Some of the strongest development teams I’ve built aren’t great simply because they have talented engineers, they’re great because those engineers have strong, trusting relationships with Product. They ask questions, challenge assumptions, understand the problem behind the ticket, and know that disagreement doesn’t have to mean dysfunction.

That didn’t happen by accident.

In this session, I’ll share lessons from building those teams and what I’ve learned about closing the empathy gap between Product and Engineering. We’ll look at the relationship from the developer’s side of the table: what Product may be dealing with that Engineering never sees, why developers are often brought in after a problem has already been turned into a solution, and what engineers can do to change that dynamic without becoming Product Managers.

We’ll talk about how to uncover the problem behind a requirement, ask better questions, communicate technical tradeoffs in a way the business understands, and push back without becoming a blocker. Along the way, we’ll talk about what building an elevator where you really needed a ramp can teach us about how Product and Engineering solve problems together.

Because the best developers I’ve worked with don’t just build what’s in the ticket. They understand enough about the problem and trust Product enough to help us build the right thing.