Hot Topics in the Summer Heat: Greg Coticchia's Take on Product Prioritization

Welcome to Product Coffee. I'm Jason Brett, and we do this every single week. We bring, we bring some really smart product people together to talk about the things that you need, that you're thinking about to help you amp up your game, raise your game as a product person in your own organization. And today we are really honored to have the CEO of Sophion, Greg Coticchia, who's going to talk about a prioritization method that he's been using in his career and that he's taught to a lot of people. He was the founding executive director of the Carnegie Mellon School of Product Management for their product management master's degree, which is the first of its kind program. And now you're over at the University of Pittsburgh, is that right, Greg?

That is correct. Yeah.

So we're going to talk about 4UP product prioritization, and I'm going to let you take it away now, Greg. Thanks for being here.

Yeah, I appreciate it. And if I could get the screen up here. Hey, one of the things I want to mention is that it's— I'm excited to hear that you're doing something with, with John Mansour. He is a class act and that is a great organization and just a, just a really terrific, terrific place that I— at Sophia on here, we've used 280, and they have been just terrific. John's been terrific, and it's a great organization. So I'd really, really encourage people to tune in next week, whatever you're up to. Yeah, should be fun. Should be fun. So I'm going to welcome everybody. Jason, thanks for the time. Thanks, everybody, for being here. I'm going to go through some ideas on product management and prioritization. We'll talk a little bit about why prioritization is so much fun and why it's difficult, why we need it. I'm going to throw out some of the ones that you've probably heard about for 1,000 years in terms of different methodologies. But most importantly, I, I do want to hear from, from you in terms of, you know, what you're using, what's working for you, and, and how, how my methodology that I've used for a number of years has worked for me. And maybe you can take it, adapt it, and make it successful. As I promised, I'm going to do a little bit of shameless self-promotion about Sophion. And Jason, thanks. I do have a background in product management. I'm the OG PM. I've been in product management since dinosaurs roamed the earth. And, and I worked on mainframe products in the 1980s. As one VP of product development said to me over the last few years, what we called a product back in the '80s would barely make that definition of a product today. But we called them products back then. I've had an entire career in entrepreneurial startups, early-stage businesses, launching products and companies. I've been involved in literally hundreds of products in their development and continuation and transition from way back to those mainframe days all the way through today's SaaS product offerings. And as Jason mentioned, you can get a degree in product management. You don't have to, though. That's one of the things I like to always say. But it was an honor to be the founding, uh, the founding executive director at a prestigious university such as Carnegie Mellon University in their master's program for product management, creating the world's first degree in product management. So, um, I left there to join Sophion because the mission that Sophion is on, uh, is all about meeting this relentless demand for innovation. And that includes what product managers do each and every day, as we all know, and in new product development. It's estimated that, you know, while we know all the stats of failures and new products, and they range from, you know, 40% to 90% and everything, at the end of the day, it is true that only 6% of executives, 6%, are happy with their innovation efforts. And there's about $3— listen to this, this is a killer— there's about $3 trillion spent on R&D a year across industries. $3 trillion. Half of it is considered wasted, and 6% of executives are happy with the results. So there's a problem with product development and what we're going to be talking about today, which is, hey, what features go into the product? When and why are we doing that? And, you know, what are, what are the results that we're trying to get? You know, our products at Sophion try to address these issues. I look at it like cybersecurity. There's always risk involved in anything new, and you're not going to get 100%, but you can get other types of results that increase your time to market or more, more wins on the board with new products or savings and efficiency in process. I know John's next week's going to talk about portfolio and there's some folks on here that have a background in portfolio and, you know, increasing your portfolio value is really important as well. So all good things. I don't know if there's already a— oh, just here in time. Okay. Anyway, so that's a little bit— if you're— if you are interested in Sofian, we have a number of customers across a number of industries. We're not just in the, in the tech business. We, we serve a traditional consumer packaged goods, the chemical businesses, to telecommunications, to healthcare and beyond, and help automate their process. And we have a suite of 4 different products that help in everything from product discovery and idea management to actual workspaces for your product and product healthcare, to managing your portfolio and governance, to managing projects as they come along. So that's a little bit of the advertisement. Let's get into what the subject is for today. And we labeled this 4 UP, Prioritize This, Product Manager. And we'll see where we go here today. I look forward to the conversation. So let's talk about prioritization as it is. And like, you know, why do we even need it? Do we have some— I know we have quite a few people online here. So how many of you spend your day in looking in Jira and/or on some other form of lists and grooming the backlog and trying to make decisions about, you know, where and what you're going to be, what you're going to be putting on the roadmap and how that fits. We talked a little bit about some of these challenges and trade-offs. People spend their days like that. Does that sound familiar? Nobody in chat. Is everyone there? Well, I, I can tell you, uh, I've, I've been, uh— oh, we have, we have a few, we have a few people doing that here, uh, building a healthy backlog at the moment. Okay, well, thank you. Yes, 100%. Well, I can tell you, unfortunately, since the Agile Manifesto in 2001, we're 17 leaders in product software product development went off to a ski lodge and no one went skiing and defined the term product owner and the advent of going from, particularly for those of us in software, from Bugzilla to the advent of Atlassian's Jira. This has become a lifestyle for many product managers where they sit in, they sit in Jira and they look all day and they think, wow, okay, how do we move these things along in our backlog? I'm old enough to remember, you know, keeping these things and calling them wishlists lists and putting them on pencil and paper. We also used to even have customers give us input for our wish lists. They'd literally fax it for people. Anybody on the line here is old enough to remember what a fax machine is. They would fax in their product enhancement request forms, or we called them PERFs, and that was their input to the product so that we could help define the roadmap. Right? And the worst part of those days too, and it still happens today, which is they kind of go into this black hole. People don't know, like, well, how's— what's the criteria or what's the status? Or, you know, are you working on that? Did that make it on the roadmap? Or, you know, what I do in the meantime? And, you know, particularly as we talked about earlier in this conversation, in a sales-led organization, these things, you know, kind of have ebbs and flows in terms of their priority. And the worst part in those sales-led organizations, sometimes they make them into contracts. And all of a sudden that you as the product manager wake up one morning realizing that you have some kind of contractual commitment for a feature that you need to develop. That can be a bit of a problem for folks too. But I even worked in one company where we had the VP of sales meet with product management every Monday morning, and he would then tell us what we needed to build that week in the product. So that's probably the extreme case of sales-led. But needless to say, they're all there. So, you know, prioritization though, you know, you have some span of control over prioritization outside of these whale deals that come in where they're, you know, make the quarter, you know, break the bank, need this for an important customer. The highest important person, the hippo comes in and says, we need to have this feature. You have a lot of, you have a lot of control over that. But what's interesting, a little fun fact here from our friends at Product— I think this is from Mind the Product or Product Plan, Product Board, one of them is that most product managers don't know how to prioritize features. So there's a lot of methodologies. We'll talk about some of those today. But what's scary is, you know, the top 2 methodologies in a recent product management survey were none and other. So we have some work to do about getting even a framework or methodology. None and other are probably You know, it's like saying that your, your competition is apathy. You know, you should really choose and pick one, get familiar with one and start somewhere. It's probably a good way to go. Right. And by the way, besides none and other, number 5 on the list was don't know. So, you know, none, other, and don't know, not good answers. It's like asking a sales rep, what's the next step in a sales process? And they say, I don't know. Bad answer, make something up. So that's one of the things that I will emphasize here today. So let's dive in just a little bit more and talk about the definition of prioritization. And why is it so damn important? I think inherently we know it's important. And in some ways, it's interesting, by the way, that John Montsour session next week should be great because he published an article about Portfolio Management and Product Management. I would encourage anybody on this call to go read that. It's absolutely spot on. It's so well written. And so it should be a great session next week, Jason, with you. But, you know, in some ways you're managing a portfolio of features as opposed to a portfolio of products, right? So you're making similar decisions and you've got to have a way of making those trade-offs because you don't want to make poor decisions. Some ways you've got to have a rationalization as well. What is the reason why? Right? Because there will always be people questioning what your judgment is, what your domain expertise, your experience, whatever. And you do want to have a thought process not only for yourself, but you want to have one that you can explain to others about what the rationale is, right? But at the core of all these, and by the way, if you type in product prioritization or feature prioritization or product management prioritization, whatever it is, and into the intergalactic Google machine or your favorite ChatGPT and come up with all the 10 or 25 or 500 different methodologies. At the end of the day, the end of the day, the problem is there are limited resources, right? There's always, I don't care if you work for a $100 billion company or a startup in a garage. There are always limited resources. I always chuckle when a company gets acquired and they say, oh, this is going to be great, we're going to have more resources to get done what we really want to get done, because that never really happens, right? You never have enough resources. I don't care where you are. And resources is people, time, and money, right? I mean, at the end of the day, there— yeah, you can add a few other things to that. So as a result, you are always, always, always making these trade-offs about what you want to get. So you have to choose. And we giggled a little bit earlier in this call about product managers saying no. Why is that an important thing for product managers to have that ability to say no? Because you got to focus, right? Everything to everyone is nothing to no one. Everything to everyone is nothing to no one. And so you got to get hyper-focused. You got to know who your customers are. You got to know your personas. And as a result of that, through that lens, you've got to have your feature selection done correctly, right? It ensures a focus on your high-impact tasks. It maximizes the use of those limited resources. It addresses the issues of changing market dynamics. And one of the most important ones is conflicting stakeholders. We all know that, you know, what executive management thinks versus what the sales organization thinks versus what the development organization thinks. They're not always in alignment. And as Dan Olson says, you know, in a riff on Spider-Man about product management, with much responsibility comes no authority. So you have to influence, you have to influence a lot of other stakeholders to get buy-in to drive your roadmap. I want to talk a little bit, but I hope people can remember these pictures, by the way. This is one of my fun things I pulled up for that, just for this, just for this slide deck. And I hope that folks get a kick out of this and it's not too out of date, but I hope that a few of you remember the original iPod. That would be the one on the right of the screen. Anyways, it's a, you know, feature trade-offs make or break products and the decisions relative to your strategy are really, really important. You know, looking back on these two products, both of them original MP3 players, we kind of— you probably weren't even aware of the one on the left, the RCA Lyra, which was, you know, actually quite popular at the time. So RCA Lyra, and then you have the Apple iPod here on the, on the right-hand side. And I wanted to, to talk about what's interesting always, particularly about Apple products. And I know people, you know, in the cult of Steve Jobs and Apple products, they, they could, but, but there are a lot of instructive things that we can learn. What I love about this initial product, and it was this way for quite some time, is it didn't have a lot of features, right? It really didn't. But what it did have it did really, really, really, really well, right? So I mean, it didn't have the RCA, by the way, on the left. You could use SD cards, you could use portable media for that. Pretty cool, right? So that's pretty exciting. And that means that when I run out of space, I can swap in another SD card. I can move that SD card from my RCA player to my laptop, to my, at the time, a desktop or whatever else. You know, the idea of the cloud wasn't, uh, wasn't around at the time, but you had, you had portable media and you never ran out, right? So you had this kind of concept of unlimited media. That was pretty cool functionality, uh, for its time. Uh, you know, nice, nice looking device. I'm not sure why we needed a particular dedicated button for a light, but you know, hey, whatever. And, uh, you know, it had for better fidelity in terms of the, uh of the sound with the DSP chip capability on the left-hand side. So you could get higher than ever fidelity for those MP3s, which are still pretty crappy today. Uh, aside from that, it had all the basic functions. Maybe not as elegant a looking device, but pretty cool, pretty cool. Um, and, uh, but you know, as these things evolved, you know, they put radios on them and XM radio and GPS, you know, and eventually we know that they became full-function phones. But the feature selection on the right basically said, I want to get the phone, I want to get the music experience right. I want to get the iTunes library and I want to get the dedication to, you know, I think the original value prop was, you know, 1,000 songs in your pocket. I think that was kind of the tagline positioning. Someone could correct me if I'm wrong on that, but I think that's what it was. And, you know, that it stayed true to that. And there are plenty of stories of those days where, where the product teams basically said, no, we're not, we're not going to do that. We're, we're, we're, you know, we're going to, we're going to say no to that feature. And, you know, it's easy looking back in the rearview mirror to say, of course, you know, this, this, this, this product ended up being successful. But, but it just goes to show you The subtleties, the subtleties in terms of making the right product decisions, right? It met the value proposition and the problem set that they were trying to solve strategically, stayed true, said no, won the marketplace. Not easy. We all know that because all the other stakeholders are going to continually tell you, look like the RCA machine. Don't look like the, like the iPod machine. And that's one of the really hard jobs, product management. So let's talk about these stakeholders here for a minute. Lots and lots of stakeholders. You know, first and foremost are customers. You know, our job is to solve markets, not individual customers, because there's money in terms of scalability, profitability, all those things when you have scale. As an old boss of mine used to say, there's only one thing worse than no customers. That's one customer. And when you have only one customer, particularly for a feature, you learn just how costly that is. So that is a terrible mistake that we are faced with each and every day because, you know, we, we, we, we like to ring the cash register and, you know, customers do wave money underneath our nose to get particular features that they want on their timeline. So, and customers tend to think, as we all do, that they're more special flowers than, than they really are. You know, I, I remember when I was with a SaaS company called eBillingHub that we solved the electronic billing problems for law firms. And we want the one customer wanted a reference in Kansas City because that's where their law firm was. And I guaranteed her that the product worked the same in New York City as it did in Kansas City. But, you know, we tend to think we're, we're different because of even geographic differences. And, you know, yeah, customers, you know, there are a mix of what they're struggling with and whatever, but sometimes there's a lot more commonality if we look for it, particularly that's part of our job as product managers, finding the commonality and some of those lowest common denominators that still are delighters, right? Particularly for organizations that are sales-led, the demands are endless, particularly in early stages of a company or early stages of a product. You know, that next big deal, the pressure to close, the feature requests, the functionality that will help facilitate their success. I like to talk about that in terms of coffee mugs, though. I don't know if we can, can we, can we see the, my lovely coffee mug? You know, if we're in the coffee mug business and we make ones that are out of metal and they have a handle and a lid and the customer says, I love your coffee mugs, but I'd really like them made of glass, maybe twice as tall without a handle. That may not be the business you're in. So it's really disappointing to tell sales that. Even end-of-lifing products. I remember one time end-of-lifing a product with a salesperson at a very large customer. And we basically said we weren't going to sell that product to the customer because we had decided to end-of-life it, and we had a $2 million deal on the line. So these are the challenges that you'll have. Engineering has their own view. Many times in engineering, they are sometimes not just developers of the technology, but also experts or domain experts, particularly if it's been a small company that, you know, that you— that launched the product. Many of those folks are familiar with the actual problem set themselves and have very strong opinions about what should be built and why. And then there's also just the technology things that we need to take into account. In today's world, we also have the feedback not only from customer service, but customer success and account management. And these teams consistently will give us feedback about NPS numbers, and we're also getting our numbers about retention, which is so important in today's world where switching costs are, are lower than ever before, and customers can go from one product to another. So we need to make sure that the feature set we choose not only can win business but can retain business, right? And that trade-off is different because what makes you stay with a product and continue to get value from a product may be very, very, very different than what makes you initially buy a product. Matter of fact, we all know that there are features that go into our products that sell a product that people never use, right? There may be a competitive reason why you put something in the product. I remember a customer service coming, uh, coming to me as a young product manager saying, why do we have feature X in this product? Uh, no one ever— never— no one ever talks about it. And they didn't— they didn't use it. But if you had talked to a salesperson, they'd tell you it was the number one reason why they won business. So, you know, these are— that's another trade-off that you have in terms of prioritization. Where are you in the lifecycle? What are you trying to achieve? You're trying to maintain business, you're trying to win more business. What is that slippery slope? And then finally, we have our friends in leadership. And I kind of feel like I wear this hat some days as a CEO. But leadership needs to understand where you're going as well. They always want to dabble in the strategy, particularly if, you know, there's only two problems in business: not enough sales and everything else. And if there's not enough sales, they'll definitely go to the prioritization list and what we're building on the roadmap and what's going on. So you tend to get questioned about what you're building if there's not enough sales. So it comes comes back to roost, or, you know, if they came back from a, you know, the leadership on this list, when leadership goes out to a customer and the customer tells them what they want, that can be, that can be the poison to your roadmap at times. So this is what you're juggling. This is your lives. I know you know this, but this is the tough part. Someone mentioned this in our little dialogue, you know, because you have all these, you know, the other thing is priorities change frequently. We all don't want to build this monstrosity on the right, you know, where we are just cramming features in, baby. Let's put all feature-o-rama, you know, let's put more and more features into this thing. If we only had 50,000 features, that would be the value proposition we really— problem set we're solving. You know, have a point of view and be passionate about it. Be responsible, be respectful. You're going to have to do some things that are unnatural acts from time to time. But, you know, your job is not to build this, this thing, because eventually you're going to run out of steam and you're going to have a failure anyways, right? And this is where you're— this is where you're going to end up. Um, let's talk about prioritization frameworks. Um, there are, as I mentioned earlier, there are a ton of prioritization types of, types of things. And many of you will be using all different types. There are, you know, and I would encourage you to get familiar with some of the most prominent ones. I don't know about user is drunk, but you know, I have to learn about that one myself. Maybe that could be, that could be good. You know, the ones that I have run across most often besides kind of, I would call it bespoke, is rice. And I welcome folks to put whatever they've used in there. I see some things in that. Yes, user is drunk. That's what I want to know about. User is drunk too, you know, particularly at 8:30 in the morning. It's— is it— is is Rice, is value versus effort. Value versus effort is probably still the most predominant one that I've seen used across various industries. We also have Moscow, and we'll talk about that, and Kano, right? And you'll see that there are all different types of of prioritization techniques that are out there. And let's dive into each one of them very briefly, and then I'll talk about why I came up with my own, because I wanted to. I just wanted to add to the noise. The Kano model, really, this comes out of, I believe, work in Japan that was done years ago. The lorem ipsum is definitely not— is definitely a screen capture error. But what you're looking at is what are the functionalities that are satisfiers? What are delighters? What are basic must-haves? And then what are things that maybe you don't need anymore? You're going to go into reverse. And you can map these all out and kind of get a view of them. And I think Kano really helps you organize your thoughts just for yourself, even not necessarily even to explain it to us to say, well, what are we trying to achieve in light of the strategy for the product? What are we trying to get to? Right. And Kano does a very good job of this, and it makes a nice visual map if you do it right to get yourself situated. The value, complexity, effort. Really, this is again, I would say this is probably the number one trade-off that you see. Unfortunately, people will always go to the quick wins versus the thankless tasks unless they have a gun to their head. So, you know, it's one of those things that you really have to look and say, well, as we look through our backlog and we look through our prioritization, you know, how often are we doing? And by the way, these are not just points in time. You've got to look at your decisions over a period of time. That's very important and say, are we constantly going after the quick wins? Why are we doing that? At what point do we stop and say, you know what, this is time for a major project and we've got to dedicate the resources there and stay true to that. And then when we're disrupted in that prioritization, we've got to continue to say no because we've made that commitment. So there's not only the, the continued, because we're living in a world of, of sprints and quick decisions and fast releases and The speed is— so we're making these prioritization decisions all the time. But you need to spend the time to look back and say, what kind of decisions do we default to? The other part of this is in any of these methods, and I know we've kind of stopped here at value, effort, and Kano, but I would say that any of them is you've got to look at where you are in your product lifecycle. If you don't look through that lens, it's going to be problematic. MOSCOW is very similar to my 4 UP, but this is kind of a nice methodology. What do you have to have? What's table stakes that you're committed to for whatever reason? You can rationalize why, but then there's the kind of should have, there's the could have, and there's the won't have. And so, again, similar to value effort, you've got to look at these trade-offs and start making a decision about what you want to look at. Putting things in these buckets and looking at the decisions you make over time, really important. The RICE scoring is also a nice way. It's a little bit more mathematical. You're looking at your reach, impact, and confidence over effort. You come up with a RICE score. It's a nice way. Again, people rationalize their RICE score and talk about it a lot and say, okay, that's great. And, you know, RICE will give you, again, a more mechanical, more quantitative view of the world in terms of your feature set. By the way, these are not mutually exclusive methodologies for prioritization. You know, a lot of people will use two of them. As we saw, some use none or don't know, but some people are using multiple ones as well. Let me talk about mine. And I'd love to tell you that this was my brainchild, but I have to tell you that this was totally inspired by my wife who spent years in product management. And so, you know, going along with the great artist Steele, this is the great artist Steele. And so this 4UP methodology I just fell in love with because it, while it reminds you of some things like like Moscow, for me, it keeps things even, even easier. And that is the following. I call it 4UP. For those of you who love 7UP, I didn't make it to 7. I only made it to 4. But it is clean up, catch up, keep up, and leg up. And if you look at any release of any product, you've got to look at, you know, start off with what's in cleanup, what's in your technical debt, what does engineering and development need to re-architect, refactor, whatever it is. Everyone has cleanup. We've got to, you know, this is the cost of additional rework to make sure, you know, and it's just like monetary debt. If you don't clean it up, it's going to accumulate interest and make it harder to proceed with the product. So this is cleanup. And my feeling is every release should have some dedication to cleanup because if you don't, it will be an interest rate that you cannot afford to pay. So there may be varying degrees, but you've got to, you got to pay the piper. We all work with products that are new. We work with products that are medium age, some of that are older. And everybody knows that the technology changes rapidly. Developers want to work on fun programming languages, or you want to work with newer technology, and you've got to start addressing that. You can't just let it go because it will accumulate. Catch-up, you know, catch-up is about market-based understanding of what you need to do, not exclusively coming from the competition, but this is, you know, external pressures that can come from— it can come from many places. And when competition's ahead of you, you know, you've got to make sure that you have enough to fill in those, particularly for those who are sales-led, the RFPs, the checklist, and also have the— be able to— they're using— the competition is using them as differentiators. And so you've got to actually have them. You don't have to have the full— by the way, again, I think we get wrapped up in, well, this feature has this depth to it. Well, sometimes you can do the thin and checkmark and just say it's good enough, particularly for features that are newer to the marketplace, so that you can buy yourself time in terms of your resources and your releases. Um, no, keep up is one of my favorites because, you know, you have— if you have the same features or most of the same features, you're on par, but you can't lose momentum, right? You have to continue to develop functionality, and if you stop, uh, you create more cleanup, right? So you have to keep up, you have to stay on par, uh, and, and that's, that's a big part of it. The, the last one is the leg up. And leg up, by the way, if you get leg up right, it buys you time for all the other 3— clean up, catch up, and keep up. You can get a lot of credit. I've had a lot of products that had 40% of the functionality of competition and maybe not the most beautiful user interface, but it had 1 or 2 key features that were so compelling. But I'll put it in the differentiated value proposition of leg up. That customers felt that they had to have it. It wins deals, it drives business, it gets customer feedback, etc. So, you know, leg up is get you out in front, right? And so I like to put all of my products into this format. It helps me organize what I'm doing, why I'm doing it. If I'm saying no to something, why I'm saying no. Again, this is far from a perfect methodology, just like Kano or Moscow or value effort. Or RICE or any of the other 5,000 methodologies out there. Right. And happy to take questions. So, you know, some of the guidelines on which framework to use, I would just leave with you is, you know, what's the, what's the best way? What's the right way for you? How do you decide? Go back and look, you know, go back and look at your old decisions and put them through some of these frameworks and see if you would have made the same decisions. And if you didn't, that doesn't mean that they were wrong or bad or you were, but it's going to give you a lens of learning to say, well, you know, how am I making decisions? What am I valuing? We all have our preferences in life, and you have preferences as a professional product person. So you're going to make decisions based on your judgment. It, you know, just running your past decisions about your roadmap through these methodologies about your product feature portfolios is going to really help you understand your decision-making process. So I tell you that, and I would say that's a continuing basis. And I would also say Use more than one. Use more than one and see which one works for you. And also see which one works in your organization to explain your decisions. You know, we all have to explain what's the rationale or logic about why we're choosing certain capabilities in the roadmap. And having a methodology that is understood in your organization, while any one of them, again, can be criticized, And there's no foolproof logic. It does give a rationale or logic or explanation. And if people can understand why you're making those decisions, or at least the basis of those, it really helps you move things forward and not get into the emotional back and forth of why this, why now, etc. Different methodologies can be used at different times. Again, I added a few more here. Some are better for simplicity, some are better for mature products, some are better for early stage products, some are better for more data-driven products. Again, you know, even with the one that I prefer, 4UP, there's not a one-size-fits-all. There are going to be better outcomes based on different techniques through that lens of the product lifecycle and what you're trying to achieve. Am I looking for more retention? Am I looking for more net new? What am I trying to get to, right? And so bring it all together. You know, at the end of the day, the job of prioritization is manage the feedback, define the framework. Again, I would have at least two. Execute on that prioritization and stay true to that. Be able to say no. Build that roadmap and don't just become a Jira, you know, backlog groomer person. Anyone can turn that crank. That's not that hard. And finally, don't be like Dilbert. You know, we don't want a product that is a hodgepodge of complexity. We really want something that has differentiated value proposition that meets the needs of specific personas at specific customers at various segments. And this is key to us getting traction and success in the marketplace. And with that, I'm going to wrap things up, and I thank everybody for their time and attention today.

