Build the Right Thing: Product Engineering (Part 2) — Kent C. Dodds, EpicProduct.engineer
Read the talk
Build the Right Thing: Product Engineering (Part 2)
Kent C. Dodds turns a request for facial recognition into a lesson in finding the real job, then uses food delivery to show how user expectations should shape reliability, measurement and architectural commitment.
From a talk by Kent C. Dodds
At a glance
Ideas worth remembering
Translate a requested feature into the user’s situation, desired progress and outcome before choosing an implementation.
Functional, social and emotional needs can change the architecture: faster admission may still fail if its identification method makes attendees uncomfortable.
Validate problems through past behavior and observed prototype use; a customer’s proposed solution may not represent other customers’ needs.
Use Kano categories to allocate engineering effort: dependable foundations, measured performance and reversible experiments.
Revisit expectations over time, remove features users do not value and push back on behavior they actively dislike.
A faster door does not necessarily need facial recognition
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Write the progress before choosing the feature
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Functional success is only one reason a product gets used
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Follow the workshop request into state, people and repeat use
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Before metrics exist, look for behavior; during incidents, know the stakes
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The Kano model separates foundations from improvements and surprises
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Yesterday’s surprise becomes tomorrow’s requirement
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 2015 example: seeing the driver adds information beyond an ETA.
The capability may remain similar while expectations change: absence moves from acceptable to disappointing. Dodds places GPS near the performance/basic boundary.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Use the category to decide how much architecture to commit
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Some features should disappear; others deserve a refusal
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Read the complete timestamped transcript
- 0:13
So a- as some of you are, uh, heading out, um, actually, maybe we'll- let's make this less awkward. I don't want anybody to feel awkward. Uh, let's move again. Everybody stand up really quick. Yeah, I, I know, you're all like, "Oh, I can't. We just did this like 20 minutes ago." Yep, uh, you still gotta move. Um, we're not gonna do the full, uh, stre- or, uh, air squat thing, but you can just stretch a little bit. Make it less awkward for the people who wanna leave. It's okay. We don't want 'em to feel bad. Okay. Yep, you can stretch your legs, whatever you wanna do. Just don't hurt
- 0:43
yourself. Uh, and then go ahead and sit.
- 0:50
Okay.
- 0:52
So we've got, uh, I think I've got 50 minutes, five zero. So that's what you're, uh, in for if you decide to stay. So now we've got the JustGetInTheWorkshop implemented, and we're rapidly adding features based on user requests. So we've, we've moved our, uh, business life cycle. We're in this phase now, and a request comes in, example request, which we will fill in here in just a second. Um, and, and as we're going through this, I want you to see if you can apply, uh, some of these principles to your own, uh, products as well.
- 1:23
Um, okay, so what should the live request be? What did, what did somebody ask us to add to JustGetInTheWorkshop? Just throw it out or raise your hand. Yeah.
- 1:37
How long, uh, how long before they start queue up while purchasing the, uh-
- 1:42
Oh, so like s- s- a, a way to know how long the queue is. Okay. Yeah.
- 1:47
A remote wait list. They can scan a QR code and then go somewhere else and then-
- 1:51
Oh, okay. A little bit like the Disney FastPass thing then. Yeah. Like a remote wait list. Yeah. Okay.
- 1:56
How, how many carbon are you gonna breathe?
- 1:59
Oh, yeah. To, to know how much, uh, CO2 you're gonna be breathing when you get in there. Yeah, that's right. Yeah.
- 2:05
Just facial recognition so you don't have to do the app scan.
- 2:08
Oh, okay. That, that one-- So that would really speed up the process of getting in the workshop. Okay. Facial recognition. I think everybody good with that one? Okay. Um, facial recognition. Whoop. I think we all get that. All right. So let's first start with what Jack Ryan says, uh, here to dig, uh, past the requested button or whatever it is that they're requesting. So, uh, ultimately, this is just...
- 2:38
You keep asking why. What does it matter? Why does it matter? So why, why do we care that there's facial recognition? What, what, what does that mean in the context of our app?
- 2:48
Why can't they make it faster?
- 2:50
It's slow. So we're... Okay. So the problem, uh, that we're, we're thinking about is it's slow. Okay, what else? Is, is that like the main thing or is there anything else? Like, maybe there are other side features to this too. Like, um, it will take your picture and post it to social media. I don't know. That could be awful. Yeah.
- 3:10
What's the problem within the line of, like, how the talk is structured or the schedule?
- 3:15
Oh, the schedule could be the pro... Like, the fact that Tejas was speaking across the hall from me, that really bugged me, um, 'cause I like Tejas a lot and, uh, yeah. Any other, like, w- yeah.
- 3:27
The problem is trying to get into the room, right? Like, trying to register.
- 3:30
Yeah.
- 3:31
So obviously identifying the user, we all necessarily need their face. It could be, you know, communication on their phone. It could be any other number of things. We just need to identify that user-
- 3:39
Hmm
- 3:39
... so that as they go through the door, you know they did.
- 3:42
Yeah. Yep, that's true. The, the, uh, the, the core is just getting people into the room and knowing who came in, right? Yeah. Um, and, and why is that important? Let's, let's go one deep, one level deeper. Yeah.
- 3:57
They, they actually wanna know, like, who am I? Am I at the venue? Am I at-
- 4:01
Oh, good question. So the question is, in, in this role-playing that we're doing here, who are we? We are the product engineer. And so we're trying to... We're, we're talking with the user who's making the request, or maybe the PM is doing this, and now we're talking to the PM and asking them these questions, but yeah. So you have a follow-up?
- 4:17
Well, like, what's my motivation? Am I trying to get people in quicker 'cause I want to spend more time?
- 4:22
Oh, yeah.
- 4:23
Or do they just sell through a venue?
- 4:24
Yeah. So the question is, what's the motivation? Like, why do I care that we're, we're solving these problems? The reason that you care is because the app that you're building is what pays your paycheck. The, uh... Like, if we're talking about capitalistic reasons, um, but maybe you have some sort of innate thing inside of you that you just hate the idea of somebody missing the first 20 minutes of a workshop. And so, um, that is motivating you.
- 4:48
Why do we have to physically wait in the line? Why is not there, like, a queue, a virtual queue or, like... We know the number of spots in the room. Why do we-
- 4:57
Yeah, yeah. Why is there not a... That kind of goes back to this idea, too. Why is there a virtual queue in the first place? That actually, that, that's one of the, uh, things that we as software engineers need to ask ourselves frequently is like, "Okay, I'm gonna, I'm gonna go in here and I'm gonna optimize the heck out of this thing. It's gonna be amazing," when we really should step back and think, "Why does this exist in the first place? Oh, it's solving this problem. Well, why does that problem... Or, oh, okay, so that, that's why this matters." If we had known at the time that we created this solution, um,
- 5:27
that it would cost this much because this other off-shooting problem, then we never would have gone this direction anyway. We would have gone a different direction. I call that the problem tree. You got a problem, oh, uh, and then you solve that with this, and then that has a bunch of problems off of those, and each one of those span out, and you go until the problems aren't big enough anymore. Uh, and sometimes you can back up. When, when you get all the way down here, you're like, "Oh, um, that, uh, like, that's a really hard problem to solve. If I'd known that all the way back here, then I would've gone this way instead." And we often don't do
- 5:57
that. So you do need to ask yourself, "Okay, why does this exist in the first place?" Okay, so we go down why a bunch of times. This is, um, how you get down to what ultimately is called the job to be done. So jobs to be done theory, uh, is from Clay Christensen, amazing person, um, who, uh, wrote Competing Against Luck, among many other books. How many people have listened or read to at least three of his books? You have not listened or read to enough of his books. He has, like, a bunch, and they're all fabulous. Competing Against
- 6:27
Luck is very good. Um, but the idea of jobs to be done theory, or jobs theory, is people hire products to help them make progress in a specific situation. And I have a, a video on my YouTube channel. By the way, I just started getting serious about YouTube, and like, caring about thumbnails and stuff, like all the stuff you're supposed to do. So go subscribe on YouTube. I'm, I'm like weekly, um, more than weekly videos, and they're all really, really great. Uh, or if they're not great, go watch it and tell me why, and I'll make it better. Um, but, uh, yeah, so I go
- 6:57
deep into, uh, jobs theory, um, on that, uh, deeper or, um, yeah. It's, it's great. You should go look. Okay. So, um, first, facial recognition. That is the request. That's not the job. These are two different things. Uh, so Rita said, "People will say you guys should build this feature," and then you ask them, "What are you trying to solve?" That's, that is your first question back to them. Uh, and if you do say yes to every one of these features, you end up with a huge level of complexity. So you do
- 7:27
not just turn feature requests into implementation. I know some of you here in s- San Francisco are building an app right now that has like, takes the user's request and sends it into an agent and just automatically implements it. Stop. Okay, I actually don't know if anybody's actually doing that, but that would be a bad idea. You would end up with a really terrible product w- with no vision whatsoever, no taste, all judgment out the window. It'd be awful. Uh, so, uh, each feature
- 7:57
request requires your product judgment. So we don't take the feature request and nail it onto the thing we've already got. It wouldn't be a good product. There's lots of judgment that happens here. And some of that judgment is gonna be on the, the product manager, of course. Like they- they're often gonna be the one who gets the request first. Not necessarily, we'll talk about that too. But, um, often that is going to be kind of where things are coming from, and they should do a good job of, um, a- applying the vision of the product to the requests as they come in. Uh, and so,
- 8:27
uh, hopefully they are, are kind of slowing things or, or at least giving them a better shape for you. But even still, you, you still don't wanna just take everything that they give to you because it is going to have an impact on the system that you design, and now you have to maintain that long-term, and it's gonna slow you down on other things that might be more important. And so you have to put everything through the lens of the job to be done to make sure you understand the problem and realize, uh, that it's actually a valuable problem to be solved. So here are the questions that
- 8:57
we're, uh, you ask to reveal what the job is, and we, we're gonna come down to a job statement, uh, here for our facial recognition thing. So who is this for? W- who's the facial recognition for? If we're, if we're the conference and we're building an app to get people in, who is the, uh, the app for? Attendees. Attendees. It, it's actually partially for the attendees. It's also for whoever's manning the, the door, right? But, um, yes, the attendees ultimately are the ones being served. Um, and then
- 9:26
when does this problem happen?
- 9:30
Right here. When people are go- getting into a workshop, okay? And then what progress do they want? What is the progress the, the user is trying to do? Get in. Get in. That's why we named our f- our product this, just get in to the workshop. Um, okay, and then finally, what do they do currently? QR code. Well, it's the QR code scan, yeah. Blocking request. A blocking request. That's right. We could do parallelization. That could also solve this problem, right? And so,
- 10:00
uh, that... Hang on to that. Put a pin in that. Um, run MCP guy. I like that. That shirt is cool. You, you know, uh, Michael Ger- uh, Ger- yeah. Okay. Um, so let's, let's try and write the job statement. When situation, help me make progress, so I can get desired outcome. And often you'll add without some other thing. So when there's a workshop going on at 10110, help me get into the workshop quickly, um, so that I can learn about product engineering, um,
- 10:30
without missing the first 20 minutes. Okay? There you go. That's the job statement. That is not-- That has nothing to do with facial recognition, right? And so now that we understand what the job statement is, it will inform the decision that we take to, uh, to go forward with this. And again, some of you are thinking, "Well, that's the product manager's job is to, like, give me the job statement." Yeah, okay. Like, I'm not gonna say that's, that's wrong, but if you get a request that d- doesn't have a job statement attached or you've never heard, you don't know
- 11:00
which job statement this request is coming from, then that's gonna be, uh, uh, you are not understanding the, the problem well enough, or maybe the PM just skipped that part, and you're gonna spend three months building something that doesn't actually hit users because it's, it's not solving a real problem for them. Or maybe you're solving a problem that, uh, s- seems like a good idea to one person but wasn't generally applicable to everybody else. So getting down to the why, why, why and then turning that into a job statement, uh, helps a
- 11:30
lot with making sure you're building the right thing. So, uh, another thing that we do is to break that job, once we have that, into three dimensions: functional, social, and emotional. And, uh, yeah, we got... Uh, okay. So functional is like, does it actually do the thing? Social is who is involved when the user is using this product to do th- the thing? And then how do they feel when they're using it? Are they embarrassed or are, are they, like, shy or are they excited? Are they whatev- And, and these things
- 12:00
actually will have, will map to technical decisions that you as a product engineer will make. And so you actually need answers to these questions. We'll talk about that here in just a sec. Uh, oh, and I also mapped this to how React won, um, by the way. So how many of you hate it when I say React won? Uh, I'm just kidding. Some of you probably don't like React. I like React, and React won. It's over. The, the game is actually over. Um, there will be something that comes after React, of course, like, the, it's, it's not like it's gonna last forever.
- 12:30
But will we need to learn that thing? No, the answer is no. We will not be learning whatever it is that comes after React. The, it, it is changed into, like, what is the toy that you give your pet agent to be happy? Like, that, that's all that really matters at this point and as far as that's concerned. And so React won ... Here's, here's the reason. This is what my video's about. React won because it started with functional. That was, that was a thing. At the time, everybody was either Backbone, maybe Ember, uh, AngularJS, that's what I was
- 13:00
using, and, uh, React was just faster, uh, considerably faster despite all the, like, re-renders and everything we talk about now, but it was way faster. And, uh, it gave a much simpler mental model for state management, and, uh, composition was just fabulous, and it still is. Uh, React, it really solved composition, being able to create a thing, have it be, like, a total mess on the inside of that, but have a very solid interface so that that mess inside doesn't really affect anything else. That, that level of
- 13:30
encapsulation composition was really good. So then, um, eventually React, like, totally dominated. 2015, 2016, now React is, like, the top, and everybody's using it. That's when React moved from winning because of functional reasons into social reasons. Well, everybody else is using it. My boss, uh, wants me to use it, my, all my team. Uh, if I wanna get a job in this industry, I've gotta learn React. And so everybody is learning React. Now, of course, there are still others out there, and Angular 2 came out and, you know, uh,
- 14:00
people are using those. But React was just so dominant. Uh, the ecosystem was so big. Yeah, I'm gonna use that, and how do I feel when I'm using it? Well, maybe now you feel like, "Oh, I hate this thing," or whatever. But, like, at the time, it was, um, you know, everybody else is using this. I feel pretty good. Like, and it's kinda cool 'cause there are all these conferences I can go to and feel really excited with everybody else. That's why React totally won, and that's why when React started stumbling a little bit on the functional aspects of things and, okay, well, now we got SolidJS. We don't have rendering
- 14:30
problems anymore, or we got Vue and it's, like, easier to learn. That's arguable. But, like, uh, whatever, whatever it is, all these functional differences, it didn't matter anymore because it already had just nailed itself with the network externalities. So anyway, jobs theory applied to something that you might not think, but open source library is definitely a product. Um, that's pretty interesting. Okay. So, um, one thing that Jack Ryan
- 15:00
suggests is, uh, having a Slack channel or some, some mechanism for you to just get all of the user feedback. Some of you work on apps that have hundreds of thousands of users or millions of users. I worked at PayPal. I would ship something, and instantly it was out to millions of users, and that was pretty exciting and cool thing. But getting feedback from those users is really, really difficult, um, and, uh, and making sure that you're actually building the right things. And at the time it was fine that I didn't really spend too much time doing that because the, you know, it's a big company and we're gonna be
- 15:30
successful no matter what I do, I guess. Um, but, uh, uh, what you can do in those situations or even others is to have a Slack channel. It, uh, you can have a specific one with, uh, individuals that you really respect their decisions and, and, um, um, they're, like, high-value customers of yours. Or you can have one that's just, like, takes Reddit threads and, and X and, like, all the social media, brings it into one place, and you just, like, you don't have to necessarily answer everything or whatever. That's not necessarily your job. But seeing all
- 16:00
of this, you get a sense for where the rough edges, the paper cuts, and all the problems are in your product, and that can kind of help inform, okay, we're not actually, uh, solving the pr- the job that we were hired to do, uh, in this product, and give you a, a sense for, okay, so I understand why they're complaining about that. I don't believe in user error because Don Norman said it doesn't exist. And so how can I change the system so it can support what they think it should be doing? And sometimes it's gonna be, oh, well, we just need to put a
- 16:30
button right here in- instead of just having it right there, and, and now it'll be a lot easier. Other times it's gonna be, oh yeah, there's no way we can do that right now. And now I'm, now I'm doing my systems thinking of how can we make that so that those two systems can talk to each other or something. So, um, yeah, just let that context wash over you. Um, Michael says there's something very important in thinking about the storytelling of the thing you're building and how it situates in somebody's life. How does somebody feel when they're using your product? Um, is
- 17:00
... And, and not just how do they feel when they're using your product, but, uh, how does it, how do they feel when they know other people know that they're using your product? So if you're making some really embarrassing things that people need to use, like, I don't know, Depends or something, uh, I, I, I don't know that example. But, um, then, uh, like, you need to take that into account in the way that you, uh, package your implementation. Okay, so let's talk specifically, uh, about our, um, our idea. Did I ... No, I didn't. Dang it. So our,
- 17:30
uh, idea was the facial recognition thing. That was the original request. Um, and then we brought that into just getting people into, uh, the room faster. So what are the functional, um, aspects of that? I, I need you to throw out these things. So, like, what are the state, workflow, i- integration sorts of things that we need to think about if we're building this app, uh, just get in the workshop.
- 17:53
You could start on time.
- 17:54
Start on time. So, like, the speaker always starts on time? Or ... Okay. So I messed that up is what you're saying.
- 18:03
Well, in my defense, uh, people weren't gone until, um, two minutes after I should have started.
- 18:08
The solution-
- 18:09
You're right. Yeah, the solution's not there. Yeah. So actually, that's a really good, um, metric that we can track as well, is like how much are we starting on time? That will tell us whether the solution is actually solving the ultimate problem. Great. Thank you. Other... What are the other functional, like, let's, let's talk more systems things, like what is this, uh, actual, like, database table that you would need to, um, to speed up this? Let's, let's say that we do decide to do, um, to add, uh, to help us solve this job, we're going to add
- 18:39
NFC. No. Let's, you know what? Let's stick with the face recognition idea, um, just 'cause I think it'll be fun for something later. Um, but, uh, yeah. So we're gonna add fac- facial recognition. What is some of the state, uh, that we're gonna need to maintain for that? Database of everybody's faces. Yeah, database of everybody's faces. That's gonna, uh, impact a lot of things. Yeah. What else? Encryption of faces. Uh, what? Encryption. Encryption. Yeah. Okay. So we're encrypting things. Now the government won't get mad. Um, just kidding. No.
- 19:09
Uh, other, other things we're gonna need. Yeah? Number of people in the seats. Yeah. Number... Yeah. So, like, venue, um, capacity, uh, and, and attendee, uh, capacity and, and maybe... Well, yeah, we won't get into that. Okay? Cool. And then on the social side of things, um, who, whe- when this software is being used, this particular feature of the software is being used, um, how does that affect, oh, the social aspects? Like, who is using it, and who are they interacting with when they're using it? You're gonna have two
- 19:39
lines. You're gonna have two lines? Oh, yeah. That, I mean, now we're talking about parallelization, uh, which also solve, uh, is a, another solution to that same job that we're trying to, uh, to accomplish. Yeah. Um, I, I would say that the person who's doing the checking in, that would be, uh, one person, uh, that's involved there. Um, and pretty much just, just the person. There are, like, other people who are around in line. Maybe the speaker is involved as well, um, somehow, so that can kind of inform some of the implementation as well.
- 20:10
And then our, uh, emotional side of this. Hopefully, after our solution's implemented, we're all feeling, like, good about that. But maybe some people are feeling a little uncomfortable, right? Uh, like, creeped out by the fact that the conference somehow has your facial recognition information. Uh, and that might be a good spot for you as a product engineer to be like, "How about not?"
- 20:32
Uh, let's come up with a different, uh, solution for this particular job. Uh, okay. So, um, this kinda goes back to... Oh, oh. Sorry. Let me back up. Um, in jobs theory, there's actually, um, two times that your product is hired, or two categories of hiring. One is, uh, called the big hire. That's when you actually sell the product and person gives you the money, and two is when they use the product, and if they use it multiple times. Like, uh, I went to Smash
- 21:02
Burger, or no, Super Duper. Super Burger? What- Whatever. It's really close and it's really delicious. Uh, go mob them later. They're really good. Um, but, uh, and they were really nice to me, so seriously, go give them your money. Um, but, uh, so the, the big hire is when I, uh, paid my money for the burger and received that burger. The little hire was every bite that I took out of that burger, and if I stop early and throw it away, I'm not gonna be standing on stage telling you all that it was delicious, um, because I didn't like it. So you actually care a lot about users actually using your software.
- 21:31
It's not just about getting them to pay for it in the first place. So, um, y- you define your success by repeated progress. Uh, so you need to ask questions that will, in fa- influence the, uh, system. B- uh, like, how do you measure progress? Do they do it more than once? Sometimes they're not gonna do this more than once. Maybe this is the only workshop you come to, and then you're gonna leave and never go to another workshop ever. Probably not, right? So there's, there's some potential to use it more than once. And actually, if we were actually building this app, our customer would be the, the conference. It wouldn't be all of
- 22:01
you. Um, and so is the conference gonna use it more than once? Uh, what should we build, change or instrument, defer or not build, uh, and what does facial recognition become after we understand the job? I think once we, uh, now that we understand the job, we probably don't need the complexity of facial recognition, and maybe, like, NFC chips inside the badges could work. Um, but, like, then there's a whole other host of other problems that we now have to associate to that. Um, but by understanding the job to be done, it expands your
- 22:31
horizons on what you can possib- like, what possible solutions there are. And again, you're, you're focused on the problem, uh, and less on the solution until, like, you've decided, okay, which direction do we want this problem tree to go? Uh, so why do you need to know this? Uh, it gives you, uh, language, uh, for system shape questions. If, if a task comes to you and it doesn't have, uh, some sort of job to be done on, uh, attached to it, then you go back to your PM and you say, "I don't know enough about what this task is all
- 23:01
about to design a good system for this." Um, and having the language like, uh, well, what are the functional impacts and the social and the emotional progress points, um, that are going to impact, um, my implementation and architectural needs? Um, that is going to help make sure that you end up building the right thing. Um, and without the job, uh, you can just build the requested feature, totally missing, um, building the parts of the system or expanding the primitives that are available, uh, that users actually need.
- 23:32
So let's get back to some questions here really quick, and then I have one more framework that we're gonna talk about, uh, and then we will be done, which means we might actually be in a pretty good place as far as time has go.
- 23:47
Okay. How do you decide what to build, uh, without metrics, uh, in this era? So this era probably talking about, like, before you've shipped anything. You don't have any users, so how do you decide what to build in that, uh, phase? That's where the Mom Test comes in really handy, um, because it, you're able to... And actually, because we have AI, we can prototype things really, really quickly. So you validate the problem exists and that it's an in- interesting enough problem, then you build a simple solution that has, like, all kinds of paper cuts and whatever. But see
- 24:17
if, uh, people, uh, resonate with that. Watch them use your software and, and just s- if you can't get anybody to try it out, then, um- That's a signal. Um, and so you wanna find something that's, um, important enough for somebody to want to try it out. Um, if you are at an existing company and you're evaluating, um, adding a feature to a product, s- same sort of thing except in that case you have customers that, um, are using your product. You need to, uh, get in contact with those, and hopefully your PM has some
- 24:47
mechanism for doing that. Um, and then, um, through those connections, you do that same sort of thing. Make sure you understand the problem really well, build a prototype, and see how they feel about that. Um, hopefully that answers that question. Okay. So three tips, uh, from going from a product role to a product engineering role. Oh, wow, okay. So I, I'm assuming you mean by product role, you're like product owner, product manager, something. Um, I would s- um, I would talk to
- 25:16
engineers about the system and just interrogate them. And like, if, if... I, I'm a very open person, so I would just literally say, "I want to get into engineering, uh, so could you help me understand the system and like what I need to know about engineering at this company?" Um, and, and just spend a lot of time, um, trying to understand what the constraints of the infrastructure are, uh, how the system is, uh, designed. And, um, I don't know, have lunch with them. Like, s- hang out with the engineering team.
- 25:47
Um, stop being so siloed. Uh, okay, sweet. Uh, what do you do if your colleagues say there isn't a problem to solve, uh, but there is? Oh, yeah, okay. Is the user always right? No, the user is not always right. Uh, or if they-- Uh, you, you can have, like let's say you, y- your, uh, company, you have 50 users, um, th- like, that are businesses or something, and you've got one who's r- like really harping on you about this. Uh, if, if they're the one that's like covering ninety percent of your income,
- 26:16
then yes, they are right. Whatever. Yes, sir. Um, but, uh, but often that's not the case. You're gonna... You, you definitely have situations where one user like really cares a lot about this particular thing, uh, and it's not representative of other users. So how you suss that out is just by talking to other people. Like, what was the last ti- when was the last time you had this problem? Um, and what, what did you do about it? Like mom test it to a bunch of your other users. Um, and it, it, you know, if you end up realizing, oh yeah, like
- 26:46
there's not a lot of people who feel this way, then yeah, maybe the user was wrong in that case. Uh, I do not think that the user is always right, though, uh, often they are directionally right. Like, we really, really want this fe-- Like, often the user is gonna come to you with a solution. Um, they're gonna say, "I have this problem, and then here's what would solve it." Um, or they, they'll just skip the solution, and they'll just be like, "I need an export to PDF button right here." And, and that's as far as they'll go. And, um, you need to be the one to ask questions and try
- 27:16
to get at the heart of what they're trying to do. Once you get to the heart of what they're trying to do in that job, then you can go around to the other customers and see, like, Does this sound like, uh... Well, you don't ask, "Is this a problem for you?" You just say, "When was the last time you experienced this pain, and what did you do instead? Oh, you're like clicking fifty menu items to get to that? Great. That is a good signal. We are going to, uh, solve that for you." Hopefully, that answers your question. Okay, we'll do like two or three more. Um, do I really need to understand the code and architecture for
- 27:46
incident response if I can mitigate issues without that knowledge? Okay. Um, so I mean, it depends on how many millions of dollars you're m- losing a minute, um, I guess. So like it de- kind of depends on the scale of your business. Uh, if I-- When I was at PayPal, if I broke, um, the, the, the part of PayPal I worked on was, uh, cross-border transactions. Um, and if I broke that, like people couldn't send money, uh, to people, then yeah, we're losing millions of dollars rapidly. Um, and so, uh, if we're
- 28:16
talking about incident response, I mean, I actually, interestingly, I got attacked by, uh, some, um, bot on a DigitalOcean box, uh, recently on my, my personal website. And, uh, so I recorded a video of what I did to mitigate that problem. Uh, so that's going up on my YouTube channel soon. Go subscribe. youtube.com/@kentcdodds-vids. Trying to get the just Kent C. Dodds, and they are not doing that for me. But, um, anyway, uh, so, uh, I literally just said-- went over
- 28:46
to my agent, and I, like it knows what I mean when I say this. I just said, "Production is down. Figure it out." And it, and it did. And it, like, it pretty much did everything. It, it figured out and told me, "Here's what's going on. You're getting attacked by a bot." And I said, uh, "Do you know how to fix it? Fix it." And it did. So like there is an element of maybe our agents can kind of just handle things. But again, like this is my personal website, which I, I do get a lot of traffic to my website, um, a- and so it is important, and it's actually a part of my business 'cause it's the only way people can join my
- 29:16
Discord server. And like there-- It is important for my website to be up. And it's not like a simple, you know, just hosted on Cloudflare, uh, pages sort of thing. Like it, there is some complexity going on there. Um, but, uh, but it's not im- super important. I'm not losing anything. However long the agent takes to fix it, like I'd-- I'll let the agent do it, and I'm gonna go off and do something else. Um, but, uh, but if it was really important, then yeah, you better understand how that system works, and you better be able to very quickly diagnose what the problem is and guide the agent to... Like, even if you're using
- 29:46
the agent to de- debug and ultimately fix the issue, um, you're going to be a lot more, uh, successful if you really understand the code and architecture. Uh, okay, let's see. Um, I'll answer this one really quick. Do you feel systems these days are getting less secure, stable, and reliable due to the use of AI? Uh, I think it, it, um, hmm. I don't think AI has changed this necessarily. Um, I think that it has made, um, security
- 30:15
problems easier to, um, to... What's the word I'm looking for? Um, uh-
- 30:23
Exploit.
- 30:23
Exploit. That's the word. Thank you. Uh, easier to exploit, um, and also, like easier to identify. Um, and it's- Like, the lazy developer who, um, who didn't really care too much about security before is able to have a bigger blast radius now. Um, and so, like, in that way, yes. Um, but, uh, we always kind of have these problems. It's ju- it, it is getting easier to exploit them, though. Okay, great. And Mythos. Yeah, I just gotta say that, I guess. Um,
- 30:55
sweet. So we just have one more, and then I can, um, rest. I will... By the way, I will be around all day, uh, for the rest of this afternoon. I'm leaving tomorrow morning, so if you do have questions or anything that you wanna ask just one-on-one later, uh, you gotta find me. Uh, I'll be... I'll just probably stay in the hall over here. Uh, you gotta find me today, because I, I also have stickers that I brought as well. So, I- after this, I'm just gonna run out there, because they've got other people, I think. Kevin, do you have somebody else after this?
- 31:25
Yes, maybe. If, if nobody else is after this, then I'll just stay here. But, um, if not, then I'll, I'll just rush out. Okay.
- 31:34
So, prioritizing software changes. Uh, now we've moved on. We've gotten across the, the chasm, uh, of, uh, early adopters and everything. Now we're in the hands of the majority. We are getting lots of requests. So what are some requests that we could be getting in Just Get In The Workshop? Uh, actually, we've kinda talked about this already. You know what? I'm gonna skip that. We- and we're actually gonna write these down here in a little bit anyway. So, um, we'll skip that really quick. Um, not all
- 32:04
feature requests, uh, create value in the same way. So, um, uh, Wayne and I were talking about Bun on the podcast, and he said, um, Bun had all these i- other ideas, which are really exciting. Uh, they've been shipping like nuts in the last year. Um, although it seems... I don't know about you, you all, but I feel like it's slowed down considerably after the acquisition. Am I alone? Anybody notice that? I'm alone? Nobody... Who knows what Bun is? Me. All right. Okay. Good. Uh, all right. So anyway, they've been shipping,
- 32:34
like, tons of really interesting, useful features. However, they missed some foundational ideas, and the reason that Wayne said this was because I'd mentioned that I'd use Bun for some things, but I hadn't migrated some of my old node stuff over to Bun because they were missing some pretty key features that I needed, uh, to be able to do that. Uh, and so that's why he brought this up. Uh, and so there's this mental model for this called the Kano model, and so that's what we're gonna talk about for this last one. Uh, it is a 1984 paper about, um, attractive quality and must-be quality,
- 33:04
uh, where not all features are created the same way. Uh, and I wrote a... I, I've got another YouTube video about this titled, "I Hate Sprint Planning," uh, and this is how you fix sprint planning. So, um, let's open up the demo. So this is the Kano model right here. So in the Kano model, you have, um, these four quadrants that are on these two axes, the implemented and satisfied. And, um, you have actually five categories,
- 33:34
but two of them don't appear on this graph, because they should never appear in your code base, in your product at all. We'll talk about them. But these three are the delighters, performance needs, and the basic needs. And, um, the interesting thing about basic needs is that no matter how much you've implemented it, you can never get, um... Nobody will be satisfied until it's, uh, fully implemented, and it is possible to over-implement those, and we'll talk about that in a little bit. Performance things, you hit, like, a, a basic level, and people are like, "Yeah, okay." But if you
- 34:04
keep on delivering on that, then people are gonna be pretty jazzed about that. Um, and, uh, and it will make them happier and happier. There's probably a limit to this as well. Uh, and then delighters, uh, people aren't even expecting these. It's like, if you have it even a little bit, barely implemented, then yeah, okay, uh, I'm feelin'- I like that a lot. And then you can, uh, continue to add delighters, and eventually, uh, crosses to performance needs. Um, the specifics of where all this is, you'll notice there are no units on this graph, so, like, it's a little
- 34:34
bit hand-wavy on that. Um, but the, this is the basic idea. So let's, uh, remove the examples. Do, do, do. And we're gonna add a couple requests. So, um, uh, let's see. You know what? Yeah, I don't, I don't know that I have time for us to do those requests. So we're gonna use the pre, pre-built ones. And look away. Don't look. These are already categorized. I, I knew I w- I should have done this. Dang it. Okay, don't, don't look. Stop. S- I see you looking. Okay, here we are. So we've got
- 35:04
these requests. This is for a food delivery app, so we're changing, shifting gears. We're delivering food now. We, we've expanded beyond Just Get In. It's Just Get In The House To Deliver Them Food. That's what it is now. It's it's getting weird. Uh, all right. So, uh, we've got these, these items. Email. So order confirmation emails are sometimes not sent. Okay. Real-time driver GPS tracking as a feature. Seems, like, pretty useful for food delivery. Estimated delivery time accuracy,
- 35:34
like how accurate do we need to be? Is it within two minutes? Is it within, like, 10-minute accuracy? Uh, and then surprise discount on next order. Like, you've finished your order, and oh, sweet, 25% discount next time. Awesome. And then shared cart. So you're, like, a team ordering lunch together. Um, maybe we can add some sort of shared cart experience to make it so you don't have to do a 40 text message thread with... and somebody has to awkwardly ask for money afterward. So, um, based on... My, my mouse keeps on
- 36:04
disappearing. Is that happening for y'all? No, it's not. I'll look at this screen instead. Um, okay. So based on the Kano model, the basic things, the, the things that absolutely must be there, uh, raise your hand and say which of these things would you say are basic needs.
- 36:21
GPS. GPS? Okay. GPS is a really interesting one. Um, we're gonna put it with basic, but I wanna talk about that one. What's next? ETA. What? ETA? Yeah. Okay. ETA is an interesting one. I'm not gonna fill that one in, uh, just yet. Um- I wanna get the other, there's one other basic that I'm looking for. Email. Email, yeah. If, if I'm not getting my email confirmation, then I'm like, "Who are you?" Like, what, what have you done in, in the last year? So if we, uh, pop up
- 36:51
just email right here, anywhere down here, I am not satisfied. I'm getting, like, only some of the emails or something. No, that's not gonna do it for me. Every other app, not just food delivery, but every other app, has reliable email. I'm expecting that. That absolutely is required. In this case, making email a specific need, shouldn't we make it a bit more general? So then- Like a notification ... like- Yeah, yeah, fair point. Um- Like ... notification. And we'll go ta-da.
- 37:22
A notification with confetti. Yeah. Okay. That's very good point. All right. So, um, I do wanna talk about GPS, but I wanna, uh, I'm gonna bring that one in last. So let's talk about performance. Now, somebody mentioned ETA was a good basic. I would actually put it as a performance, and the reason is that as long as you're within, like, a reasonable range. Like, if you're within, uh, two minutes of people arriving on time, then, like, okay, yeah. Like, I realize that there are stoplights and
- 37:52
whatnot. Like, that's, that does happen. But if you somehow manage to, like, get me... Well, uh, let's first start with b- um, before. If you say it's gonna be 10 minutes and it's actually, like, 30, I'm pretty ticked. If you say... E- even if you overdeliver and you underpromise, overdeliver, and you say, "Well, it's gonna be 30 minutes," and then they're there in 10, I'm like, "Bro, I'm not even home yet. Like, gosh." So, uh, it's not necessarily overpromise, underdeliver or what... The opposite of what I just said.
- 38:22
Uh, you need to hit some level of, like, satisfaction there or implementation. But you know, if it, if I'm, like, looking at my phone and it's counting down with every step that he takes, and then he drops it on my doorstep right when it hits zero, like, wow, that's pretty cool. I don't know that I'm necessarily gonna, like, be looking at my phone all the time, but I will be impressed. Uh, so there is, like, a level where depending on what you're looking for, this is going to add a s- a certain amount of satisfaction for people and surprise, and, and,
- 38:53
um, they'll be excited about that. Another good example of this, how many of y'all are web developers? You serve your app over HTTP. Wow, a lot less than I expected. Well, what did I expect? Well, in, in that world, I know some of you are native developers and you're like, "Yeah, people download my 30 gigabyte app, and it takes them 20 minutes, and nobody complains about that." Well, us in the web world, if it takes less, uh, more than a second, then people leave. Uh, so there you are. So in the web world, um, it depends on what it is
- 39:23
that you're building, but you... One performance metric, uh, literally, uh, performance need, is how fast your website loads. And in some situations, being like, uh, one second, all right, that's good. That's gonna put me at satisfactory. I'm, I'm happy. But you can, um, push that further. Okay, 250 milliseconds and 100 milliseconds. Now, like, whoa, I'm really impressed by that. So that's, that's what we're talking about when we're talking performance needs. So as long as... For ETA, as long as you're reasonably good, then that's fine, but you can push beyond
- 39:53
that. Uh, whereas with a basic need, if you go beyond the implemented, then it gets to be a little bit much. Like, all right, so I received three notifications. He's, uh, he's just picked it up, and now he's driving to you, and he just passed the stop sign, and then, like it can be too much. So that's kinda the difference between basic and performance, is, um, whether or not it, uh, really matters if you get more and more of it. Okay. So now let's talk about, uh, discount and group order. Where, where should those
- 40:23
be categorized? Delighters. Yeah. Both of these are delighters, uh, I would say. Uh, the group order, I think we're starting to get used to being able to, like, have more collaborative software. So I would actually suggest that one's starting to move into the performance realm. Um, but, uh, yeah. So for delighters, these ones, like, if you even have a little bit, um, I'm gonna be like, "Oh yeah, sweet. I'll take a 5% discount. Oh man, I'll take a 90% discount. Heck yeah." Like, I'm, I'm loving that. Uh, or
- 40:53
actually once you pass this, it's like, "Is there something wrong with this company?" Like... So that, like, you could maybe go a little bit too far with that, too. Um, and, uh, yeah, group ordering, "Oh, that's nice that they have that feature. Oh wow, like, it's really easy to use." See, that's where we're going with that. Okay, I think we all pretty much get the delighters. The, uh, the delighters are the interesting one because that's the one that's most exciting to work on, right? Who wants to work on notifications? Like, zero people in this room wanna work on that. But, like, if you don't have that, then
- 41:23
your users will also go down to zero. Like, they will not be happy with that. So you have to have those delighters or those basic needs in place. You cannot, uh, o- overdelight, uh, your basics. Like, if you don't have the basics, then it doesn't matter what your delighters are. There's a little bit of an exception with the early adopters because they are willing to, like, experience all the paper cuts to get to that solution that you're, you're doing for them. Um, but, uh, yeah, uh, once you start getting to the level where you're trying to scale it out to
- 41:53
majority, uh, you absolutely have to have those, uh, basics in or you will not be successful. Now let's talk about GPS. I agree that this is a basic need, but, um, back in 2015, this would've been a delighter. Like I-- "You mean I can watch my driver where they are right now?" And so yeah, you have an ETA and it's, like, right around here, but I can judge for myself and I know they're coming up to that, uh, train station and, like, there, there's no way they're getting through that. They stop at the train station. So now, like, this is w- was really, really
- 42:23
awesome in 2015. But, uh, it eventually moved down, uh, into performance and now, like, I'm expecting it's gotta be there. Like, it just has to exist and if you can make it more and more accurate, like okay, I feel pretty good about that. Yeah, that's pretty good. Um, but now I would agree, I think it's a basic need. If you don't have it at all- Uh, and, and at least at... I don't know, I, I do think that maybe it's kind of sitting between performance and, and basic need. 'Cause, like, you can be more accurate, but honestly, am I gonna really care that much that it's, like, that much more accurate than
- 42:53
the next person? As long as it's within a reasonable accuracy, which we could call fully implemented, then I'm fine with that. So, um, the, the point there is that your, um, the, the different items that you sup- uh, support from your application, uh, or your software solution, those pieces can move on the Kano model, but they only move one direction. It goes from delighter and it... So if you implement a delighter, this is, like, a really nice feature, nobody else has it, your competitors don't have it yet,
- 43:23
um, it can either go from delighter down to performance, or it can just pop off 'cause nobody cared about it. Uh, and so you're like, "Nope, we're, we're gonna remove that feature. Nobody was using it anyway." Um, but once it goes down to performance, then it's gonna go down to basic need. Uh, and now you have to do it. Uh, so this does happen, uh, over time, it- which means you can't just be like, "Okay, we prioritized all of our tasks and we're gonna just leave it there." No, you have to regularly be looking at, okay, what are our competitors doing? Oh, they added this delighter. Well, we probably better
- 43:53
start thinking about, like, looking into that and, and seeing if we can solve the problem and our, and our own take on that problem. So that is, uh, the basics of the Kano model. There's a couple of things, uh, about that. So, uh, Wayne was the one who introduced the Kano model to me, and he gave one of my favorite analogies for this. If there's no toilet paper in my hotel, that's a bad experience, but if I have 100 rolls of toilet paper, it doesn't increase my experience of the hotel. Uh, and actually he added-- I should have added it to this, the thing, but the next thing he said
- 44:23
was, "And it might make me worry about the food."
- 44:28
So, so, um, there is, like, if we were to take the, the Kano model and, uh, follow this line, I would say continuing this, the green line, the basic needs would probably go down. The more it's fully implemented, uh, yeah, it starts to become a deterrent for you. Um, so but that, that said, uh, slide, there we go. Uh, you have to have, um, the foundation. So, like, don't bother wasting a bunch of time on the de- delightful stuff before getting the foundations right.
- 44:58
Fo- focus on foundations and primitives. Make sure you have good feedback systems so that you know that you're covering your bases as far as basics are concerned. Uh, okay. So, uh, did I? Yeah, there we go. So why product engineers need the Kano model. Uh, product managers are responsible for identifying the value. Um, you also have some responsibility there as well, but, like, in the perfect world, product manager is gonna find where that value is gonna come from, and they're gonna deliver that to you. And your job is to make sure you understand
- 45:28
that, uh, and then, uh, convert that into the technical requirements as the product engineer. So you decide the reliability, reversibility, like, how much does it matter? What's the, uh, performance constraints? Uh, and so in, in each one of these categories and it helps you make the right, uh, decision. Not just which one should I do first, but how much technical, um, uh, expertise or, or, uh, effort do I put into it? So, um, for basics, we're gonna focus on reliability, completeness, ownership. Like, these
- 45:58
things we absolutely have to nail and we have to do it right. We don't want notifications not showing up. For performance, these are measurable quality gradients. What that is, is, like, how much does ETA actually matter? Where is the level of satisfied do I need to get to? Um, because, like, if you have those performance metrics under the line, then that's going to be a problem as well. So you need your basics up, you need your performance up, at least to that line. And once you have all of that, now you can start playing around
- 46:28
with, uh, adding things to that. So you're going to need to measure things to make sure that you're hitting, um, those, uh, goals on the performance metrics to make sure that you're at least at the level you should be. Uh, and then delight, uh, delighters, um, these are, like, kind of experiments. Uh, okay, so maybe you, you do think that this is gonna be kind of core to your identity and everything, but still, a delighter is not a basic, and you need to make sure that you're covering your bases on the basics. So you're gonna be thinking about, okay, with this experiment, how much do I want to
- 46:58
invest in making sure that this is solid, reliable every... I mean, of course we want everything to be reliable, right? But there's only so much time, there's only so many tokens. Uh, and so this is where you're gonna, um, maybe have a little less commitment from an architectural standpoint. Maybe you kind of, instead of integrating it into the existing system, you have this other s- uh, system where there you can do a lot of learning and then once you've learned and kind of gotten the shape of this new thing, you can find a way to bring it back into the full system. All right. Now there, like I said, there are other two other parts of
- 47:28
the Kano model. One is, uh, the indifference category. So these are the things where the user, uh, like you decide, "Ah, it doesn't really make a difference whether you have this or not. I don't care. I don't need that feature." Uh, so you don't want to make this, like, a, a permanent part of your product and in fact you want it out of your product as quickly as possible. It's just dead weight that you have to maintain as an engineer, it's not useful. And this is why it's important for you to understand the Kano model because you need to go to your, uh, your boss and say, or your,
- 47:58
uh, product manager, say, "Listen, we spent two weeks maintaining this feature. Is anybody using that? Like, does anybody even care about this thing? 'Cause if they don't, maybe I should not spend two weeks working on figuring out how to get that migrated over to the new system." So, uh, indifferent category you definitely wanna know about. And then, uh, reverse. This is the sort of thing that you just really don't want in your product at all. So, uh, we were talking about the, the facial recognition thing where like, oh yeah, maybe when you sign in, it could
- 48:28
like automatically post to their social media saying, "I'm going to this event." Like, they would probably really hate that. I, I would hate that a lot. Um, and so these are the sorts of thing that you as an engineer-- Like, uh, uh, let me ask you this. There are products that do shady things that we don't like as users. That, that's a given. I think we can all agree on that. Who built that? We did. Software engineers are building that. And, and I'm not saying that the buck stops here
- 48:57
necessarily, but it kinda does. Like, we're the ones who are building it. So, like, could you please push back on those stupid ideas that are, like, making our lives awful? Like, software can be just this wonderful thing that can make the... Fulfill our lives so much better, and it's software engineers just like us that, that, uh, do the opposite as well. And so, um, like, take a stand and be like, "No, I'm not gonna do that." And yes, I realize that maybe
- 49:27
you... Yeah. Thank you. Uh, I realize, like, okay, yeah, Kent, that's, that's nice as a self-employed person. Um, but, uh, I don't, I don't know. I feel like, um, have a little respect for yourself. There you go. So, uh, I'm gonna answer a couple more questions. We have four minutes, I think, until I'm, I'm booted out of here, and before I do this, uh, I'm just gonna look... Ah, shoot. You know what? I don't have time for questions. Here's what we're gonna do. Uh, I, I don't know if there's
- 49:57
somebody in this room after me. Is there anybody? Is there- There is. There is. Thank you. It's PayPal. Sorry, what? It's PayPal. It's PayPal? I loved PayPal. Loved working at PayPal. So we're not gonna be a problem for PayPal. I'm gonna run. I'm not gonna talk to any of you, and I'm just gonna run over to the hall over here, and then if a- anybody who wants to talk can talk. So let me just wrap up. I don't want you leaving yet. You haven't clapped yet. Gosh. So just really quick, um, the Mom Test helped us with idea or early
- 50:27
idea evaluation or validation. It's not just for startups. It's also for any new product idea that you have in your company. Um, framing user requests with jobs theory will help you make sure that you're not just building the solutions as the, they come to you from the user, but that you can manage actually to solve many user requests with a single solution. And, uh, uh, the Kano Model will help you prioritize all of the, uh, changes that are coming down the pipe and make sure that you're not shipping anything that's in the reverse category at least.
- 50:57
And with that, um, I want you to remember my original thesis. When AI agents level the implementation playing field, the differentiator becomes building the right thing. Um, and this is why I say this is the last skill y'all need to learn. Uh, once the AI agents figure out how to do this, then who knows? Like, this AGI, we... I don't know what we do in this industry. But this, what's really cool about this is even if I am wrong and agents stop right here, they don't get any better than they are right now, and we're still having to babysit them and
- 51:27
all the stuff that we're doing now. If I'm wrong, if you do this, you are one of the most valuable members of your team at your company because this is where the actual value comes from. When you can take your technical expertise and marry it to the actual problems your users are having, then you're the most valuable person at your company. And that is it. Thank you all so very much.