Enjoying this issue?
Get tomorrow's AI & engineering digest in your inbox — hand-picked, summarized, and always spam-free.
TLDR
As AI agents automate implementation, the differentiator for product engineers becomes building the right thing. Kent C. Dodds argues that understanding user jobs (via Jobs to be Done theory) and prioritizing features (via the Kano model) are the critical skills that separate valuable engineers from those who just implement requests. The talk walks through how to dig past feature requests to uncover the functional, social, and emotional dimensions of a job, and how to categorize features into basic needs, performance needs, and delighters to guide technical decisions.
Key points
Feature requests should be analyzed with 'why' questions to uncover the underlying job to be done.
Jobs to be Done theory has three dimensions: functional, social, and emotional progress.
The Kano model categorizes features into basic needs, performance needs, and delighters.
Basic needs must be fully implemented; over-implementing them can reduce satisfaction.
The speaker predicts that product judgment will be the last skill needed as AI improves.
Techniques
- Jobs to be Done theory
- Kano model
- Mom Test
Stop scrolling. Start reading smarter.
Receive the day's most important AI & engineering updates in one concise email. No spam.
Transcript (captions)
So, a as some of you are uh heading out, um actually maybe we let's make this less awkward. I don't want anybody 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. There you still got to move. Um, we're not going to do the full uh stretch or uh air squat thing, but you can just
stretch a little bit. Make it less awkward for the people who want to leave. It's okay. We don't want them to feel bad. Okay. Yep. You can stretch your legs, whatever you want to do. Just
don't hurt yourself. Uh, and then go ahead and sit. Okay. So, we've got uh I think I've got 50 minutes. 5-0. So that's what you're uh
in for if you decide to stay. So now we've got the just get in the workshop implemented and we're rapidly adding features based on user requests. So we 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 product as well. Um, okay. So, what should the live request be? What did what did somebody ask us to add to just get in the workshop? Just throw it out or raise
your hand. Yeah. >> Oh, so like a way to know how long the queue is. Okay. Yeah. >> Oh, okay. A little bit like the Disney Fastpass thing then. Yeah. Like a remote
weight list. Yeah. Okay. >> Oh, yeah. To to know how much uh CO2 you're going to be breathing when you get in there. Yeah. That's Yeah. >> 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. 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 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 does that mean in the context of our app?
slow. >> 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 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.
Oh, the schedule could be the problem like the fact that Tis was speaking across the hall from me. That really bugged me. Um because I like TIS a lot and uh yeah. Any other like Yeah.
>> Yeah. Yeah. Yep. That's true. The um 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. >> Oh, good question. So the question is in in this role playinging 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 followup. >> What's my motivation? Am I trying to get >> Oh yeah. >> 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 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. >> 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's one of the uh
things that we as software engineers need to ask ourselves frequently is like okay I'm going to I'm going to go in here and I'm going to optimize the heck out of this thing. It's going to 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 that it would cost this much because this other offshooting problem, then we never would have gone this direction anyway. We
would have gone a different direction. I called 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
really hard problem to solve. If I'd known that all the way back here, then I would have gone this way instead." And we often don't do 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 Klay
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 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 u 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 deep into uh jobs theory um on that uh deeper or 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. Um 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 not just turn
feature requests into implementation. I know some of you here in 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 with no vision
whatsoever, no taste, all judgment out the window. It would be awful. Uh so, uh each feature 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 going to be on the the product manager, of course, like they
they're often going to 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 applying the vision of the product to the requests as they come in. Uh, and so, 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 want to 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 going to 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 we're uh you ask to reveal what the job is. And
we we're going to come down to a job statement uh here for our facial recognition thing. So, who is this for? What 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. 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 when does this problem happen right here when people are going getting
into a workshop? Okay. And then what progress do they want? What is the progress that the user is trying to do? Get in. That's why we named our our product this just get in to the
workshop. Um okay. And then finally, what do they do currently? Well, it's a 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 that hang on to that. Put a pin in that. Um run MCP guy. I like that. That shirt is cool. You you know U Michael uh G.
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 1010, help me get into the workshop quickly um so that I can learn about product engineering um 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 going to say that's that's wrong.
But if you get a request that doesn't have a job statement attached or you've never heard you don't know which job statement this request is coming from, then that's going to be uh you are not
understanding the the problem well enough. Or maybe the PM just skip that part and you're going to 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 seemed like a good idea to one person but wasn't generally applicable to everybody else. So getting down to the Y
why and then turning that into a job statement uh helps a 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 the thing? And then how do they feel when they're using it? Are they embarrassed or are they like shy or are they excited? Are they what? And and these things 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 one um, by the way. So, how many of you hate it when I say React one? I'm just kidding. Some of you probably don't like React. I like React and React one. It's over. The the game
is actually over. Um, there will be something that comes after React, of course. Like, it's it's not like it's going to last forever. 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. that it it has 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 as far as that's concerned and so react one here's here's the reason this is what my video is about react one because it started with functional that was that was the thing
at the time everybody was either backbone maybe Ember uh AngularJS that's what I was using and uh React was just faster uh considerably faster despite all the like rerenders 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 really solves
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 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 team uh if I want to get a job in this industry I've got
to learn React. And so everybody is learning React. Now of course there are still others out there and Angular 2 came out and know people are using those. But React was just so dominant.
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 kind of cool because 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 problems anymore or we
got view and it's like easier to learn. That's arguable. But like 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 libraries definitely a product. Um that's pretty interesting.
Okay. So, um, one thing that Jack Ryan 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 going to be 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
select channel. Uh you can have a specific one with uh individuals that you really respect their decisions and and 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 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 pro 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 going to be, oh well, we just need to put a button
right here in instead of just having it right there and and now it will be a lot easier. Other times it's going to be, oh yeah, there's no way we can do that right now and now 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
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 it depends or something I I don't know bad 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 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 need you to throw out these things. So, like
what is the state workflow integration sorts of things that we need to think about if we're building this app? Uh just get in the workshop. >> Start on time.
>> Start on time. So, like the speaker always starts on time or Okay, so I messed that up is what you're saying. [laughter] Well, in my defense, uh, people weren't
gone until, uh, 2 minutes after I should have started. >> The solution, >> 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 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 are going to add NFC no let's you know what let's stick with the face recognition idea um just because I think it'll be fun for
something later um but uh yeah so we're going to add face facial recognition what is some of the state uh that we're going to need to maintain for that. >> Yeah. Database of everybody's faces.
That's going to uh impact a lot of things. Yeah. What else? >> A what? >> Encryption. Yeah. Okay. So, we're
encrypting things now. The government won't get mad. Um just kidding. No. Uh other other things we're going to need. Yeah. >> Number 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 or the social aspects like who is using it and who are they interacting with when
they're using it? >> I'm going to have two lines. >> You're going to have two lines. Oh yeah, that I mean now we're talking about parallelization uh which also saw uh is
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 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. 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?
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 [laughter] let's come up with a different uh solution for this particular job." Uh okay. So, um, this kind of 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 the 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 Smashburger or not, 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
going to 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. It's not just about getting
them to pay for it in the first place. So um you define your success by repeated progress. Uh so you need to ask questions that will in influence the uh system but uh like how do you measure
progress? Do they do it more than once? Sometimes they're not going to do this more than once. Maybe this is the only workshop you come to and then you're going to 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 you. Um and so is the conference going to 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 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 horizons on what you could
possib 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 systemshaped 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 about to design a good system for this. Um and having the language like 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 a requested feature totally missing um building the parts of the system or expanding the primitives that are available uh that users actually
need. So let's get back to some questions here really quick and then I have one more framework that we're going to talk about uh and then we will be done which means
we might actually be in a pretty good place as far as time is go. 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 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 interesting enough problem. Then you build a simple solution that has
like all kinds of paper cuts and whatever, but see if uh people uh resonate with that. Watch them use your software and just if you can't get anybody to try it out, then um that's a
signal. Um and so you want to 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 uh 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 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'm assuming you mean by product role you're like
product owner, product manager thing. Um I would um I would talk to 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 hang out with the engineering team uh 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 your uh company you have 50 users um like that are businesses or something and you've got one who's like really harping on you about this. Uh if if they're the one
that's like covering 90% of your income, then yes, they are right. Whatever. Yes, sir. Um but uh but often that's not the case. you're going to 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 sus that out is just by talking to other people like what was the last time 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 you know if you end up realizing oh yeah like there's not a lot of people
who feel this way then yeah maybe the user was wrong in that case. Um I do not think that the user is always right though. Uh often they are directionally right like we really really want this.
Like often the user is going to come to you with a solution. Um they're going to say I have this problem and then here's what would solve it. Um or they they'll just skip the solution. 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 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 50 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 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 losing a minute. Um, I guess so like it 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 crossber 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 talking about incident response, I mean, I actually, interestingly, I got attacked by, uh,
some, um, bot on a digital ocean box, uh, recently on my my personal website, and 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.comkensyods-vids trying to get the just kydods and they are not doing that for me. But um anyway uh so uh I literally just said went over 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 and so it is important and it's actually a part of my business because it's the only way people can join my 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 super important I'm not losing anything, however long the agent takes to fix it, like I' I'll let the agent do it and I'm going to 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 the agent to 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 I don't think AI has changed this necessarily. Um, I think that it has made um security problems easier to um to what's the word I'm looking for? Um,
>> 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 blaster radius now. Um and so like in that way, yes. Um but we always kind of had these problems. It's just it is getting easier to exploit them though. Okay, great. And
mythos. Yeah, I just got to say that I guess. Um sweet. So, we just have one more and then I can um rest. I will, by the way, I will be around all day the rest of
this afternoon. I'm leaving tomorrow morning. So, if you do have questions or anything that you want to ask just oneonone later, uh you got to find me. I'll be I'll just probably stay in the
hall over here. Uh you got to 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? 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,
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 kind of talked about this already. You know what? I'm going to skip that. And we're
actually going to write these down here in a little bit anyway. So, um, we'll skip that really quick. Um, not all feature requests, uh, create value in the same way. So, um, Wayne and I were
talking about Bun on the podcast and he said, uh, Bun had all these other ideas which are really exciting. 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 slowed down considerably after the acquisition. Am I alone? Anybody noticed that? I'm alone. Nobody who knows what bun is. All right. Okay. Uh all right. So anyway, they've
been shipping like tons of really interesting useful features. However, they missed some foundational ideas. The reason that Wayne said this was because I'd mentioned that I'd used 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. 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 going to talk about for this last one. Uh it is a 1984 paper about um attractive quality and must be
quality. Uh where not all features are created the same way. Uh, and I wrote a 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 KO model, you have um these four quadrants that are on these two axes, the implemented and satisfied. And
um you have actually five categories but two of them don't appear on this graph because they should never appear in your codebase 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 at fully implemented. And it is possible to overimplement 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 keep on delivering on that, then people are going to be pretty jazzed about that. Um and and it will make them happier and happier. There's probably a
limit to this as well. Uh and then delighters, u 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 film I like that
a lot. And then you can uh continue to add to lighters and eventually u crosses a 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 bit hand wavy on that. Um but the this is the basic idea. So let's uh remove the examples and we're going to 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 going to use the pre pre-built ones. And look away. Don't look. These are already categorized. I I knew I I
should have done this. Dang it. Okay, don't don't look. Stop. I see you looking. Okay, here we are. So, we've got these requests. This is for a food delivery app. So, we're changing
shifting gears. We're delivering food now. 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 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, 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
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 card
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 disappearing. Is that happening
for you 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? GPS. >> GPS. Okay. GPS is a really interesting one. U we're going to put it with basic,
but I want to talk about that one. What's next? >> What? ETA. Okay. ETA is an interesting one. I'm not going to fill that one in uh just yet. Um
>> I want to get the other There's one other basic that I'm looking for. >> 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 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 going to 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. >> Like a notification. Yeah. Yeah. Fair
point. um >> notification and we'll go tada. A notification with confetti. Yeah. Okay, that's very good point. All
right, so um I do want to talk about GPS, but I want I'm going to 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 stop lights and whatnot. Like that's that does happen. But if you somehow manage to like get me Well, let's first start with u before. If you say it's going to be 10 minutes
and it's actually like 30, I'm pretty ticked. If you say, even if you overd deliver and you underpromise, overd deliver and you say, "Well, it's going to be 30 minutes." And then they're
there in 10. I'm like, "Bro, I'm not even home yet." Like, gosh. So, it's not necessarily overpromise, underdel or what? The opposite of what I just said. 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 going to 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 a certain amount of satisfaction for people and surprise and and um they'll be excited about that. Another good example of this, how many
of you all are web developers? You serve your app over HTTP. Wow, a lot less than I expect. Well, what did I expect? Well, in in that world, I know some of you are native developers and you're like,
"Yeah, people down 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 more than a second, then people leave. Uh, so there
you are. So in the web world, it depends on what it is that you're building. But you, one performance metric, literally performance need is how fast your website loads. And in some situations
being like uh 1 second. All right, that's good. That's going to 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. We're talking performance needs. as long as for ETA as long as you're reasonably good then that's fine but you
can push beyond 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 kind of 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 be categorized? >> 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 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 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. 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 want to work on that. But like if you don't have that, then 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 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 at once
you start getting to the level where you're trying to scale it out to 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 have 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 stopped at train station. So
now like this is what was really really awesome in 2015 but uh it eventually moved down uh into performance and now like I'm expecting it's got to be there like it just has to exist and if you can
make it more and more accurate like okay I'm feeling 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 because like you can be more accurate, but honestly, am I going to really care that
much that it's like that much more accurate than 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 uh the the
point there is that your um the the different items that you uh support from your application uh or your software solution, those pieces can move on the KO 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. Um it can either go from delighter
down to performance or it can just pop off because nobody cared about it. Uh, and so you're like, "Nope, we're we're going to remove that feature. Nobody was using it anyway." Um, but once it goes
down to performance, then it's going to go down to basic need. Uh, and now you have to do it. Uh, so this does happen uh over time, which means you can't just be like, okay, we prioritized all of our
tasks and we're going to just leave it there. No, you have to regularly be looking at, okay, what have our competitors doing? Oh, they added this delighter. But we probably better start
thinking about like looking into that and and seeing if we can solve the problem in our in our own take on that problem. So that is uh the basics of the Kano model. Here'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 a hundred rolls of toilet paper, it doesn't increase my experience with the hotel. Uh and actually he added I should have added it to this the thing but the next thing he said was and it might make
me worry about the food. So so um there is like if we were to take the the KO 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 foundations. So
like don't bother wasting a bunch of time on the de delightful stuff before getting foundations right. F 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? U 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 going to find where that value is going to come from
and they're going to deliver that to you and your job is to make sure you understand 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, 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 going to focus on reliability, completeness, ownership.
Like these 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 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. Okay, so maybe you you do think that this is going to 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 going to be thinking about okay with this experiment how much do I want to 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 going to 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 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 the Kano model. One is uh the indifference category. So these are the things where the user like you decide that 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 your boss and say or your product
manager say listen we spent two weeks maintaining this feature. Is anybody using that? Like does anybody even care about this thing? Because 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 in different category you definitely want to 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, we were talking about the the facial recognition thing where like, oh yeah, maybe when you sign in, it could 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, 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 necessarily, but it kind of 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 going to do that." And yes, I realize that maybe you're Yeah, thank you.
Uh I realize like, okay, yeah, Ken, 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 going to look. Ah, shoot. You
know what? I don't have time for questions. Here's what we're going to do. Uh I I don't know if there's somebody in this room after me. Is there anybody? Is there
>> There is. >> There is. Thank you. >> Sorry. What? It's PayPal. >> It's PayPal. I loved PayPal. Loved working at PayPal. So, we're not going
to be a problem for PayPal. I'm gonna run. I'm not going to talk to any of you and I'm just going to run over to the hall over here and then if 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. [laughter] So, just really quick. Um, the mom test helped us with idea early idea valuation
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 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. 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 you all need to learn. uh once the
AI agents figure out how to do this then who know 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 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. [applause] >> [music]