What Is Product Engineering Beyond the Feature Request?

Product engineering is the practice of marrying technical expertise to the real problems users have. The method: interrogate every request with jobs-to-be-done questions, split the job into functional, social, and emotional dimensions, then prioritize with the Kano model. Feature-first teams skip these steps and maintain features nobody uses.

What Product Engineering Actually Means

Product engineering is the discipline of connecting technical decisions to the progress users are trying to make, rather than implementing feature requests as they arrive. Kent C. Dodds, the creator of Epic Web and a former PayPal engineer, presented this approach in his 2026 talk "Build the Right Thing" at AI Engineer. His thesis: when AI agents level the implementation playing field, the differentiator becomes building the right thing.

The talk used a fictional conference app called "Just Get In the Workshop" as a running example. The team has shipped a basic product and is now receiving user requests. One audience member suggests facial recognition to speed up check-in. That suggestion becomes the case study for every framework in the session.

Dodds' core warning applies directly to teams wiring user requests straight into AI coding agents: if you say yes to every feature, you accumulate complexity with no vision and no taste. Each request requires product judgment, because every feature becomes a permanent maintenance cost and slows work on more important things.

From Feature Request to Job Statement

The fastest way to escape a bad feature request is to keep asking why until you reach the job to be done. Jobs theory, developed by Clayton Christensen and described in his book Competing Against Luck, holds that people hire products to help them make progress in a specific situation. The request is a proposed solution; the job is the problem.

For the facial recognition request, the questions are concrete. Who is this for? Attendees, and the person checking them in at the door. When does the problem happen? When a workshop starts and a queue blocks entry. What progress do they want? To get in. What do they do currently? A QR code scan that serializes everyone into one line.

The resulting job statement reads: "When there's a workshop starting soon, help me get into the workshop quickly so that I can learn about product engineering without missing the first 20 minutes." Notice that facial recognition appears nowhere in it. Parallel check-in lines or NFC badges solve the same job with different trade-offs.

Dodds calls the diagnostic a "problem tree": a problem spawns a solution, the solution spawns new problems, and backing up often reveals you would never have chosen that branch if you had known its downstream costs. Asking why the virtual queue exists in the first place can invalidate the optimization entirely.

Functional, Social, and Emotional Progress

Once you have the job statement, jobs theory says to break it into three dimensions, and each one maps to technical decisions. The functional dimension asks whether the system does the thing: state to store, workflows to integrate, metrics like "does the session start on time" that prove the solution works.

The social dimension asks who is involved. For workshop check-in, that is the attendee and the person at the door, with everyone waiting in line affected too. Adding parallel lines, for example, changes staffing and flow, and a second solution to the same job emerges from simply mapping the social surface.

The emotional dimension asks how people feel. A database of attendees' faces, even encrypted and capacity-aware, can leave users creeped out about how their biometric data is handled. That emotional signal alone can justify rejecting the request and choosing a lighter solution to the same job.

Dodds extends the framework to technology adoption itself, arguing React won in the mid-2010s first on functional grounds (speed, composition, a simpler state model) and then on social grounds: everyone else used it, employers demanded it, and the ecosystem rewarded it. Once network effects dominate, later functional challengers rarely displace the winner.

Success Is the Little Hire, Not Just the Sale

Jobs theory distinguishes two hiring moments, and product engineering should measure both. The big hire is the purchase: the customer pays and receives the product. The little hire is every subsequent use, and repeated progress is what defines success rather than a one-time transaction.

For the conference app, the paying customer is the conference, not the attendees, so repeated use means the conference choosing the product event after event. For a food delivery app, the little hires are orders, and retention depends on each order making progress reliably.

The practical instrument is a steady feedback channel: a curated Slack or community space with high-value users, or an aggregator that pulls in Reddit and social threads. Dodds learned this at PayPal, where features shipped to millions of users instantly, but structured feedback was hard to get at scale. The channel surfaces the paper cuts that tell you whether you are still doing the hired job.

He also cites Don Norman's position that user error does not exist: when users struggle, change the system to support what they expect. Sometimes the fix is a button placement; sometimes it triggers systems thinking about how two disconnected parts of the product should talk.

Prioritizing With the Kano Model

The Kano model, from Noriaki Kano's 1984 work on attractive quality and must-be quality, sorts features into categories with different satisfaction curves. In the second exercise of the talk, Dodds applied it to five requests for a food delivery app, and the categories dictate how much architecture each request deserves.

The model has five categories, two of which should never appear in your product at all. A comparison makes the differences clear:

