 Hi, welcome to Agile Product Prototidation, the Kano edition. My name is Shannon Vitesse. I've been working in Product and Tech for the last 20 years, and today I'm going to walk you through a little bit about what I've learned in Product Prototidation, starting with why it matters, where and when it happens, different methods that I've seen, a deep dive on Kano, and then we're going to wrap it up. So let's get started. First things first, when I started watching TV as a kid, and I'm American, we watch a lot of TV. The remote controls are pretty simple. We had this old one in the basement that even only had three buttons, and the entire point of this thing was just don't make me get up. So you had something to turn it on, mute or turn up the volume, and then change the channel, and that's it. That's all we really needed. But later, different pieces of hardware came into the picture. We started getting DVD players and stereos, and the operation became complex because you had all these different remote controls, and we decided to create one remote control to rule them all, and that's where this puppy came along. She was complex and hard to manage, and she had a lot of programming to do, but she got the job done. Now then, this little beauty came along, and it was a real disrupter for the market. So Apple shifted all that complexity away from hardware and into software. We started consuming media in a different way, but those old remote controls still existed. I remember because for anybody who didn't have Apple TV, you still had to program that sucker, and every time your batteries went out, you had to reprogram your remote control and find that weird code and all this stuff. I bet the Gen Zers are going, what is this woman talking about? This is how it was back in my day. So I got pretty frustrated, as most customers were, because you want something that's easy to use, but the prioritization didn't shift in the case of these remote control makers. They kept the complexity based in the hardware, and you could tell that there was a lot of misalignment between the people who are managing the software and managing the hardware. They just weren't connected and we weren't adapting your remote controls to be able to mend that complexity in the hardware. So we lost a lot of time and energy building these remote controls for people who didn't want them, essentially. I bet a lot of those didn't even ship in the end. Once that Apple remote came along, probably a lot of those shipments were stopped, and all that time and energy building those things was lost. Evidently, when you lose the value to the customer, you start losing customer, you start losing money, and I bet a lot of those businesses went out of business. So the cost of not prioritizing is huge. It really impacts your business. You can lose loyalty, trust, and opportunity, and of course revenue, and if you lose enough of it, you will go out of business. So prioritization is maybe the most important tactic to learn in your organization. But unfortunately, it happened all over the place, and we cannot always predict everything, but we do know that it happens at different times and in different spaces. So let's go into that just a little bit. In the product development lifecycle, it happens in pretty much every single phase in a different way. Starting with the beginning is our concept aligned to our vision and strategy for the product? Are we building it in the most optimized way? Are we launching it in the places and in the go-to-market strategies that will bring us the best results? And are we measuring the right KPIs to know if this thing is actually successful? Now, it happens in different parts of the organization as well, the company mission, trios, and vision, telling us who we should be focused on. Is this bringing the most value? Is this the purpose that we should really care about all the way down to the backlog where we're deciding which epic or story should we be doing? Now, for today's purposes, we're going to focus on this middle zone of roadmap and strategy, and I decided to focus on this because I feel like as a product manager, this is where we spend most of our time. Mission, vision, and prios don't typically change that much unless you're going through a very large disruption. And delivery plan and backlog are things that actually change quite a lot because you're doing small prioritization, small decisions. So I think in this middle zone is where you have a lot of impact. And it's important to get it right or you waste a ton of time. So let's talk about different prioritization methods, which you've probably already heard of today. I think this one might be the most popular. It was by Steven Covey, and it's called the Action Priority Matrix. I think this is great for product strategy and roadmaps. It's really focused on customer ROI. So it's balancing the impact or value based on the effort. So those top two quadrants of quick wins and major projects are the ones that you would want to do because they bring value to me and they're not too difficult. This next one is by Eisenhower, who's an American president. And I think this is a good one for sprint or backlog prioritization or even like story prioritization. In any case, it's low level decision making because it balances things that are important. So again, we're focused on value. But instead of the return on investment being based on the effort, we're talking about timing. And so that's why I like this for story mapping and other activities that are more low level because you're not talking about really if you should do it because anything in the delegate or don't do it boxes are like a no go. But when you should be doing it. So that's good for the low level decisions. Finally, you probably have already heard of Rice. Rice is a pretty popular method for product prioritization. It's reach times impact times confidence divided by effort. So let's state the obvious. Sean McBride is in love with math. That's cool if you love math. But I actually feel like this takes a lot of work. I feel like it's useful for those large organizations that need to arbitrate many much decisions in a short period of time. And they need to be totally objective about it. Math is your friend. So it's good for trade-offs and backlog management in those cases. And I think it still is a little bit of guesswork in terms of like confidence is a rating 0 to 100. Like that's guesswork effort as we know always guesswork. So you're not actually being that objective. But I think if you have a lot of decisions to make and you really need to compare a lot of things this could be pretty good. But all of these assume that you have a lot of information. And that is the problem that I have with these methods. They're not talking about early stage decisions. These are late stage decisions after I've already done technical discovery after I've already done effort and estimation with my engineering teams. So we already know the complexity, the impact, the dependency, the timing and scheduling. You may have even already done a lot of customer research. And so you know the reach of these things and the target audience for these things. So we're really assuming all the data is already there. So if you don't have that data it's really hard to use any of those methods. And that's why I love Kano. Kano is a low ambiguity or high ambiguity low information tool. And I like it because it helps you find the customer value really quickly. Consider all your options and then save engineering time which is something that we don't do enough of. I think as product managers is really focused on our value and harness what we care about and why we care about it before going and asking someone, hey, how hard is this to build? I think we need more of that in our business. So what influences priority according to Kano? So this is Noriaki Kano. He was a customer success and customer satisfaction guru in the 80s. And I like him because he was focused on joy. Very customer-centric outlook. Now I am interpreting some of these notions from his Japanese interpretation. So bear with me. This is how I think about it. And I've made a little quadrant for you. So it's really concrete. There's two parts. Is it there? And do you like that or not? So very easy, no guesswork. You know exactly what it is. So let's start in the upper left hand corner. Something is not there and I'm happy about it. Oh, thank God it's not there. Now just to the right of that, you have I'm happy that this thing is here. Oh, awesome. There it is. There's that feature that I was looking for and expecting. Yay. In the bottom left, you have something that's not there and I'm not happy about it. So I'm probably expecting this thing. It's like a crap, where did that thing go? I'm expecting this feature. Where is it? Situation. And then on the right of that, you have what the heck is this? I'm seeing this thing. I don't want this thing. What are you doing to me? Right? So that's what this quadrant sort of says to me if we're interpreting it. But the way that Kano talks about it is actually on these different curves. So we're gonna go through the curves a little bit because this is how he predicts value assessment from the customer. I really love this. So first you have the required line. These are features that will disappoint if they're not there. So I'm gonna give you an example. I'm in a restaurant. I expect a plate, right? I'm not gonna eat with my bare hands. I'm not delighted about that if I see a plate and I'm not dissatisfied. I'm like right in the middle. It's there and I expect it. Now take my plate away. I'm gonna be totally unhappy about that. How am I gonna eat my food without getting it all over my beautiful clothes? So I really am unhappy if I don't have a plate. And so that's why that goes down and to the left it's absent and I'm dissatisfied. Now the next feature type he talks about is desired. So this is something that if it's there, it makes a difference to me and if it's not there, I'm unhappy about it. So let's talk about me in the restaurant again. I just ordered some fries. I expect there to be ketchup. I'm not unhappy that there's ketchup. I'm not thrilled that there's ketchup. I just kind of expect it. Now if you give me some sort of special sauce, now I'm pretty impressed. I'm like, oh yeah, nice. I get my special sauce. This is kind of cool. I'm gonna come back to this place because they're a little different. But no ketchup and I'm choking down these french fries. Really uncomfortable. No thank you. I don't want that. I want my ketchup. So that's an example of a desired feature. Next is my favorite kind of feature. These are the delightful features. Ones that I'm not expecting and so they bring me all kinds of joy. So let's say that I go into my restaurant and I want a steak but instead of just giving me a steak, the chef comes to the table and explains everything to me and he brings me an assortment of sauces or she does and I get all this cool experience and I learn all about my steak and it's different flavor profiles and how I can really get the most of this experience. Wow, I'm not expecting this but I am pleasantly surprised. But if I just go to the restaurant and get my steak, I'm still pretty happy. It's fun. I'm getting a brilliant steak. It's cool. I'm not dissatisfied nor am I totally delighted. I got exactly what I expected. Now the last major feature type is called a reversible. Now this is the one that actually makes a difference in the negative. If you have a feature that is a reversible feature you can actually turn customers away. So an example of this might be steak in a vegan restaurant. Now, if I go into a vegan restaurant and I see steak on the menu, I'm immediately in what the heck is this land? I do not expect it to be there. I do not want it to be there. I'm highly dissatisfied, right? But if I can go into Paris and actually find a vegan restaurant, I am thrilled because this is so rare. We do not often have vegan restaurants in Paris. So great. I'm super excited that I have no meat on this menu. I'm thrilled with that. Now this is a feature type, the last one that doesn't really matter that much is called being different. Why? Because it makes absolutely no difference to me at all. So if I'm in a restaurant and there's a tablecloth, I don't care if there is or isn't a tablecloth. It just makes no difference to me. I'm there for the food. I don't really care what color the tablecloth is or if it's even there. So these are the five different types. You have required, desired, delightful, reversible and indifferent. Now one caveat about this that you need to know is that these opinions are not gonna be fixed because we're human and we change our minds. So this thing called habituation will happen where someone will get used to a feature. And an example that a friend told me about that I really liked was this confetti that he had built into a product. At one point he was like trying to bring a little bit of joy and excitement into this conversion stage. And when the customer hit it, confetti would fall down from the top of the screen to the bottom of the screen. Oh yay, kind of delightful the first time it happens. But then the 50th time, you're indifferent to it. You don't care anymore. The 100th time, it's a reversible feature. Get rid of this stupid confetti, I don't care. I don't want it. But in the inverse, things can actually become something that was maybe a reversible feature at first. The more you do it, you can get used to it. So a good example of this would be back end features. They're not always the funnest things to do is entering content into these feature systems. But the first 10 times it might be annoying after a while, you get used to it. You might get indifferent about it. I don't ever think that would become positive but you might become indifferent. So I think that the curves can kind of go from bad or good into indifferent with habituation. Worth thinking about. So let's talk a little bit about how you can use this method. So basically step one is interview. Obviously, you cannot know what your customers think if you are not talking to them. Cannot stress this enough. Next, you wanna note and collect your answers and then map your features and finally craft a strategy out of it. So let's give this a real life situation because I love my restaurant stories. I'm gonna stick with it. So let's say that I am the owner of the Balgon restaurant in Paris. It's beautiful, but it's tiny. I can only seat so many customers. And I'm seeing I'm getting kind of a leaky bucket where I'm bringing in customers but I can't retain them because I can't seat them best enough they're going off to other restaurants. So I decided in order to maximize profit, I need a takeout option. I gotta figure out how to keep attracting these customers and maybe even pull in even more, still make those lunches and get them to do a takeout options that don't lose those potential customers. So I'm a good PM and I think about the different problem spaces that we might have. So customers might not wanna do a takeout box because it pollutes or they might not wanna do takeout because they feel like it's just the same old thing and they'll go somewhere else for something new or they might find it less enjoyable as an experience and perceive that as less value. Hey, I'm paying for the ambiance. Why should I pay the same price if I'm just gonna eat it in my living room? So these are the potential problems and I've come up with three solutions again because I'm a good PM and I ideate. So let's say that I want eco-friendly boxes, new menus to keep things fresh for people who do multiple takeout orders a week and I wanna do a discount for people who feel like they're losing some of the value. So I'm gonna do an interview in the positive and negative for each of these and I'm gonna rate it on a scale of like, expect, neutral, tolerate and dislike. So I'm gonna ask my customer. Now I'm gonna be the customer. Hey, Mr. Customer, what do you think if I give you eco-friendly boxes? And that's a feature that I can offer you if you take a takeout menu. I'm gonna say I probably like that option. So you see the alignment on the left is gonna go all the way in that like box. Now, if it's not there, how would you feel if I just gave you plastic boxes and you just got thrown away at the end? I'm gonna say I don't like that. So I'm in that X right that aligns with present like and absent dislike. That's where that X is gonna go. Now, I'm gonna ask you customer, how do you feel about getting a new menu? And I might say, well, I kind of expect a new menu, I guess. It's not anything super exciting. And what if I don't give you new menu? What if you just get the same old menu as usual and you come in every week and you do your takeout menu, same thing? I'll say, I guess I can tolerate it. I like your food. Your chef is pretty good. So that's why that X is in the expect line and tolerate its absent line right there. Now, the last question that they are asking me, hey customer, how do you feel if I give you a 10% discount if you do takeout? I might say actually, I kind of expected because this is not a super great experience for me. I'm losing some money. Also, it's cheaper for you if I just do takeout. So yeah, I expect you to give me a discount. And if I don't give you discount, well, I don't like it because I'm expecting it. So that's why that X goes in that box there. So you would run through these questions for as many features as you want, but I think it's better to do a smaller quantity of feature and run it through a lot of customers and then you would map those responses. So for the eco boxes example, let's say that I interviewed seven customers and five of them said that they really liked it and then it would be a desired feature. So that's how I would map this and I would eventually put these different features on the screens that I can see how I feel about those. So there's my eco box up in that present. I like it, not present, I dislike it. So that makes it a desired feature from the most of my customers that I interviewed. So you map these different things to find out where your features are in their value scape, right? And this is kind of what we came up with. Let's say that we did, I don't know, a hundred customer interviews or something like that. And we found out that the eco boxes is considered a delight. The new menu is considered kind of indifferent because people don't really care and discounts are required. They kind of expect it and it's not there, they're gonna be upset about it. So now I've figured out what these different features mean to my customer. And if I go back to my product strategy at the very beginning, I decided that I wanted to avoid the leaky bucket. I wanna keep attracting customers which means I probably need some sort of delight features and I wanna retain the customers that I've attracted. I don't want them going out the door somewhere else because I can't service them fast enough. So I need some requirements in there to make sure that they stick around and I'm not disappointing them. So to attract customers, we will surprise and delight them with some cool eco boxes to reduce pollution and to retain customers. We will meet their requirements by giving them a 10% discount. We decided not to do the special menu because why go through all that effort if we're not gonna get any value for it? So that's how I determined a strategy. I came up with a problem space. I made a decision about what kind of product strategy I needed to respond to that. Then I mapped my features based on customer interviews about where they bring value and how and I devised a final delivery strategy around it. Now let's do a wrap up digging into some of those use cases just a little bit more so that you can find out how best to apply this process. First of all, when you are trying to attract customers in the acquisition phase, delight features are gonna be your best friend. Anything that can pull them away from a competitor is great. So when you're dealing with poor experiences on the back end I mentioned before, having an amazing back end experience might be the thing that pulls your customers away from their competitor. Or if you are having an experience that is totally unexpected and new like that remote control that we saw at the beginning of this story where Apple completely disrupted that thing and said, okay, instead of having 20 buttons on this thing, we're gonna have two, push and browse, easy. So Apple really thought the simplicity was the thing that was gonna delight their customers and so that's what they delivered and it really worked. So delight things are great for that early stage conversion funnel acquisition of your customer. Next retention, I mentioned this a little bit in my strategy but retention is all about meeting expectations. So those required ones and that's why I interpreted that type of feature as required because my customer wants it and if they don't have it, they're gonna leave. So retention is the game. Now you might also wanna think about identifying those reverse features because those are the ones that you're going to want to remove. If you keep a reverse feature you're gonna drive customers away and that's against your strategy of retaining them. In the growth and activation phases. So I've attracted my customer, I've gotten them to do enough in that early stage that they're gonna continue on with the process. Here again, if you're seeing people drop out of your funnel right after the activation phase, maybe you need a delight to keep them there. Maybe you need something to make that experience a little more enjoyable for them so they'll stick around and complete your conversion funnel or even expand it. So let's do a little bit of wrap up about what we've learned today. First of all, this is a tool for high level prioritization. This is a great opportunity for you and your team to craft strategy rooted in customer data, prioritizing their value and their experiences before you have to talk to any engineers. Why does this matter? I think everybody can agree that engineering time is kind of the commodity that you don't wanna waste and one of the biggest wastes that I could possibly imagine comes from poor prioritization in asking them to prioritize everything, size everything, imagine the effort to do everything only for you to take 80% of those things and not do them. What a waste of engineering time or you prioritize things poorly and then you waste time and energy building it only for never to ship or not to reach the customer potential that you thought it would have. So this is why high level prioritization is critical to get right. You will absolutely save engineering time. Now the next one is something I think that a lot of companies who are not product led really struggle with and this tool gets you right on track for that instead of making assumptions about what your customer wants because I don't know, you don't have the time, energy resources or people to do direct customer research. You rely on your product managers to do that research in those cases and this is a tool that they can use. It's easy. You just ask them two questions for each feature. So prioritizing the value based on a customer centric vision is a great way to shift your team easily into product led growth. The last, sorry, the right side that I really like about this is that it actually follows data. I don't like decisions and strategies being made based on hunches. I'm not a big fan of bets. You can do it and sometimes you have to do it and in that case, A-B testing is great. But then again, in order to perceive the value of what you've done, you've had to go through the entire process of estimating, ideating, building, launching, and measuring before you even know if it worked. So that data can come to you very late in the phase but I actually think it's a lot smarter to do it earlier and to try and find out what your customer thinks about the value in a very quick and easy research method before you have to go through all that work. Another reason I like this is because it focuses on strategy. So I like that there are different ways that you can adapt your interpretation of your customer value and apply it to different situations. Just because your customer thinks something is valuable does not mean that you're gonna do that feature if it doesn't meet your strategic needs. So I like that this focuses on using it in acquisition or to prevent customer attrition or to maintain retention or other problem spaces and you can really think about what are we trying to do right now based on our customer behavior and which features are gonna get us to that response. And last but not least, this is not an end-all be-all. I said it was early stage and I meant it. At some point you're gonna have to do feasibility checks. You cannot make decisions about what valuable is until you know what the return on investment is. So a lot of people, I mean, no estimates, people won't do estimates. They'll just begin AB testing in some form. Maybe that's a clickable prototype. Maybe they'll build something very low-tech and easy to the user test to make those assumptions or maybe they'll just go build it and maybe test it. But none of the case, they won't do feasibility. But most organizations today do estimates and just some sort of feasibility check because we wanna understand like what we're getting into. So after you do this method is the right time to say, we know what's important to us and we know what we should do based on our strategy. So now let's talk about can we do it? And that's where that COVI method comes in really well. So I feel like this is a great combination method starting first with what is valuable to us, what is important to us and why, and then moving into what can we do with the capacity, resources, dependencies and limitations and constraints that we have in front of us. So don't forget to do the feasibility, I think is maybe the most important takeaway after all this, even though you might love this method, don't forget, you still have to talk to your engineering team after you talk to your customer. So I hope that you've gotten some good information on this today. We've gone over a lot of different methodologies, a lot of ways of interpreting this and a lot of ways of using it strategically in your product process. Thanks for watching everybody. You can find me on LinkedIn if you have questions or if you want to ask more about this or get some ideas about how to try it. I've done a lot of workshops on this and I have found that having interview cards and the five lines and then you can put stickies on is a great way to do this in a team workshop and I hope you try it out. And I hope you do this before you talk to your engineers and then use it as a value driver.