Build the Right Thing: Product Engineering (Part 2) — Kent C. Dodds, EpicProduct.engineer

JustGetInTheWorkshop already exists. Now the workshop exercise moves into the familiar next phase: users want more features. Kent C. Dodds asks the audience what to add. Suggestions include queue information and a remote wait list, but the room settles on facial recognition so attendees can skip scanning the app. It sounds like a straightforward engineering assignment—until someone asks why.

The first answer is speed: admission is slow. The next answer separates identity from the proposed identification technology. The conference needs to get people into the room and know who entered; a face is only one possible way to do that. Go another level deeper and the consequence becomes clearer: people should be learning in the workshop rather than missing its first 20 minutes while waiting outside.

That change in the question opens other routes. Could a virtual queue reduce the physical wait? Why does this particular queue exist at all? Optimizing an existing solution can hide the fact that an earlier choice created the difficulty. Dodds calls this the problem tree: a solution produces further problems, which require further solutions. If a downstream branch becomes unexpectedly expensive, return to the earlier decision and consider another branch instead of treating the current design as inevitable.

Jobs to be done supplies the language for that earlier decision. Introduced here through Christensen’s Competing Against Luck, the idea is that people hire products to make progress in a specific situation. Facial recognition describes a requested feature. It does not describe the progress that makes the feature worth building.

A feature request still needs judgment, even when a product manager has already shaped it. Every addition changes the system engineers must maintain, and that maintenance consumes time that could go toward a more valuable problem. Dodds’s deliberately sharp warning about automatically sending every request to an implementation agent—“Stop”—targets this missing decision. Cheap implementation does not supply a product vision.

Four questions recover the job from the workshop request:

• Who needs it? Attendees are ultimately being served, while the people managing the door also use the system.
• When does the difficulty occur? As people try to enter a workshop.
• What progress do they want? To get inside.
• What happens today? A QR-code scan, with a blocking request in the exercise’s current workflow. Parallelization becomes a candidate solution before facial recognition is necessary.

The job statement uses a simple structure: “When [situation], help me [make progress], so I can [desired outcome], without [undesired consequence].” For this exercise, an attendee wants to get into a workshop quickly, learn about product engineering and avoid missing the first 20 minutes. The statement leaves the identification technology open. That is useful: it lets the team compare solutions against the same outcome rather than mistake the initial request for the requirement.

If the task arrives without that context, asking for it is part of designing the system. Otherwise, the team can spend three months implementing something that solves no meaningful problem—or solves a problem for one person that scarcely applies to anyone else. A job statement makes those assumptions discussable before they become architecture.

A job has functional, social and emotional dimensions. Functional asks whether the product does the thing. Social asks who participates and how using the product relates to other people. Emotional asks how the user feels: excited, embarrassed, comfortable or uneasy. These questions belong in engineering because their answers can change implementation decisions.

React provides an intentionally opinionated example. In Dodds’s account, its early appeal was functional: speed, a simpler state-management model and composition. Composition let a component hide messy internals behind an interface, preventing that mess from spreading into its consumers. Adoption then created social reasons to choose React: teams already used it, employers wanted it and the ecosystem offered opportunities. Conferences and community added an emotional reason to belong. His “React won” framing is an interpretation of adoption, and his prediction that agents will spare developers from learning its successor remains a forecast.

The mechanism matters beyond React. Once a product has a large network of users, teams and supporting resources, a competitor’s functional improvement may be insufficient to displace it. An open-source library is a product too; its job includes more than executing code.

User feedback helps engineers see those dimensions in ordinary work. A shared Slack channel could gather input from selected customers or collect public discussions from Reddit, X and other sources. The engineer need not answer every message to learn from the recurring rough edges. A complaint may reveal a misplaced button, or it may reveal that two systems need to exchange information. The useful question is how the product can support what users expect to accomplish, including how they feel when other people know they use it.

Return to the door. The audience proposes tracking whether workshops start on time. This changes what success looks like: faster identification is an intermediate step; attendees being ready for the session is closer to the desired outcome. The exercise then deliberately continues with facial recognition to expose what that choice would require.

The three dimensions now produce concrete engineering questions:

