# Build the Right Thing: Product Engineering (Part 2) Kent C. Dodds, EpicProduct.engineer | AI Engineer World's Fair 2026 | 52:09 Source: https://www.youtube.com/watch?v=s0hFne6EeOI Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/build-the-right-thing-product-engineering-part-2 Published: 2026-10-05 Tags: engineering-culture, product-strategy ## TL;DR - A feature request such as facial recognition is only a proposed solution, so engineers should ask why until they understand the user's job and desired progress. - Functional, social, and emotional needs change the technical decisions a product engineer makes, including whether a solution creates discomfort or privacy concerns. - The Kano model helps engineers match architecture to value by making basic needs reliable, measuring performance needs, and keeping delighters easy to change. ## Summary Kent C. Dodds argues that product engineers need to understand the problem behind a request before implementing its proposed solution. He uses facial recognition for workshop check-in to show how repeated questions can reveal a job statement: help an attendee enter quickly without missing the first 20 minutes. That job could lead to parallel queues, badges, or another approach. Engineers also need to consider functional, social, and emotional effects, since a faster check-in can still make people uncomfortable about facial data. Dodds then introduces the Kano model through a food delivery app. Reliable confirmations are basic needs, delivery estimates have a performance gradient, and discounts or group ordering can delight users. Expectations change, so today's delight can become tomorrow's requirement. These categories should affect technical choices: make foundations reliable, measure performance, and keep experiments reversible. His closing argument is that implementation speed matters less when teams have not chosen a valuable problem. ## Key ideas ### A requested feature is only a proposed solution to a deeper problem [00:50](https://www.youtube.com/watch?v=s0hFne6EeOI&t=50s) Dodds starts with a request for facial recognition in the workshop check-in product. He asks the audience to keep asking why: why does facial recognition matter, and what does it change? The underlying problem is that people need to get into the room quickly and avoid missing the first 20 minutes. He warns engineers not to attach every request directly to the existing product. Each addition creates complexity and long-term maintenance, and a difficult downstream problem might show that the original direction was wrong. Product judgment is needed before implementation. ### Jobs theory turns a feature request into a statement about user progress [05:56](https://www.youtube.com/watch?v=s0hFne6EeOI&t=356s) Using Clayton Christensen's jobs-to-be-done theory, Dodds says people hire products to make progress in a specific situation. He separates the facial recognition request from the job it might support. The job statement becomes: when there is a workshop at 10:10, help me get into the workshop quickly so I can learn about product engineering without missing the first 20 minutes. This framing opens up alternatives such as parallel queues or badges. It also gives engineers a basis for asking a product manager for enough context before designing a system. ### Functional, social, and emotional needs all affect engineering decisions [11:23](https://www.youtube.com/watch?v=s0hFne6EeOI&t=683s) Dodds divides a job into functional, social, and emotional dimensions. Functional needs describe whether the product does the task. Social needs include who is involved and how people interact while using it. Emotional needs include whether users feel excited, embarrassed, shy, or uncomfortable. For facial recognition, the functional design could require a database of faces, encryption, and venue capacity data. Socially, it might involve the person checking attendees and people waiting in line. Emotionally, attendees may feel creeped out that the conference has their facial information, which is a reason to reject the proposed solution. ### Success includes repeated use, not only the initial purchase [20:50](https://www.youtube.com/watch?v=s0hFne6EeOI&t=1250s) Dodds distinguishes the 'big hire', when someone pays for a product, from the 'little hire', when they use it and continue choosing it. He compares the little hire to each bite of a burger: if someone stops eating and throws it away, the initial purchase did not prove that the product worked for them. Product teams should define success by repeated progress where repeat use makes sense. They should ask how progress will be measured, whether the customer will use the product again, and whether a change should be built, instrumented, deferred, or rejected. ### The Mom Test and prototypes can validate ideas before metrics exist [23:54](https://www.youtube.com/watch?v=s0hFne6EeOI&t=1434s) When asked how to decide what to build before a product has metrics, Dodds recommends validating that the problem exists and matters enough for someone to try a solution. The Mom Test helps teams ask about real past behavior instead of collecting polite opinions. A simple prototype can contain paper cuts and still reveal whether people want to use it. At an existing company, the same approach involves talking to customers, understanding the problem, building a prototype, and watching how they respond. Failure to get anyone to try the prototype is itself a signal. ### The Kano model separates requirements by how satisfaction changes [33:09](https://www.youtube.com/watch?v=s0hFne6EeOI&t=1989s) Dodds introduces the Kano model, which places product features against implementation and user satisfaction. Basic needs must work before users are satisfied at all. Performance needs have a gradient, so improving them keeps increasing satisfaction for a while. Delighters can make users happy even when only partly implemented because they were not expecting them. The model also includes indifference, where a feature adds maintenance without user value, and reverse features, which users actively dislike. These last two categories should not become permanent parts of the product. ### Food delivery examples show why priorities change over time [35:00](https://www.youtube.com/watch?v=s0hFne6EeOI&t=2100s) For a food delivery app, reliable order confirmation is a basic need. Delivery estimates are a performance need because users tolerate a reasonable range but become unhappy when a ten-minute estimate takes thirty. Discounts and group ordering can delight users, although group ordering may move toward performance as people come to expect it. GPS tracking shows how categories change: it was a delighter in 2015, then became a performance feature, and can now feel like a basic requirement. Features can move from delighter to performance to basic, or disappear when nobody cares. ### Architecture should match the value and certainty of the feature [45:03](https://www.youtube.com/watch?v=s0hFne6EeOI&t=2703s) The Kano category affects more than the order of a backlog. Basic needs deserve reliability, completeness, and clear ownership. Performance needs require measurable targets so the team knows when delivery estimates or other quality levels are good enough. Delighters are experiments, so Dodds recommends limiting architectural commitment until the team learns more. A separate system can support the experiment before the team integrates it into the main product. Indifferent features should be removed rather than carried through migrations, and reverse features deserve direct pushback from engineers. ## Notable quotes - "You do not just turn feature requests into implementation." (07:15) - "When AI agents level the implementation playing field, the differentiator becomes building the right thing." (51:01) - "You cannot overdelight your basics." (41:28) - "The user is not always right." (25:57) ## Tools & references mentioned - Clayton Christensen - Competing Against Luck - Jack Ryan - Rita - Don Norman - The Mom Test - Kano model - React - AngularJS - SolidJS - Vue - Bun - PayPal - Cloudflare Pages ## Who should watch - You are an engineer receiving feature requests without a clear explanation of the user problem behind them. - Your team is deciding how much architecture and reliability work a new feature deserves. - You are building an early product and need ways to test whether an idea matters before you have useful metrics. ## Related talks - [Build the Right Thing: Product Engineering (Part 1)](https://aietalks.com/talks/build-the-right-thing-product-engineering-part-1) (Kent C. Dodds, EpicProduct.engineer, 55:19) - [Everything is ugly, so go build something that isn't](https://aietalks.com/talks/everything-is-ugly-so-go-build-something-that-isnt) (Raiza Martin, Huxe, 25:15) - [Designing AI To Scale Human Thought](https://aietalks.com/talks/designing-ai-to-scale-human-thought) (Jun Yu Tan, Tusk, 12:24) - [Shipping Products When You Don't Know What They Can Do](https://aietalks.com/talks/shipping-products-when-you-dont-know-what-they-can-do) (Ben Stein, Teammates, 19:34) - [Build Dynamic Products, and Stop the AI Sideshow](https://aietalks.com/talks/build-dynamic-products-and-stop-the-ai-sideshow) (Eliza Cabrera, Workday & Jeremy Silva, Freeplay, 18:10)