All right. Thank you, Greg. Really, that's fantastic. And I'm also reminded, I love that Dilbert cartoon that I'm thinking about, The Simpsons episode with Danny DeVito and where he designs the car, the Homer. That's a great addition. And the simplicity is really powerful in the 4UP prioritization approach. I like how you present that.

That.

So thank you very much for sharing that with us. Questions, comments? We've got a couple minutes here left. There's a lot of chat out here. You want to bring that— could you bring that comparison chart back up?

Sure thing. I think people— I like that myself. I found that by a gentleman by the name of Martin Andreev. Hold on, let me, uh, let me share that screen again here. There we go. Can folks see that? Let me just put that in full screen. Yep. And you know, I think this brings the point, uh, that's so important, you know, is that if you're If you're applying a method for prioritization that is about customer acquisition and early-stage product as it's trying to get names versus you're trying to maintain the satisfaction, you know, I, in the class I teach, I talk about, you know, that your experience in buying a washer and a dryer. And, you know, if you, if you had that experience recently, it, it brings home the point of You know, what you use your washer and dryer for. If most people, they, they, you know, they, they go, they throw their clothes and they hit a button, they walk away. But when you go for the shopping experience, I mean, it's got Bluetooth and two tubs and it's got fins on it and, you know, and a television and you got all these features that are very appealing and that, you know, that may be the competitive marketplace. But the reality is when you get that washer and dryer home is that you may still just push, you know, wash or dry or whatever. And so, you know, retaining a customer and the feature set and winning a customer can be two different things. And you've got to look at that prioritization technique. You've got to think through that process. All right.