• Functional: what state must exist? Facial recognition introduces a database of faces and encryption concerns. Admission also involves venue capacity and the number of attendees inside.
• Social: who shares the workflow? The attendee interacts with a check-in worker, with other people waiting nearby and possibly with the speaker. Two lines introduce parallel admission as another route to the same job.
• Emotional: what does the method feel like? A conference holding facial-recognition information may make attendees uncomfortable. Faster entry can therefore improve one dimension while damaging another.

“How about not?” is a legitimate engineering response at this point. It means reopening the solution choice because the feature brings costs the job does not require. The workshop example has visibly changed: it began as a request to replace a scan with a face, and now it is a choice among admission methods evaluated against learning time, operational needs and attendee comfort. This is a design exercise, so it does not establish that facial recognition, parallel lines or badges actually improve throughput.

Purchase is only the first test. Jobs theory distinguishes the big hire—paying for the product—from the little hires of actually using it. Dodds makes this tangible with a burger: buying it is the big hire; each bite is another decision to continue. A burger thrown away early has failed despite completing the sale.

For JustGetInTheWorkshop, the paying customer would be the conference, while attendees and door staff experience the workflow. Repeated progress therefore includes whether the conference chooses the product again. Understanding that job may lead to NFC chips in badges instead of facial recognition, although badges create their own problems. The aim is to choose the problem-tree branch deliberately and decide what to build, instrument, defer or omit.

Without users or metrics, begin by validating that the problem exists and matters enough for someone to try a solution. The Mom Test supplies the questioning approach, and fast prototyping makes the next step cheaper: build a simple version and watch people use it. Paper cuts are acceptable at this stage. An inability to persuade anyone to try it is itself a signal. An established company can run the same process with existing customers rather than treating every new feature as already validated.

Moving from a product role into product engineering also requires learning the system’s constraints. Talk with engineers about how the infrastructure works and why the architecture has its current shape. Dodds’s practical advice is refreshingly ordinary: spend time with the team, have lunch and stop being so siloed.

A demanding customer is evidence, but may not represent the market. In the hypothetical business with 50 customers, one customer supplying 90% of revenue has obvious commercial weight. Otherwise, investigate the underlying job with other customers. Rather than ask whether they like a proposed feature, ask when they last experienced the pain and what they did instead. A person clicking fifty menu items to finish a task supplies a much stronger signal than agreement with an export-to-PDF proposal.

Incident response exposes a different judgment: how costly is waiting? Dodds recounts an agent diagnosing and fixing a bot attack on his personal website after receiving “Production is down. Figure it out.” He could tolerate the agent taking its time there. A failure in the cross-border payments work he did at PayPal would have much higher stakes. When rapid recovery matters, understanding the code and architecture helps an engineer diagnose the failure and guide the agent instead of waiting for it to discover everything.

His security assessment follows that concern about scale: AI can make existing weaknesses easier to identify and exploit, while giving a careless developer a larger blast radius. The concern is what increased capability does to existing engineering habits.

Once a product reaches a broader audience, many valuable-looking requests compete for attention. Dodds introduces the Kano model through a practical frustration: Bun had appealing features, but missing capabilities kept him from migrating some existing Node work. Interesting additions could not compensate for foundations required by that use case.

The model, introduced as originating in a 1984 paper on attractive and must-be quality, relates implementation to satisfaction. Three categories explain different relationships: basic needs cause dissatisfaction when missing; performance needs reward improvements in quality; delighters offer something users did not expect. The graph has no units, so it supplies a qualitative way to reason about value rather than a formula for calculating satisfaction.

The exercise switches to food delivery, with order confirmations, driver GPS, delivery estimates, a surprise discount and a shared cart. Their categories depend on what users expect and how additional implementation helps:

• Basic need: reliable order confirmation. Receiving only some confirmations is unacceptable. An audience contribution usefully generalizes email to notification: the need is dependable confirmation, rather than a prescribed channel.
• Performance need: delivery-estimate accuracy. An estimate within a reasonable range can satisfy the customer; greater accuracy can improve the experience further.
• Delighters: discounts and group ordering. An unexpected discount adds pleasure. A shared cart can replace a 40-message lunch-order thread and the awkward request for repayment. Group ordering may already be moving toward a performance expectation as collaborative software becomes familiar.

