Ask why in every PR - product engineering with Erin Fox
· Summarized
Key takeaways
- Always question the 'why' behind every feature or change to ensure it addresses the right problem.
- Trust in engineering teams can be maintained and strengthened through clear communication, understanding user pain points, and building relationships.
- Engaging with stakeholders by understanding their goals and aligning engineering efforts with those goals leads to more effective product development.
- Foundational software principles like clear patterns and thoughtful system design are still crucial, even with the rise of AI agents.
- The roles of engineers are evolving towards more integrated positions, blending technical expertise with product and business understanding.
- A practical step to improve product quality is to include or ask for the 'why' in every pull request, fostering a culture of purpose-driven development.
Summary
The Importance of Asking Why in Product Development
This section emphasizes the foundational value of questioning the 'why' behind every feature, change, or bug fix. Erin Fox advocates for treating each new feature as a mini product, which involves understanding its purpose, the associated metrics, and its impact on the user. Asking 'why' not only clarifies the purpose but also helps prevent unnecessary work, especially in the context of AI-generated pull requests, where the rationale might be missing. The key is to ensure that every change is deliberate and well-understood, thus fostering trust and more meaningful product development.
Trust and Communication in Software Engineering
Fox discusses how trust in engineering teams has been challenged by the rise of AI tools that generate code and PRs. She highlights the importance of clear communication, understanding user pain points through metrics and community feedback, and telling stakeholder stories in terms they understand. Developing strong relationships—knowing personal details and goals—enhances trust and makes it easier to align efforts. The section underscores that excellent communication skills are crucial for standing out as a product engineer.
Engaging with Stakeholders and Understanding Goals
This section explores strategies for effective stakeholder engagement. Erin recommends directly asking managers and team members about their objectives, aligning engineering efforts with those goals, and building trust through honesty and relationship-building. She advocates for a collaborative approach where engineers help stakeholders see their goals are aligned, thereby breaking down 'fences' and fostering a team-oriented mindset. This approach enhances cooperation and ensures that engineering work genuinely meets business needs.
Design Principles and System Architecture for AI-Assisted Coding
Fox emphasizes that foundational software principles like avoiding duplication and thoughtful system design remain vital, even with AI agents. She suggests that specifying clear patterns and goals helps steer AI agents, avoiding unexpected large-scale changes or architectural drift. She advocates for explicit communication of expectations and aligning code patterns to support long-term maintainability, illustrating that good design and intentionality continue to be key regardless of automation.
The Role Evolution from Software Engineer to Product Engineer and Beyond
This section discusses how the roles in tech are evolving towards more integrated responsibilities—blurring the lines between traditional software engineering, product engineering, and product management. Fox reflects on the need for engineering skill sets that include domain knowledge, strategic thinking, and user-centric perspectives. She envisions a future where engineers are more involved in understanding business goals, user pain points, and system architecture, positioning the product engineer as a crucial bridge across teams.
Practical Advice and Homework: Asking Why on Every PR
The episode concludes with actionable advice: on every pull request both as a reviewer and creator, explicitly include or ask for the 'why' behind the change. This habit reinforces understanding, prevents blind merging, and cultivates a culture of thoughtful development. Fox emphasizes that this small but powerful step can significantly improve product quality and team communication.
Sponsors
- Epic Product Engineer Podcast · Visit epicproduct.engineer for more episodes and resources.
Show notes
If you are merging beautiful AI PRs without being able to say why the change exists, this episode is for you. Kent talks with Erin Fox about treating every feature like a new product, asking why before you write code, and rebuilding the trust contract that agents quietly broke.
They cover circling back to metrics, using community Slack as a feedback loop, telling a stakeholder story that is not just a migration estimate, and going slower with agents so they do not rewrite your patterns.
- (00:00) - Meet Erin Fox
- (01:40) - A new feature is a new product
- (05:03) - Finding the why before you build
- (07:36) - AI PRs broke the trust contract
- (10:57) - Metrics, research, and circling back
- (14:25) - Community Slack as a feedback loop
- (16:17) - Tell the story stakeholders can hear
- (20:49) - Communications skills as an engineering edge
- (24:12) - Ask your boss their goals
- (27:22) - Go slower with your agents
- (37:50) - Homework: ask why on every PR
Erin Fox is a full-stack engineer who has shipped a React Native MLS soccer app, creator-focused email tools, and plenty of features that felt like launching a product each time. In this conversation, she and Kent dig into what that framing changes: you do not just implement a ticket. You figure out the date, the why, and whether the real fix is a new feature or a two-hour margin change.
A major theme is trust. Erin used to assume a teammate's PR already had the why baked in. AI-generated PRs look great and pass tests, but the why is often missing. Her red flag is simple: if you cannot explain why this change is needed, do not treat passing tests as permission. That same question belongs in the PR template, in stakeholder conversations, and in how you brief an agent - because "fix this bug" will happily change a million things.
They also get practical about feedback loops. Look at the metrics you instrumented. Lurk in community Slack, including accessibility channels, until user pain is not abstract. Then tell the story in language stakeholders care about: not "this migration takes a quarter," but what it unlocks. Erin's communications master's degree shows up here. She asks her manager what their goals are this quarter and treats that as the job.
Homework is small on purpose: on every PR you open or review, write why this change matters.
Homework
- On the next PR you open, add a Why section that a teammate could understand without the ticket.
- On the next PR you review, ask why this change is needed - especially if it looks AI-generated.
- If you cannot answer why, stop and find out before you merge.
Resources
Guest: Erin Fox
Host: Kent C. Dodds
Follow this show on AudioBrevity and new episodes get summarized for you. Create a free account