Category	Satisfaction behavior	Example from the talk
Basic need	Never satisfies until fully done; overdoing it adds nothing	Reliable order confirmation emails
Performance need	Satisfaction rises with quality on a measurable gradient	Accurate delivery estimates
Delighter	Unexpected extras satisfy even when barely implemented	Surprise discounts, group ordering
Indifferent	Users do not care either way	Features nobody uses; remove them
Reverse	Users actively dislike it	Auto-posting check-ins to social media

The exercise surfaced a nuance: GPS driver tracking felt like a delighter around 2015, moved through performance as competitors copied it, and now sits near a basic need, since riders expect it to exist. Kano categories drift in one direction over time, from delighter down to performance and then to basic, so prioritization is a recurring review, not a one-time sort.

Dodds' colleague's analogy captures basic needs: no toilet paper in the hotel ruins the stay, but a hundred rolls do not improve it, and the surplus might make you worry about the food.

How Each Category Changes the Architecture

The Kano category is an architectural instruction, and this is where product engineering earns its keep. Basic needs demand reliability, completeness, and ownership: notifications and confirmations must simply work, even though nobody wants to work on them, because without them users leave regardless of what else you ship.

Performance needs require measurement, because the whole category is a quality gradient. For delivery estimates you must decide what accuracy counts as satisfied and instrument against it; for web apps, Dodds noted, load times around one second feel acceptable while pushing to 100 milliseconds genuinely impresses. Falling below the satisfied line on a performance need reads as a defect.

Delighters should stay reversible experiments. Instead of integrating a speculative feature deeply into the core system, isolate it, learn its real shape, and only then fold it in. Keeping experiments reversible preserves the option to delete them when they turn out to be indifferent features, which Dodds calls dead weight that engineers end up maintaining for nothing.

Reverse features deserve explicit pushback. Dodds argued that the shady product behaviors users hate are built by software engineers, and that engineers have standing to refuse, even when employment pressure makes refusal uncomfortable. The facial-recognition request, once reduced to its job, was dropped in favor of simpler check-in options precisely because its emotional dimension bordered on reverse.

Validating Ideas When You Have No Metrics Yet

Before launch, with no users and no data, validation comes from problem interviews rather than dashboards. Dodds recommends the Mom Test approach: ask people when they last experienced the pain and what they did about it, never whether a proposed feature sounds good to them.

AI tooling shortens the loop. Prototype a rough solution quickly, watch people use it, and treat the inability to get anyone to try it as a signal that the problem is not important enough. The same interview discipline applies inside an existing company, where the product manager usually owns the customer relationships and can route engineers to real users.

When one loud user demands a feature, representativeness is the question. If that customer covers most of your revenue, accommodate them. Otherwise, ask your other users when they last hit the same problem; discovering that one person clicking through 50 menu items is not a pattern saves you from building a feature nobody else needs.

FAQ

• Why should engineers care about the job to be done if product managers exist? Because requests often arrive without a job statement attached. Without one, you cannot design a good system, and you risk spending months building something that solves a problem only one person had. Understanding the job also lets one solution cover many requests.

• Does the Kano model assign fixed categories to features? No. Categories drift over time in one direction: a delighter becomes a performance need as competitors copy it, then a basic need as users come to expect it. GPS tracking in delivery apps illustrates the full drift over roughly a decade.

• What is the difference between basic needs and performance needs? A basic need never produces satisfaction until fully implemented, and over-implementing it adds nothing. A performance need scales satisfaction with quality on a measurable gradient, like delivery estimate accuracy, so you decide how far up the gradient to build and instrument to stay above the satisfied line.

• How do you decide what to build before any metrics exist? Use problem interviews: ask when users last felt the pain and what they did instead. Then prototype quickly and watch real usage. If nobody will try the prototype, that is evidence the problem is not worth solving yet.

• Do AI agents change any of this? Dodds argues the opposite of what you might expect: when agents make implementation cheap, the differentiator shifts entirely to choosing what to build. Automatically turning every user request into code would produce a product with no vision, which is exactly what these frameworks prevent.

Turn Your Own Talks Into Written Knowledge

The insight running through this article is that value lives in separating what users say from what they need. If you have given conference talks, recorded interviews, or explained your engineering lessons on YouTube, that same kind of knowledge is likely sitting in video form where search engines and readers cannot easily find it.

Skala Blog turns a YouTube video into a written article: paste the URL, transcribe the talk, and generate a structured draft you can review and publish. A 52-minute session like this one becomes a searchable reference instead of a playback counter.

Visit Skala Blog to start from a video you have already recorded.

Source video