Subscribe
Share
Share
Embed
Solo episodes from Kent C. Dodds on durable skills for people who ship software: judgment, accountability, problem clarity, and what stays valuable as AI takes on more implementation. Kent teaches directly on camera — no guest, one idea at a time. Complements guest interviews on Become a Product Engineer (Chats with Kent). Episode 1 adapts The Last Software Engineer; later episodes cover traps like building the wrong thing faster and skills like making user pain visible. Subscribe for evergreen episodes as the series grows.
You work at a company building a food delivery app. And you've got five items on your backlog, and you are tasked with figuring out what priority these need to have. You're in a meeting, and there are a lot of people who have differing priorities. And your job, as the software engineer who's going to actually build these features, is to be an active participant in this conversation. So what are those features? Well, first, we've got the real-time driver GPS tracking feature. And then we've got shared cart and group ordering. Surprise discount on the next order. This is one that one of your stakeholders is really excited about. Maybe they have a vested interest. They want a surprise discount on their own order. And then you also have estimated delivery time accuracy. And you do have a bug. There's some order confirmation email, sometimes doesn't get sent out properly. So the question is, how do you decide which one of these gets your attention first? And there's an argument going on in the room. You are the engineer who's going to be tasked with building these. Do you just let them all fight it out? Or do you take an active role in participating in that discussion? Well, if you're a real product engineer who is not replaceable by AI, then you're going to be actively involved in discussing which of these things is most important for your company, because that will set you apart from the AI that can just go ahead and implement it. And so how do you decide? Was it just choose the loudest stakeholder? Is it whatever you're most personally most excited to work on? Or have we promised a feature that we need to just get out right away? How do you decide? And there's actually a question that you can ask yourself to help you make this decision. And it is, what type of feature is this? How do we categorize these features? And in the Become an Epic Product Engineer podcast, Wayne Allen gave us a great model for this. He said, it's called the Kano model. This is better with Kent, and I'm going to talk with you about durable skills that you can develop to become epic product engineers and make the world a better place by making your products better. This is the Kano model, or at least it's three of the categories from the Kano model. There are actually five. We'll talk about the other two later. So you've got your basic needs, performance needs, and delighters. Let's look at the basic needs first. These are what Wayne calls hygiene features. So these are the sorts of things where if they're absent, then people are outraged, really upset, and if they're present, it's like, well, yeah, of course, this is going to be here. So Wayne in the podcast used an example of hotels. He says, if there's no toilet paper at my hotel, that's a bad experience. But if I have 100 rolls of toilet paper, that doesn't increase my good experience of the hotel. And in fact, he says, maybe I'd worry about the food if there was that many. So the basic needs, you're going to go only up until they are satisfied. And you cannot go beyond that by increasing that basic need. So which one of these things would you say is a basic need? You absolutely have to have this if you're going to be a food delivery. You might think a couple of these things are absolutely must-haves. But I would say that the must-must-have of these is the order confirmation email. That's got to be there. And so we're not going to leave this in the not implemented. We're going to fully implement it. And now we've got our basic need met. You could fully implement it by sending a bunch of emails. But that actually is going to make the experience worse. So if we were to draw this out further, we might say if it's beyond fully implemented, this might go down. So you do have to take it to the level of expectation for these basic needs and probably not go beyond that. Maybe you can make your email look really nice and whatever. So you can do some polish. You have to have it. It's just got to be there. So then there's the performance needs here. So this is the sort of thing where once you get to that level of satisfaction, you can actually do more and get better satisfaction. So Wayne references the hotel industry again. And he says the hotel industry has the star rating from one-star hotel to a five-star hotel. All the features along that are very well understood by the industry. And so if you are a three-star hotel and you deliver a four-star service, maybe the customers don't necessarily understand the distinction, but they can kind of feel that. And that's a really good thing. They're going to feel really good about that. Now, the opposite is also true. If you promise a four-star experience but only give a two-star experience or a three-star or a one-star experience, then all customers are going to be really upset. So matching at least where your customers' expectations are as far as their experience for these performance needs, that's going to be really important and just make sure you don't go below that. So maybe it's an over-promise or under-promise, over-deliver sort of thing when it comes to this. So an example of a performance need from our example here is this estimated delivery time accuracy. So if you're not accurate at all, you say they'll be here in 20 minutes and then they're knocking on the door. I mean, maybe they'll be like, oh, that's nice. Or maybe they'll be like, ah, I'm not home. Come on. Or if you say, they'll be here in five minutes and they're not there for 20 minutes, yeah, that's going to be a bad thing. So we kind of have this expected level of performance on that. But if they say, OK, yeah, they'll be here in two minutes and they're knocking on the door, OK, yeah, that's fine. But you can take this even further. And if you say, they're walking up to your door right now and they actually are, wow, OK, I'm feeling pretty good about that, that's going to make me feel great. And then finally, on the three that we're going to talk about, we've got these delighters. So delighters are the sort of thing where, if you don't have it, it's like, yeah, I wasn't expecting it, so whatever. But if you do, it's like, oh, this is quite nice. So examples of this would be maybe the shared cart and group ordering and the surprise discount on the next order. So you don't have it, no big deal. But you have something in there, oh, OK, that was kind of nice. I wasn't expecting that. You have group ordering, oh, that's a sweet feature. Yeah, I'm happy about that. And for some users, that actually might kind of turn into something that becomes a performance or even a basic need eventually. Let's talk about the GPS tracking one here. So raise your hand if you think this one, oh, yeah, that's definitely a delighter. Well, you would be right in 2015. So the interesting thing about these different dots we've got on the Kano model is that they can change over time. So back in 2015, being able to look at your device and see, oh, the drivers are coming up to that intersection. Oh, wow, they've been waiting in the intersection a long time. Back then, it was just really cool. It was a wow moment for customers. Today, if you don't have this GPS driver tracking feature, then people are going to be like, ah, this is stupid. I'm going to go to a different app. And so these things can move to different categories over time. And what's interesting is once your competitor adds a feature, it actually kind of becomes your must-be. So it might be a delighter for your competitor. But if customers get really happy and excited about that, they'll start expecting that. And that becomes a performance need. And then it gets into the basic needs, which is what it is now. So you've got to get it up to fully implemented. Otherwise, your customers are going to be dissatisfied. And Sean Roberts on the podcast also said, what are we doing? That is upsetting to customers. What are we lacking that our competitors are not lacking? That's the space where these features have gone from delighters back into basic needs. When your competitor adds it, as long as the users really like it, it can kind of become a basic need for yourself. And there's an area where teams really often get this wrong. And that is like, well, if nobody's complaining about it, then it's probably fine. Or nobody told us how happy they are with this feature. So it must not matter to them. The fact is that customers are not going to praise you for things that are obvious. Hey, the checkout worked. Good job, team. That's not a thing that's going to happen. Or I received my confirmation email. Awesome work. No. Swizec Teller on the podcast said, in some ways, your software is good when people stop complaining about it. So that's just kind of the way that basics work. Silence, no praise, it's just fine. And you should not worry about it. However, if the basics are not there, or if they break, it's a completely different story. Some users will complain, the ones who are really invested or the really noisy ones who are thinking about everything all the time. But most of your users are not going to. They're not going to leave a ticket. They'll just leave. They'll find another competitor who can serve them better. And this is part of the reason that Don Norman on the podcast said that users just assume the workaround is required. So they will never tell you. They'll never complain about doing that. And so in an industry where you don't really have competitors or your users are not the one who bought the software, then they're just going to find workarounds for whatever they're doing. And they're not going to be satisfied. And that's a really great opportunity for a competitor. But if you are actively engaging with your users, the people who actually are using the software, not just the ones who bought it, but the people who are using the software, and you're watching how they're using stuff, you can see the workarounds that they're doing. Oh, well, email never comes through. But it's fine, because I just go to the website and see what to verify that it actually went through. That's not a good experience. And eventually, somebody's going to show them that it doesn't have to be this way. And that could be your competitor, or it could be you. So your goal is to make sure that these basic needs are met, and then watch your users to make sure that they're actually being met to that user's expectation. And if they're expecting something else, then you've got to change something about your feature to make it so they expect the right thing. And the tricky thing about this is that you cannot delight yourself out of broken basics. Like, if you've got basics that aren't working, like you're not delivering the food, then I don't care how good your discount is. I don't want it. I don't want to spend any more money on you, because you're not delivering my food. And so these basics have to be there. The delighters are only there once the basics are done. John Mulroy actually mentioned that a few years ago, Linear used to not ship features until they had zero bug reports or zero bug tickets. It's like, burn down the bugs and the bad experience, and then we can ship features. And what's interesting about this or sad is that AI makes all of this worse. So Dax Raad on the podcast said, the default place for our new coding agent abilities is to go work on the wrong things. And that's because, again, the delighters are the things that are exciting to work on. He also said, you're thrown at a junk drawer because we get excited about a feature, and we don't do the hard part of understanding where that feature needs to be or the natural pathway to get there. And that, again, is just because it's really exciting for us to build out these delighters. And because we have AI, we can just turn these things out so fast, and we're not being thoughtful about how that fits into the bigger picture. And then just kind of go in this bucket of features that is not a good experience either. So you can have too many delighters. And especially if you don't have the basic needs, that's not good. Even if you do, if you go with too many delighters and you're not thinking about how it fits into the broader picture, that actually can lead to a bad experience as well. So you need to feel free to ship more, but be very thoughtful about the things that you're shipping. And maybe, as many of the episode or podcast guests have said, slow down and think about it. So let's go back to this list. Now that we have all of these properly mapped out, we can sort them where basics come first. And so let's hit this build order. Our basics come first, and then performance, and then our delighters. And I would put the bug at the very, very top. This is like most important basic. And then you've got the GPS tracking that comes after that. The estimated delivery time accuracy, let's get that at least to satisfactory. Like, that's fine. You can leave it there. And you can start working on some of these delighters if you want to. But it's got to be at least at this base level. They should have nothing that's underneath the satisfied line. That's really, really important. So earlier, I mentioned that there are five categories, not just three. But the other two are not the sort of thing that you want to map out on the Kino model. These are the kind that you just shove off. And so the first is indifferent. These are the sorts of things that nobody cares about either way, and you do not want to spend any cycles on this. So for example, our food order delivery service example, custom profile avatar or accent theme colors. OK, maybe if you've got nothing else to do, then you could do some of these fancy polish things. But really, I think you should just push that off. It's not really the sort of thing that you should be spending cycles working on. And then the other one is reverse. So this is the sort of thing where their presence actually makes things worse. On this, you want to push back really hard. So an example would be a share your order pop up after checkout, or even automatically shared your order. You don't want that. That's a dark pattern. The user wanted dinner. They don't want their content or you to generate content for them and push it out to their feed. That is a bad, bad thing. So you'll get tickets for both of these kinds. Make sure that you categorize them properly. And really, knowing the name gives you the language to push back, and you should be pushing back on these kinds of features. So with that, I want you to ask one question before every feature or whatever ticket or agent prompt before you send anything. You're going to ask the question, what type of feature is this? Is this basic, performance, or a delighter? And your follow up there is, are my basics solid enough to be building this? And if no, then the list kind of answers itself. You want to organize things so that you're working on the most important things first. Make sure that everything is above that satisfied line, and then you can go above and beyond. That kind of goes into your homework here. So let's get into your homework. I want you to open your backlog and pick five items that you'd actually build, and then label each with basic, performance, or delighter. And if any basic is broken or missing, that's not going to show up in your backlog, so you've got to think about that and add that to the backlog or talk to whoever needs to be talked to to get that added to the backlog. And that is your next sprint. So bring everything up to satisfactory. And honestly, it's your next however many sprints you need to get above that satisfactory line. Don't work on the exciting stuff. I know they're exciting to work on, but focus on getting everything up there. And then I want you also to look at your existing feature set. And I want you to want to ask yourself, has this thing I used to think was a delighter become a basic now? Is something you should actually be doing all the time. So I want to invite you to jump on the Become an Epic Product Engineer podcast. Each or many of the things that we talked about in this episode came from guests on that podcast, like Wayne, Dillon, Dax and Sean. And there were a whole bunch of others that I didn't mention in here, and that I think you would really enjoy. So go take a look at the Become an Epic Product Engineer podcast, and also this has been Better with Kent. I invite you to subscribe, comment and like and share and all of that good stuff. I'm just getting started with this. So I welcome your feedback and your comments. I'm gonna look at all of them and add them to my list of ideas. I want to make this so that you can get better with me as we continue to make the world a better place by building better products. So thank you so much for spending some of your time with me to get better with me. Have a good day.