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

The workshop begins with people still waiting outside. A line stretches away from an entry bottleneck, while seats inside need filling. Kent C. Dodds jokes that a room full of engineers ought to solve the problem, then asks attendees to wave newcomers into empty seats. Before anyone proposes software, the scene already contains several different concerns: processing entry, finding available seats, and getting people into a session that has started.

That immediate frustration will become the workshop’s example. First comes the reason to practice product judgment at all. Dodds went into full-time teaching in 2019, helping experienced engineers acquire experience with testing, React and full-stack development. Better coding agents unsettle that business: an engineer who already understands software may now direct an agent through an unfamiliar framework instead of taking a course on its implementation details. His admission has a personal cost—he sells those courses.

The educational choice is between teaching this week’s agent techniques and teaching a skill that survives changes in tools. Dodds chooses judgment: deciding what deserves to be built. His thought experiment imagines automation doing almost all engineering work and asks what useful human contribution remains. This is a forecast about the direction of automation, not a claim that present agents can independently produce dependable software; he acknowledges their mistakes and rejects planning around a fully automated future whose consequences nobody knows.

The archer metaphor makes the change concrete. Engineers once differentiated themselves by hitting a difficult target: translating a request into working software despite technical obstacles. Agents make the arrows behave more like homing devices and let an engineer attempt many more targets. The targets still have different values. Easier implementation increases the importance of choosing one worth hitting.

After a round of 12 air squats, the room gets a second kind of participation: attendees can submit and vote on an example app, and use the same interface for questions. The example is deliberately unrehearsed. The frameworks must work on a problem chosen in the room, and attendees are asked to apply them to their own applications too.

The question changes from “can we build it?” to “is it worth building?” This applies to an internal enterprise feature as much as a new startup. Money remains finite, and a product that attempts every possible feature can overwhelm its users. Selecting useful work has always mattered; cheaper implementation makes the consequences of poor selection arrive faster.

A ticket can be implemented correctly and still produce no customer value. Treating the specification as the end of responsibility leaves the engineer doing a job that increasingly resembles an agent’s: accept instructions, produce code, take the next ticket. Wayne Allen’s formulation puts the dependency in order: “Building the thing right is downstream of building the right thing.” Technical quality cannot rescue an unnecessary capability.

Faster generation introduces several distinct traps:

• Product expansion. Adding features becomes easy enough that someone must deliberately stop the product from accumulating unnecessary behavior.
• Repeated bad practices. Agents can spread existing codebase mistakes faster, increasing the importance of the environment and patterns they work within.
• Convincing prototypes. A polished interface can feel ready to ship while leaving scalability and edge cases unresolved.
• Sunk effort. Rapid progress creates attachment to the implementation, making it harder to stop when the direction proves wrong.

Owning the eventual system changes how a prototype is used. A prototype can establish the desired experience, then be replaced with an implementation shaped by engineering judgment. The prospect of being paged at 2:00 in the morning supplies a practical reason to care about the architecture, constraints and agent working environment. Looking functional is only the beginning of that responsibility.

Product engineering connects customer needs to technical choices. The engineer still decides the data model, workflow shape, observability, constraints, failure modes and smallest useful slice. Understanding where a request came from helps make those decisions without overbuilding or creating a system that cannot accommodate the real workflow. This responsibility overlaps with a product manager’s understanding of users while retaining a technical center of gravity.

The smallest useful slice can require subtraction. In Dodds’s comparison, AI can hand over something that looks like the whole product, leaving the engineer to whittle it down. He illustrates this with Instagram’s early history: watching users revealed that photo sharing mattered more than the surrounding check-in features, so the product concentrated on photos. The useful operation is to preserve the behavior people value and remove the rest.

Watching work happen also reveals requirements that an office conversation can miss. In a story from Uncle Bob, software for telephone-line technicians looked different after its developer rode along and saw someone use it while hanging from a pole. The environment made improvements obvious. A workflow that is tolerable at a desk may be difficult in the conditions where the customer actually works.

A technically interesting API does not automatically justify switching workflows. A prospective user already has a way to get something done; the new product must improve that experience enough to make changing worthwhile. The same context matters inside the architecture. Even when agents make a database change or service rewrite cheap in tokens, the change can still cost the team coordination and disrupt users. Choosing suitable building blocks early avoids costs that code generation alone does not remove.

WorkOS provides a concrete architectural example. In Dodds’s account, Michael considered distributing the authentication platform as an on-premises licensed product or through an open-source model with a commercial arm. Customer conversations brought an operational requirement into focus: a security fix needed to reach users immediately. Waiting for each customer to upgrade an npm package would leave that timing outside the provider’s control. The resulting choice was a hosted service.

What changes when the provider needs to deliver a fix immediately? The comparison below follows the update path. Customer-managed installation inserts a customer upgrade between the fix and its use; hosting lets the provider deliver the correction through the service. The architectural choice follows from who must control that step. This example supports the decision for the requirement described, rather than establishing that hosted authentication is always the right choice.

Directing agents extends an older team-lead responsibility: create a system in which implementation goes well. Good tests, clear architecture and obvious building blocks make it easier to assemble features without unnecessary mistakes. Running more agents increases the importance of that preparation; it does not remove the need for it.

System design also includes the conditions under which people make decisions. Dodds recounts Don Norman’s response to the Three Mile Island incident: instead of stopping at operator mistakes, examine the system that led competent people toward those decisions. Norman’s provocative phrase, “User error does not exist,” is presented as his assertion. Its practical use here is to redirect attention from blaming a user to understanding what the design made difficult or misleading.

The first questions turn these ideas into decisions about scope and hiring:

• MVP scope. Ask for the minimum thing that demonstrates a solved problem for a particular audience, rather than an acceptable number of features. In a crowded market, narrowing that audience may help.
• Hiring. Dodds recommends evaluating how candidates discover the core problem and derive its system implications. Banning agents from a coding exercise poorly reflects work in which agents are available.
• Discovery timing. Talking to customers and building should continue together as a feedback loop.
• Distribution. Getting users to adopt a product is a separate difficulty; this workshop does not offer a developed answer to it.

Close collaboration with product managers supplies context, while collaboration with neighboring engineers prevents duplicated systems. An engineer who sees only one slice of an application may rebuild a capability already available elsewhere. Dodds recommends looking at least one neighbor outward, upward and downward—much as using React effectively benefits from understanding JavaScript and the browser beneath it.

The workshop names three intended frameworks: The Mom Test for early validation, jobs theory for framing requests, and the Kano Model for prioritization. This part develops the first. The winning audience proposal returns to the opening scene: an app that gets people into conference workshops. After considering a Lightning Lane name, the room settles on Just Get In the Workshop.

The first questions mix observation with proposed solutions. How long have you waited? Why are you waiting? Are there seats inside? Would pre-registration help? That last question already commits attention to a mechanism before establishing what causes the difficulty. Soon it is easy to imagine a mobile app, a website for one-time users, and integrations with conference providers. The product grows in the conversation before its necessity has been established.

The Mom Test changes the object of the interview. Asking someone to evaluate an idea invites reassurance, speculation or a polite way to end the conversation. Asking for a concrete episode gives the engineer behavior to interpret. The user supplies the experience; the engineer remains responsible for diagnosing the problem and choosing a solution.

The useful questions collect different kinds of evidence:

• The episode: Tell me about the last time this happened. Who was involved, and what made it annoying enough to remember?
• The workaround: What did you do instead? This reveals the existing workflow a new solution must fit into or replace.
• The cost: What did the workaround cost in money, time or effort? How often does the problem occur?
• The consequence: What are you losing by not having a better solution?

For Just Get In the Workshop, the observable change is in the discovery process, rather than a shipped app. The queue begins as an invitation to automate entry. It becomes a question about a paid attendee’s lost experience: Dodds gives missing the first 20 minutes of a talk as a concrete cost to investigate. The interview then asks what the attendee did, how much that delay mattered, and whether it happens often enough to justify a change. Those answers could constrain the solution; the exercise does not yet establish which entry mechanism would solve the bottleneck.

This queue makes discovery unusually direct because people are experiencing the problem now. Elsewhere, an interviewee may struggle to remember a recent incident. That is useful evidence too. Existing expenditure and effort suggest motivation to improve the situation; weak recall and little action suggest a weaker opportunity. These are signals about likely willingness to change, rather than guarantees of future adoption.

Wayne Allen’s real-estate product story shows the cost of getting the order wrong. An experimental product inside a larger organization was built with microservices and a capacity ambition: handle every person in Australia logging in simultaneously. In the account Dodds relays, the team spent a year and 1.2 million Australian dollars, then had no users. The system solved an imagined scale problem before establishing demand.

The retrospective alternative was a two-week launch with manual integration. That would have traded automation and capacity for faster market learning. It is a proposed counterfactual, not a demonstrated successful launch, but it identifies the avoidable commitment: a whole team spent a year before discovering whether anyone wanted the product.

The same decision applies to a feature request. If its validation is unclear, ask the product manager why it exists. That answer guides both whether engineering time is justified and how much to invest. A one-off experiment and a capability essential to the business deserve different tradeoffs. Essential work may need more attention to detail while still being delivered in a slice that can produce early evidence.

Enthusiasm from weeks of private hacking can obscure this distinction. Showing the idea to someone who does not understand its appeal may feel like having the fun spoiled. That discomfort is useful: it is a reason to investigate the mismatch, rather than retreat into more implementation.

Problem validation and solution validation answer different questions. The Mom Test helps establish whether a problem deserves work. A prototype lets users reveal whether this particular solution gets them where they need to go. Early adopters who remain excited despite substantial gaps can signal that the core benefit matters; users who abandon it after a few difficulties provide evidence about the solution’s usefulness too.

Dodds’s vivid image is a user willing to run through glass to reach the outcome. The point is the strength of motivation visible in behavior: a valuable result can make people tolerate an unfinished prototype. Their persistence helps identify what to preserve, while their difficulties show where the implementation still interferes with the goal.

How does customer learning continue to influence the system after building starts? The cycle below joins discovery to implementation and observation. Each pass can revise the useful slice and its architecture. Knowledge of existing workflows can also expose transition costs, such as downtime during migrations, that would be easy to miss if the engineer saw only the requested feature.

The closing questions sharpen the distinction between product engineer and product manager. A product engineer understands the system’s available data types, queues, scheduled jobs and other building blocks, including their limitations. Given a user goal, that engineer can decide whether existing infrastructure fits or whether the system needs to expand. Customer understanding makes the technical choice better; familiarity with the implementation makes it possible.

Whether these responsibilities need separate people depends on the organization. Dodds handles multiple roles as a self-employed builder; a small startup may share them among three people, then separate them as it grows. He expects AI to let a larger business operate with a smaller organization, but offers no numerical staffing rule. The responsibilities still exist even when the titles are combined.

The junior-to-senior question receives a modest answer: juniors still learn by trying to emulate more experienced engineers, while formal promotion remains a conversation within their organization. This part ends as the scheduled session rolls into the next hour. The unresolved work is to keep translating user goals into system decisions, rather than treating faster code generation as evidence that those goals have been met.