I have managed to pin my— I'm trying to get to the chat. Were there any questions out there that didn't get answered? I'm trying to get back to the chat. There it is.

Let's see here. I can— I'm sorry for doing this while we're up here.

Uh, yes. Um, so, and then also, um, Yasmin, the, uh, Google Doc is at productcopy.com/notes.

Thank you, Allison, for the user's drunk, uh, definition. I appreciate that very much. Thank you.

Yeah, I had not heard of that one before today. That was, uh, that— I, I like the thought behind it. Um, yeah, and then Andrew said PDM is drunk. Um, it looks like we've got all the, uh, looks like we've got all the questions answered. Were there any questions out there that did not come up through the, uh, uh, that did not come up in the chat? Anybody wants to jump in or have any comments or other approaches that you use that you find really powerful or, you know, questions about this approach.

Let's see here.

Don't see any hands up.

All right.

So that, that has us looking pretty good. Well, thank you so much for being here, Greg. Really, really appreciate you as always, and all of your your support here of this community and bringing your thoughts to us and sharing this. And we will have the resources from this session out in the premium members archive later today. And then we'll have the recording out on the web in about 90 days. Oh, so Eric's asking, what is the WSJF? Framework. That is Weighted Shortest Job First. And that comes out of some of the SAFE. It's one of the tools they use heavily in the SAFE methodology, Eric. Basically, it takes a group approach to adding scores to several different factors in prioritization, and you end up with a number number that you can use to ordinarily to provide guidance as to where you can get the best return on investment across a few different criteria in your prioritization. We use that pretty heavily at Silverpop for quite a while, and it's really great because it brings engineering and the business and product and marketing and even support to the table to have a value discussion along with an effort discussion in a really open forum. That creates a lot of, that creates a really good alignment across the team. But it's expensive because you literally have to get everybody, you know, as many people as possible into the meeting and you have a lot of discussion about why people vote the way they vote. So it's valuable but expensive. Andrew says using these methods in concert is important. For example, 4UP plus RICE. 4UP to ensure you're investing in each area and RICE to prioritize within each area. Yeah, that's great, great insight, Andrew.

Good insight. All right.

Well, we have got— registration is live for next week's session. If you're on our mailing list, you'll get an email later today. If you're a premium member, the link is already in Slack. You can jump in there and follow through, or for those who are on the call, you can go over to productcoffee.com/tickets and sign up for next week's session. And that should redirect you over to our LinkedIn page where you'll see all our— to our Eventbrite page where you can see all of our open sessions now.

All right.

Thank you again for being here, Greg. Thank you for everybody who's sitting here and watching from Sofiane as as well. It's so great, so great to have you all here. And we will see you all next week. Have a great week, everybody.