As AI agents make implementation faster and more accessible, engineers need to spend more time deciding which problems and features are worth building.
2
A product engineer connects customer needs to data models, workflows, constraints, observability, failure modes, and the smallest useful slice of a system.
3
The Mom Test replaces requests for opinions with questions about recent behavior, workarounds, effort, and cost, giving teams evidence for deciding how much to build.
Summary
Kent C. Dodds argues that AI agents are reducing the value of implementation skill while increasing the value of judgment. Engineers can now hit more targets, so their advantage comes from choosing the target that matters and understanding whether a feature deserves engineering effort. Product engineering connects customer problems to technical decisions such as data models, workflows, architecture, constraints, and the smallest useful slice. Dodds uses examples from WorkOS, Instagram, and a failed Australian real-estate product to show how user context changes system design and investment. The workshop then applies The Mom Test to a live idea, an app called Just Get In the Workshop. Instead of asking whether people would use it, participants ask what happened the last time they faced the problem, what they did instead, and what it cost. Dodds also argues that customer conversations and user feedback should continue while building, because early prototypes expose whether a solution actually helps.
AI agents make choosing the target more valuable than hitting it
Dodds says AI agents are leveling the implementation playing field. Engineers can hit more targets than before, but the targets do not have equal value. The important judgment is deciding what to build and whether it is worth building at all. He describes this as the durable skill for software engineers. The shift applies to internal enterprise work as well as new products. Engineers are moving from asking, "Can we build it?" to asking, "Is it worth building?" Dodds warns that an agent will not reliably stop a team from expanding a product in the wrong direction, so engineers need to slow down and choose intentionally.
Product engineers connect user needs to concrete system decisions
Dodds does not ask engineers to become product managers. He describes a product engineer as someone who connects an understanding of customer needs to technical choices. Those choices include the data model, workflow shape, observability, constraints, failure modes, and smallest useful slice. Product context helps an engineer decide whether a request fits the existing architecture or needs new primitives. It also helps prevent overbuilding. The engineer still owns technical decisions, but makes them with knowledge of what the user is trying to accomplish and what the business needs.
Seeing users changes architecture and workflow decisions
Dodds uses Robert C. Martin's story about building software for telephone-line technicians. After going out on a repair truck and watching a technician use the software while hanging from a pole, Martin saw many ways to improve it. Dodds says product engineers live half in the technology and half in the customer's situation. He also cites WorkOS, where customer conversations led to choosing a hosted authentication product instead of an on-premises or open-source model. A security fix needed to reach customers immediately, so the way customers operated changed the technical direction.
The smallest useful slice should determine the first system
Dodds contrasts waterfall, agile, and AI development to explain why teams need to reduce their ambition. In AI-assisted work, an agent can produce a whole system, so the engineer's job is to cut it down to the part that actually solves the intended problem. He uses Instagram's early history as an example. The product began as Bourbon, a broader check-in application, but user behavior showed that photo sharing was the feature people cared about. The team removed the rest and focused on that behavior. The right first slice comes from observing what users need, not from listing every possible feature.
Validation should measure behavior rather than enthusiasm
For the workshop exercise, the audience chooses an app called Just Get In the Workshop, based on the line outside the room. Dodds uses it to introduce The Mom Test. Questions such as "Would you use this?" invite compliments and speculation because people want to be polite. Better questions ask about the last time the problem happened, what the person did instead, and what the workaround cost. People cannot reliably predict their future behavior, and they may agree with a proposed solution simply to end the conversation. Specific past behavior gives the team evidence about whether the problem is real and costly enough to address.
The amount of evidence should shape the engineering investment
Dodds connects customer validation to technical trade-offs. A feature that is a small experiment deserves a different investment from a capability on which the business depends. He describes a product team that spent a year and 1.2 million Australian dollars building a highly scalable real-estate system, only to discover that nobody used it. A two-week launch with manual integration could have tested the market sooner. Engineers should ask where a request came from and whether it is experimental or central to the business before deciding how much architecture and polish it needs.
User feedback continues after the idea is validated
Validation does not end when a team decides that a problem is worth solving. Dodds says teams should put prototypes in front of early users and watch whether they continue despite gaps. A user who tolerates rough edges to reach the desired outcome provides a strong signal. Someone who stops after minor obstacles provides a different signal. Dodds describes customer conversations and prototype feedback as a continuing loop. This feedback also helps engineers choose the right architecture, because knowing how users solve the problem today can reveal the system's appropriate shape and prevent the team from building the wrong abstraction.
"Your job as a product engineer is to connect the customers, understanding what the customer needs, to the technical choices that are being made so that you don't paint yourself into a corner and you don't overbuild."21:35
Who should watch
You are an engineer using AI agents and need a way to decide which work deserves your time before asking an agent to build it.
You work from product tickets without much customer context and want to connect user behavior to architecture and scope.
You are validating a new product or feature and need better questions than whether people would use your idea.
