Build the Right Thing: Product Engineering for Software Developers — Part 2

Official Schedule Context

Official Description

There is nothing quite as demoralizing as finishing a feature and realizing you built the wrong

thing. The code is clean. The tests pass. The ticket is closed. And none of it matters. This is

happening more often, not less. AI makes it faster and cheaper to implement, which means teams can

now waste entire sprints on the wrong idea at unprecedented speed. The bottleneck is no longer "can

we build it?" It is "should we build it?" and "are we sure we understand the problem?" This session

is a condensed introduction to product engineering for builders: the skills that sit upstream and

downstream of implementation. We will not try to cover everything a full-day workshop would.

Instead, we will focus on the highest-leverage ideas you can apply on Monday. ### What we'll cover

1. Validate before you build Most wrong builds start with an idea that was never tested. You will

learn to separate real user pain from solution-shaped requests, and practice discovery questions

that surface past behavior instead of hypothetical enthusiasm. 2. Prioritize what deserves to exist

Not every good idea should be built now. Especially in the AI era, "we could build this" is not a

reason to build it. We will work through a practical prioritization lens, including the Kano model,

to help you distinguish fundamentals from delighters from distractions before your team commits. 3.

Own the feature, not just the PR Product engineering does not end at merge. You will leave with a

clearer picture of end-to-end feature ownership: staying close to users, setting up simple feedback

loops, and improving what you shipped instead of moving on to the next ticket. ### Format This is a

2–3 hour session with Kent C. Dodds. Expect focused teaching, real-world examples, and short

interactive exercises and discussion. This is not a full simulation lab or a ticket-closing coding

workshop. It is judgment practice for engineers who already know how to ship. ### Who this is for

Software engineers (and technical builders generally) who: - Have shipped something polished that

nobody wanted - Feel pressure to move fast with AI and want a better filter for what deserves to

exist - Want stronger product instincts without becoming a PM - Care about owning outcomes, not just

closing tasks Some software engineering experience is assumed. No particular stack is required. PMs

and designers often find this valuable too. ### What you'll leave with - Discovery questions for

ambiguous work - A prioritization lens you can use before committing to a build - A clearer model

for feature ownership and post-ship feedback loops - Language for stakeholder conversations when

requirements are unclear

Related YouTube Video

Letting AI Interface with your App with MCP — Kent C Dodds (speaker-match related prior/adjacent AI Engineer video; captions: English auto-captions).

Transcript Status

Related video transcript availability: English auto-captions. Treat this as supporting context, not a recording of this exact scheduled session unless later confirmed. Not fetched yet.

People

Notes

Supporting Slides

Slide Evidence