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.
2
Functional, social, and emotional needs change the technical decisions a product engineer makes, including whether a solution creates discomfort or privacy concerns.
3
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.
A requested feature is only a proposed solution to a deeper problem
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
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
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
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
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
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
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
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.