Delivery estimates show why the mechanism is accuracy, rather than simply arriving sooner. Promise 10 minutes and deliver in 30, and the customer waits unexpectedly. Promise 30 and deliver in 10, and the customer may not yet be home. Better estimates support coordination. At the impressive end of the example, the countdown reaches zero just as the food reaches the doorstep.

Website load time illustrates another quality gradient: depending on the application, one second may be satisfactory, while 250 milliseconds or 100 milliseconds feels better. Confirmation behaves differently. Sending more and more notifications—pickup, departure, passing a stop sign—can become intrusive. Once a basic need is adequately met, extra implementation need not add value.

Delighters are tempting engineering work, but they cannot make unreliable basics disappear. Early adopters may accept paper cuts to obtain a valuable new capability. A majority audience is less forgiving. The product needs its foundations in place before surprising additions can carry the experience.

GPS tracking makes changing expectations visible. In Dodds’s example, watching the driver in 2015 would have been a delighter. It gave customers information beyond an ETA: they could see a driver approaching a train crossing and judge why the delivery might be delayed. Familiarity then turned tracking into something customers increasingly expected.

Where does that feature sit now, and how did it get there? The diagram follows the expectation change described in the exercise. GPS sits near the boundary between performance and basic: more accuracy can help, but reasonable accuracy may be enough. The important relationship is that widespread expectations change the penalty for leaving a feature out.

A backlog classification therefore needs revisiting. In the progression presented here, successful delighters move toward performance expectations and eventually basic needs; an experiment nobody cares about can instead be removed. Watch competitors to understand the changing problem, then develop your own solution rather than freeze priorities at the moment the feature was first proposed.

Basic needs also have a stopping point. The hotel analogy is memorable: no toilet paper makes a stay bad, but 100 rolls do not make it better—and might make you worry about the food. Foundations need adequate implementation and feedback that exposes failures. More of the same is not automatically an improvement.

The Kano model helps decide more than task order. Product value becomes technical requirements: how reliable must this be, what must be measured and how reversible should the implementation remain? Product managers help identify the value; product engineers must understand it well enough to choose the corresponding system design.

Each category calls for a different allocation of effort:

• Basics need reliability, completeness and ownership. Missing notifications undermine the expected experience. The team needs to make these foundations dependable.
• Performance needs measurement. Establish the satisfactory level for a quality such as ETA accuracy, then instrument it to know whether the product reaches that level. Falling below it remains a problem even when the feature technically exists.
• Delighters need room to learn. Treat uncertain additions as experiments. A separate implementation can allow learning before the feature becomes deeply integrated into the existing system.

Everything should work reliably, but time and tokens are finite. The architectural tradeoff is commitment: investing deeply in a known foundation differs from embedding an uncertain experiment throughout the product. Once the experiment’s shape and value become clearer, the team can bring it into the full system with better knowledge of what deserves to stay.

The remaining Kano categories sharpen the engineer’s responsibility:

• Indifferent features add maintenance without user value. Before spending two weeks migrating a feature, ask whether anybody uses or cares about it. Removal may serve the product better than preserving it.
• Reverse features make the experience worse. The workshop’s hypothetical automatic social-media post is the callback: checking into an event should not automatically announce attendance in a way users dislike.

This is where prioritization becomes a matter of judgment about harm. Engineers build the software that users resent as well as the software that helps them. Dodds asks engineers to push back on harmful ideas and recognizes that refusal is easier from his position as a self-employed person. The responsibility still reaches the people implementing the behavior.

The closing frameworks connect without requiring a startup setting. The Mom Test helps validate a new problem or idea inside an existing company. Jobs theory turns requested solutions into an understanding of progress, potentially allowing one solution to satisfy several requests. Kano then helps allocate effort and keep unwanted behavior out of the product.

Dodds’s final thesis is conditional: when AI agents level the implementation playing field, building the right thing becomes the differentiator. But the advice also holds if agents stop improving and still need supervision. Technical expertise becomes more valuable when it connects to the actual problems users have. Faster construction is useful when the team understands what deserves to be constructed.