How To Use Product Discovery To Accelerate Growth with Jim Morris, Product Discovery Group

This episode is brought to you by VanHack. Want the secret hack to staying competitive and building great products? Extend your company's hiring budget with VanHack's pool of 400,000 remote engineers at a lower cost than local hires. Join companies like Dapper Labs 1Password Brex and Dooley, who've hired great engineers with VanHack. Mention Traction Remote when you sign up today and get 10% off your first hire@vanhack.com. that's V A N H A C-K.com.

Let'S say you've got this interesting prototype. You show it to users and they say, oh, I like this, that's interesting. I'd use this. I have to say, after years of hearing this from hundreds of users, that they're basically lying. They're not lying on purpose. They just want us to be nice to you. So I call this the meh Feedback. When you hear that's interesting or I like this, don't walk away with validation. What is validation? When someone says, ooh, oh wow, is this available? That emotional reaction when the user just exclaims something, that's what you're looking for.

I need some traction. You need some traction. Let's get some traction.

Hey, what's up innovators, entrepreneurs, visionaries and disruptors. This is your Traction podcast host, Lloyd Lobo. We're a community of over a hundred thousand people just like yourself on a mission to help you get the methods, the money and and the madness to explode your business growth. Featuring stories and tactical advice straight from those who've done it before, like Shopify, Twilio, Asana and many more.

There's no point creating something that nobody wants. And yet many founders skip this very important process of product discovery, right? Even the most agile, efficient processes can't make a bad idea good or successful. And doing product discovery is a key indicator of validation. Most companies fail because they can't get to product market fit. But what is the leading indicator of product market fit? It's product discovery. And so we're here to talk all about that. And today's speaker is an expert, a guru in product discovery. Jim is a coach for product management leaders and teams and early stage startup tech companies and Fortune 500 corporations. Previously, Jim was an engineer, product manager and leader at startups where he developed raw ideas into successful products several times. He co founded Power Reviews, which grew to 1200 clients and sold for 168 million, which is in today's terms, billions of dollars. He product managed and architected one of the Internet's first E commerce systems at Fog Dog, which had a 450 million IPO back in the day and overall badass product management expert. He's a graduate from Stanford with a B.S. in computer science.

I left school, went in to join a company called Fog Dog. We sold sporting goods back when Amazon only sold books. We went public. It was a lot of fun, quite a roller coaster ride. A couple years later I started a company with a couple others about product reviews and we called it Power Reviews. We were in that for seven years and had a fierce competitor and eventually who bought us and we joined them for a couple of years and then the federal government split us apart because we were a monopoly. So I'm a convicted monopolist and basically became Power Reviews again. And after 10 years I exited the business and became a product management coach. A little bit burned out and really wanted to take the lessons I'd learned and help others. So I work with consumer facing companies. Digital health companies are like about 50% of my business now. So many amazing things going on in connected devices to help you through chronic conditions or just everyday medical needs and then just tech, finance, clean energy. Everyone's using technology to get ahead. So what I want to know now that you know about me is tell me about you. Fill this out. And this is basically a four question survey to get us warmed up to each other. So everybody go here. Maybe you weren't expecting to contribute something, but I think this is a great way to see just kind of lead into the topic of not building things that are untested. Lloyd said some of the greatest frameworks in the world can't make a bad idea good. They can't necessarily tell you if a bad idea is good or bad or if any idea, as Lloyd said, like not even the best process can get a good idea, can make a bad idea good. A lot of great ideas were created without JIRA or Rally or Shortcut or pivotal or these things. And so I want to remind people that yes, tracking things and having a process is very useful for scaling engineering and product, but that we're here to validate ideas and to make sure that we test them. Okay. As we think about ways to do that, just remember that's different than agile. When you use product discovery to accelerate growth. We're going to stop wasting engineers, stop wasting their time. We're going to collaborate up front, explain what that means as opposed to coordinate know your data. So really this kind of talks about like quantitative data and it leads into our qualitative data Talking to customers and then creating experiments. And this is the part that really helps accelerate growth as you expand the universe of ideas that you're working with. Okay, so stop wasting those engineers. I'm an engineer by trade, and it's terrifying when I hear about frameworks that exclude engineers, that treat them like the Agile factory. And really, engineers have been some of the sources of ideas that create some of the most valuable companies in the world today. So you might have a roadmap that looks like this. Gates, rows with things you need to do. I had one of these and I shopped it around to my clients. And it was a pivotal time because as we talked to our clients, we realized they weren't necessarily interested in new features. They were interested in being mobile compliant. Their traffic had gone above 50% of usage on mobile devices. And so it was incredibly important for us to be mobile compatible. This is back when this is really happening at a rapid pace. People didn't even think you'd buy on mobile, but they knew they'd do research like reading product reviews. So we pivoted. I met two customers a week for 50 weeks, and after about two or three months into that, we pivoted our roadmap, almost basically threw it away and went to mobile compatibility, building on new frameworks, building APIs. And we didn't deliver a lot of new functionality, just a couple of the lighters in there. But people loved it. And, and it was much better than our fixed roadmap. And so we pivot when we test ideas, right? We're not just there to put the stamp of approval on them. Now I want you to spend time and money to learn before spending that time and money to build. So spending to learn is different, right? We know how to spend time and money to build. That's what we're talking about. Agile, scrum, those frameworks. Here I was working with an entrepreneur who spent $200,000 building this website. It had zero traffic. What had happened was he had an idea, asked somebody to build it for him, and they said yes. He paid them, they built it instead. When he got to me, we went back to ground zero of this concept and made some fake prototypes, tested with users, gradually figured out what it was, the core value that they wanted that he could offer, started marketing into different areas. And this was about getting recommendations from your neighbors about handyman plumbers and people like that. So we built this very simple site. He and his team built this site in squarespace with Google spreadsheets. Very lightweight way, not $200,000 to test this concept of driving traffic from next door Facebook groups. All the places our users told us that they went to get recommendations and we made lists and people could contribute to the lists. And this site grew in traffic, we grew in learning, pivoted to this site and eventually pivoted to a subscription service. And what I taught him was not about his product, he had to learn that, but I taught him how to learn to learn. And I think someone mentioned that in the chat. And to me, that's what I do with clients. That's what you can do, is not just consuming materials about learning how to do things, but actually the process of testing with users. Okay. That's the learning to learn. So in product discovery, it's well known we go after these risks. Okay. Value, usability, technical feasibility, business viability. So I like you now. These all sound like great ideas. In the chat, can you just type in something that blocks you from doing discovery? It could be other people, it could be lack of knowledge, could be lack of money. Go ahead and chat me a couple items that are blockers for you. Who will be first? You can do it. Yeah. Data concerns with users. Getting users to respond. Being an introvert. Absolutely. Knowing what's the best method. Confirmation bias, the cost. I know what users want. Yeah. This is if you are in an organization with folks that are the highest sort of paid person in the room. Type decision making, resources, leadership. Finding customers that will spend time answering questions, asking the right questions, the right platform. Statistically significant users. Yeah. Prefer to develop and write code. Absolutely. So to that point about developing, writing code, when we started Power reviews, the other engineer and I that were the hands on keyboard folks, we stalled the two sort of business folks on the team for three months while we planned the product and thought about what we were going to build. And that discovery period allowed us to accelerate our development because we'd thought about and tested ideas before doing it. So I do think there is a time to code and there's a time to think about coding, not just in the architecture sense, but in the products in the future sense. Didn't know I was blocked. We just decided on your own what we think our users need. Yeah, fair enough. That's great that you don't have any blockers. I do think you can augment your intelligence with user feedback. Finding the right users. These are all great. And investors. Yeah. So. So let's talk about ways that we can bring product discovery more to the forefront. One is of course collaborating. A lot of this is one way collaboration waterfall is that Typical anti pattern we see slightly better, but still an anti pattern is throwing it over the wall. This is where the business folks and the design folks get together and think about a concept. Maybe build something that's applicable and then send it over the wall. Engineers are still confused because they weren't involved and maybe you didn't have as much knowledge in that beginning process. So you design things that really can't be built. There's also the agency model of the agency is internal or external where people drop in, they don't have any context, they make something look pretty, they give you an estimate. This also leads to confusion. So what's a two way version of this? Collaborative solutioning, bringing everybody up to that front of the process. People call it shifting left. But the idea is I want you to work together, bring the engineer back into the fold. There's some of the greatest sources of ideas on the planet, historically proven by the revenue and stock market value of some of the largest companies in the world. So make sure they're involved, make sure they know how to contribute and make sure you value that contribution. Okay, I'm going to talk about how to value contributions from your team members. Now. We can't bring everybody in as you bring more people in. People stop showing up to meetings. There's too many connections of communication. So we devise a core discovery team. Most people are familiar with the triad designer, product manager, engineer. I like to add a data person, maybe a customer facing person. So what this results in is we're talking to that customer, we're showing them some sort of prototype, might be analytical report, might be API documentation, might be a clickable prototype. Usually we've got to iterate, we've got to make some changes, test again with another set of users. Sometimes we validate and after a couple of iterations we really find something that works. And I want you to be throwing stuff away. So a lot of folks have heard this about discovery, but this is a muscle to get going. You have to pat your head and rub your tummy as you're doing delivery. And then discovery put it all together and those two little green areas really show you what I want to change about the process. Bringing customers and engineers into into the fold. Before you build that idea, don't build the untested idea and then stick together. Six months is probably the minimum for each person to start getting some insight. Remember I was talking to two customers a week and I generated the insight after talking to customers for a couple months that they really didn't want my roadmap doesn't come right away. So here we are. This mutilated interactive session section, that's that roadmap. We try to replace it with a goal, a metric goal, something that's measurable, that we can all go after. This gives flexibility to the teams to find the right solution. So let's go through an exercise. Let's say you work at Lyft or Uber. Your team has been given this directive. Create a push message to tell the passenger that the driver has arrived. We've probably all gotten this push message. Okay, so what do we do? We're going to make a user story. As a user, I'd like to get a push message from Lyft in order to know when my driver has arrived. We ask an engineer for an estimate. They just kind of make something up. It's pretty stressful. 20 days, I might pad the time. Don't really know exactly what's involved. And then you just set the priority and delivery date and then you go, don't do this. Let's break standard operating procedure. Let's take a product discovery approach. So please, in the chat, write a one sentence I statement, problem statement that you had to reverse engineer out of that stakeholder or customer or driver or whoever who told you, Hey, I want you to create a push message, this push message. So go ahead and add into chat, write that problem statement. I want to know when the driver's arrived. Want to be notified when my ride arrives. I'm worried as I don't know when the driver will arrive. Time wasted by our drivers when they arrived at the site. Too cold to wait outside. Yep. We don't necessarily have that in San Francisco, but I hear that all the time from folks in the East Coast. Could be too hot if you're in the Midwest right now or New York. Yeah. As a writer. So someone's actually talking about it as a passenger. Want to be notified. I don't want to come out too early. We want to be efficient with our time. Need to know a bit earlier so I can prepare myself. Maybe I ordered the lift and then I just started scrolling. Okay. These are awesome. Thank you. So here's some samples. I can't identify which car is my Uber. I'm waiting too long for the passenger. I don't want to waste time. I want to get the driver moving again. What you'll notice is that the I is different here, even though it says I like, who is this? And someone in the chat had something about time wasted by our drivers. So that's actually from the perspective of the company, what I want is that perspective of one of the individuals in your ecosystem. In this situation, it's the driver. So we'll pick the driver. And a lot of my teams forget to pick a user. When we pick a user, then we can recruit for that user and we can run through a use case. And we do that because we need to connect with a problem or opportunity for that person to give us real feedback. So we'll pick the driver and we'll take the problem and the customer. The driver. I'm waiting too long for the passenger. Everyone has experienced this on the passenger side, not many on the driver side. So now let's think of multiple solutions. Of course, this is going to be the easy part with a bunch of product folks on the line. So now switch it and write a possible solution to this problem that I selected. Yes. Find the customer. That's the stick. I wonder if there's some carrots out there. But yes, I think it was a $5 fine for a while. Not sure. Maybe they still have it. That's funny. Yeah. Send me notification. The passenger's ready, turn on location tracking, notify the passenger sometime in advance and send periodic reminders. Yep. Anybody know what Lyft just did? If not, I'll explain it at the end. In the most recent three months, the driver could be rewarded for time spent. And that's actually what happens with taxis. When you arrive and they lift the flag or they drop the flag, there is wait time. And that's not a concept that Lyft and Uber brought over to their transportation system. Your phone buzzes now. That's right, Omar. Yeah. And it keeps buzzing and buzzing. Yeah. Thanks, Andre. Yep. Really interesting change. Yep, these are great. Okay, so these are some samples. Definitely finding the passenger, displaying signs, sending a text message instead of push message. They can often detect whether you've got this going and they'll send either of those. Of course, in the old days, they just honked the horn. So one of your jobs as product folks is to understand the offline world and how your online solutions affect user behavior. Right. Is it better or worse, like trying to replace the honking of the horn with the whole app ecosystem? It's a very interesting concept. They did it here in San Francisco before people would just honk, knock on our door, rev the engine, that kind of stuff. So there's a non technology solution everywhere and sometimes there are simple technology solutions like text, email and spreadsheets that are hard to overcome. So beware of these very basic solutions. That people use. Sometimes they're hard to overcome with your more app based or website based or other based solution. Okay, so we're going to pick a success metric. That's the last one. You can do this. I want it to be an outcome, not an output. What's the difference? I often think of an outcome as something we don't control. I can control for the most part the launching of a piece of software, hitting a deadline. I can put more people on it, I can reduce the scope, I can get something launched, but it's not the case that I can get someone to use it. Jordan was talking about don't have the skills to build a good clickable prototype. All people are putting this in. What I do is I take screenshots using Snagit. Snagit is my fake Photoshop of choice. And then I throw them into figma. And in figma I make little highlight spots and just link those spots and those make what looks like a screenshot clickable. And in Snagit I often change the text and replace logos. So I taught myself about two years ago to do that. That's the most basic version. So, Jordan, that's a place to start when you're thinking about building a good clickable prototype. Passengers entered vehicles within two minutes of arrival. I love that. Ride starts within three minutes of notification. Percent of drivers spent waiting idling. Snagit is like a print screen. It's like that little key combination you use on the Mac, but it puts it into an app and it organizes them rather than just spamming your desktop and then you can actually modify it. You think of like Paint is the most basic program. Snagit's like, much better than that. Not as good as other software. Remember, positive reviews for applications have increased as opposed to the seamless process of booking. Absolutely. If there's a lot of traffic, lift waiting will cause more traffic. Reduce time spent waiting by 30%. These are great. Again, here's some examples. I typically choose this 1. Reduce 50% reduction in wait time. I think the better way to write it would be reduce wait time from five minutes to two minutes. But again, what I want you to do is just think numerically. Think about a success metric. This is the thing you rally around. A good success metric gives people a common goal and it keeps us open to multiple solutions. If we pick a solution too early, again, we haven't tested it. So stop building untested solutions. Really want you to think about what, what opens the team up to multiple solutions and what are multiple solutions like I said your phone will vibrate when your driver's three minutes away. Feel free to leave the app. Lyft and Uber have built these solutions and more. They spent 10 years on this problem. Pretty interesting way to think about what you're doing as a team and how you can easily take that conversation about the idea, move it into that problem metric space, and then think about how do I test multiple ideas, Right? So we work backwards, starting at that solution. And you can do this. You've got to start somewhere, changing your culture, changing how your team works. You can work backwards and eventually start to work forwards. Set some goals, pick a user, pick their problem. Multiple solutions help. Let them help you validate that solution. So product Discovery is going to keep this loop going, right? Because after you launch your post launch, Product discovery is looking at your analytics, looking at your funnels, your pipelines. Where do people drop off? Do your next discovery. Where that drop off is bigger. There's a client I have where it's 3% drop off on one step, 3% drop off in the next step, and then a 15% drop off. So we just picked that spot, found those users and talk to him about that process. And we learned a ton. These four items really just off this opportunity. Assessment for Marty Kagan's inspired, it's chapter 35. Like all of Marty's chapters, it's concise, it's two pages, and it's helped me organize my team's time and my time. And it's nothing like these long documents that people need to fill out in order to justify working on a product. Because we're not using engineering resources right away, we're using that core discovery team. So it's lower stakes to test ideas if you can get into a rhythm. Okay. And then if you want to learn more about okrs, here are two fantastic resources. Felipe Castro and Christina Watke. Christina Watki's book Radical Focus starts with a 60 page fictional story that is just near and dear to my heart as a startup, lifelong startup person. And for all of you, those first 60 pages are just, they embody so much about our experience and trying to bring products to market. So I highly recommend it. Okay, so how do we accelerate growth? Of course, talking to customers, because all those ideas that we have aren't enough, honestly, and we don't know which ones are good. So when you're accelerating growth, you can actually get in your own way by building things that are untested. Right. So your growth is limited by stuff that may not be that good. You may Have a good idea in here, but it's sitting and ceiling you've created or your bosses. So let's look back in my past where I was product manager trying to gather requirements, talking to CEO, sales, marketing, legal. I'm sure a lot of you done this. You get frustrated and you just head for the door. You're like, I can't figure this out. Everyone's got competing priorities. You hear a lot of this. I want. So that's my customer avatar on the left on all these departments are representing to you different things about the customer. They're really funneling their own dreams to some extent. Now, of course they do hear things, but maybe they're not as process oriented and not as consistent as you need to be in product when you're figuring out what folks want. And really I'll call it need in parentheses. Because we can't really listen to users direct words because they often talk in solutions. So I want you to use that process. We just had to reverse engineer the problem success metric and. And maybe their solution's correct. I want your team to come up with multiple solutions to see if you can solve this need and to do some solution tests. A lot of people are doing the open ended, informal conversations. You're going away and then you're coming back at the end and showing them the product as it's built. I call that the product discovery valley of death. Test that solution. You'd be surprised at how many, how much more you need to do in order to launch successfully. Okay, so now there are lots of users out there. Some of you have 6 users with large corporations, some of you have millions of users. I recommend you just start with one discovery cycle at a time, five to six users, and gain insights from there. Zero users, zero insights. The five to 15 users, you can get quite a bit of insight. So don't forget about this customer here. But a lot of my teams do. So we'll just take the customer down. Just a reminder that you need to test those ideas. So how do we talk to these customers? We do it over zoom. Right. Used to do it in person, but zoom is a preferred choice during these times and it's actually quite efficient and we get a lot of good feedback. Now when I think about an experiment, I've always thought about what's a good analogy for product experiments. Anybody know what this is? Most people probably do, but this is psychology test given to patients to figure out what's going on in their mind. It's like a mind map, but it's more It's a Rorschach test. That's the name of psychologist or psychiatrist that came up with this. And it's when you see this, you might say to yourself, oh, I would explain this as some sort of a bat or some object. And then you get a conversation about what's going on in that person's mind and you use this as a talking point as a way to describe something without asking directly how are you feeling? So we want to do this in product. So I got four components. You have to find users or representative users proxies to get them in the mindset. Think back to a time. It's an elephant. I like that. When think back to a time we don't want to ask users to imagine. And the reason we think back to a time is if they can't remember a time when they had this problem or opportunity, remember then you may not be testing with the right person. Let's say you were testing this solution about getting users out to the curb. If the users never really requested an Uber or Lyft and I have met people like this, they may not be able to explain to you their reaction. You may not believe their reaction to the solutions you're giving them about the phone vibrating or getting a text message because they haven't experienced actually having to get out there. Maybe you're talking to drivers and maybe you find somebody who's not been a Lyft or Uber driver but who wants to be one. Again, no imagining. I want you to think back and channel that experience. I want good content in there. No fake content is a really is a large part of the experience. You don't need to wait for that content writer. You can generate content as a team. Doesn't have to be the perfect content in the end. And I want a high fidelity prototype and let's call this realistic enough. I don't want pixel perfect. I don't like paper prototypes. They can work. But I like getting that muscle of screenshots that are clickable or rough prototypes. And I'll show you an example of what I mean. So you put these together and by the way, you're welcome to screenshot these items. There's my Twitter handle at the bottom there's a hashtag for traction. I'm here to educate and hopefully bring more the more product discovery to your teams help your users have a bigger voice in your company. So put these four things together and you can just start working with users. So here's some great best practices for designing experiments. There's a Bunch of them here, but they're a lot of fun and they're things that I've learned through working with clients the last six years, plus my time at Fog Dog and Power Reviews. So we all have big dreams, but testing a big dream is tiring and tedious, and it's not going to give you great results because you barely get through one version of this. So pick a screen and let's test that screen. Now, if you're doing analytics testing, and I use analytics here because it's one of the hardest things to build and one of the best candidates for discovery, even this screen is a little bit too big. So I want you to even simplify further, one hypothesis at a time. You might have put four metrics on this page on the left. When a user opens that page in a prototype, just a design prototype, we can mock up the data, mock up the results, and they have a reaction like, oh, that's so cool. What graph was it about? And what's the concept that's most interesting to them? If you just show them one screen at a time, you'll know right away, oh, I love having that data. Okay, now, because each time we talk to somebody, it introduces a little bit of bias. And so someone in the chat earlier was saying, I want to reduce bias. Talk less by simplifying the prototypes. You talk less and you get these honest reactions. You might end up building that dashboard on the left and releasing it. But if you test it, like the way on the right, you'll know that each of those quadrants is valuable. Okay, now, in analytics, like most things, I want you to think about what actions people will do. What's the outcome of showing somebody this data? What can they do? Now, sometimes they can't do something, but most times they can. And I want you to make the outcomes, the calls to action, really obvious. Don't make a small button that's part of your design system. You need to be able to break your design system and make things obvious. Why? Because you talk less. Users see the button and they're going to talk about it without you interrupting them. So users might say, I don't like that design. But, yeah, that's the right button. That's fine. We'll talk about design and pixel perfect. If the idea is good, make it obvious. So I showed you this pie chart and most of you are probably going, oh, pie charts are awful. Everybody knows pie charts are awful. I don't like pie charts. I think they're kind of hard to read. Makes me think brain hurts. So my first reaction is, I love bar charts. Bar charts are so much better. Maybe a line chart and then really, don't make me think, just give me the numbers. And you have these meetings with your team and then if you're facilitating this meeting, you're like, oh my gosh, like how do I, how do I break this logjam of all these smart, interesting people? My teammates, we're collaborating like Jim said, but they all have different opinions. Oh no, just test multiple solutions. We're not building this, the data store and putting the JavaScript D3 library somewhere and trying to program these. We can just put some numbers in Excel, make the graphs, take the graphs out, put them into a figma prototype, make them clickable and we'll get a sense of it. Can they interpret this information? What would they do with it? And you, through discovery, you can improve your team morale. If my idea gets in, Designer's idea gets in. I've had the QA engineer sit in on discovery and have an idea and let the user help you decide. So when we expand to multiple solutions, we're going to let the user help us decide. And this is also part of that accelerating growth. I'm not just arguing over one decision, I'm not pre deciding. Right, you're going to self limit your growth if you pre decide things. Let's say you've got this interesting prototype, show it to users and they say, oh, I like this, that's interesting. I'd use this. I have to say after years of hearing this from hundreds of users, that they're basically lying. They're not lying on purpose, they just want us to be nice to you. So I call this the meh feedback. So when you hear that's interesting or I like this, don't walk away with validation. In fact, these are just neutral comments, mostly for Americans. There's a lot of international folks here. So I'll say if you're in France. When we did product reviews, we were in 20 countries and 15 languages around the world with tens of millions of reviews. You aggregate all that data, you get a sense of what the average rating for each country was. And we did this and the French were like a half star below the Americans. Now even more for the uk. And so the idea is that you have to know your audience and how they react. But in America, stuff like this is not validation. What is validation? When someone says, ooh, oh wow, is this available? That emotional reaction when the user just exclaims something, that's what you're looking for. Okay. You get this in business software, I kid you not. Like business software folks are so tired of their awful interfaces that don't deliver value. When you show them something that's simple and valuable, you'll get this reaction. So those of you who think a lot of the discovery concepts are about B2C, most of the examples I share with you are actually B2B. Okay, so speaking of B2B, in B2C, where are your users? They're usually in some other application or concept besides yours. My product teams do their solution tests and they start them inside of their own company's application as if the user spends all day there. They don't. They're on Netflix. How do you get them off Netflix? Well, maybe it's a push notification, Maybe there's a slack ding email teams or you can go to Google Homepage. You can test the starting point in a lot of places. And I want you to become a marketer. I want you to adopt a lot of product marketing concepts because your product won't sell itself and you have to take responsibility for this. Okay? So I want you to choose your own. I want you to add these options of choose your own adventure. There's a book called the Cave of Time. It's one of many of these books. Anybody out there read these books? I did. Choose your own adventure books. The difference between this and a normal book is that at the bottom of I'm going to say a page, you're like four pages in, you've entered the cave of time. And then at some opportunity, the author wants you to make a choice. And one of these choices will probably lead to you dying very quickly. What does this look like in a prototype? It looks like it's humility. We, the product team, I, the designer, I don't really know. I'm not going to assume I know what the users are going to do. I'm going to put a bunch of options out there. Again, this is against my design system. So you're not asking for permission from your design manager. Right. Because this is not going live. This is a test to figure out the demand for something. What would people actually do with this information you've given them? They're going to hit the red pill or the blue pill. Do more icons to see where people would go. And then I give them the kebab icon, which is like the menu. You could use the information icon, the hamburger menu, give them an escape hatch so that they click that. You'd say, what would you look for as a, as an action to Take here. So let the users help you make decisions. Multiple solutions, multiple options. It looks ugly, but users can't create solutions, right? You're the solution maker. The users, they own the problems, they own the opportunities. Unfortunately, what they come out of their mouth are solutions. And you only want to half believe them because you want to test these things. So then my teams start thinking, oh, I've made all these options, I've got to make all these pages and these prototypes get out of control. So don't do that. Just build what you need, which is these options. And then when the user clicks something like the blue pill, great, we're going to maybe build that in the next set of tests. We're going to ask user why they wanted to do that, what they would expect to see on the next page, and then we can build options and variations there. So I want you to be testing frequently. This is not your last user test. Leave something vague. I was in a user test and a design sprint for a very short week and we left off this label for a diagram. As it turns out, users had a different interpretation than the team who built this graph thought it would be best for their clients to have the average revenue. It would be best for a client to see the average revenue for the 12,000 clients. When we left off the label, I was in the middle of the test and I said, okay, what is, what do you think this line is? And they said, oh, this is my, my custom goal that I set. This is the revenue that I want to attain. And it's clear that in December I didn't attain it and in January I did. They heard this from 9 out of 10 users. They'd heard this feedback before, but it was so reassuring and validating that they ended up building this feature, not the average revenue feature. So leave some things vague. Let your users help you decide. Don't be pixel perfect. Like I mentioned, this is something that was created in Snagit with Figma I was describing earlier. Like I said, I taught myself this these concepts. A couple years ago I took the Meetup application. This really has a great homepage and I just started doctoring it and then described a bunch of screenshots and this gave us the results that we were looking for. Even though it's not very nice looking. Then the last item for your bias is to think about your products like this. This is a show. Should there be fish shaped food or just like triangles? A null hypothesis is cats have no preference for shapes and food. And this is what scientists. This is a scientific Approach. This is what scientists do. Product managers in high tech often do this. They take their attitude about what's going to win and they do a test around that. So I always want to take your winning solution, back it out to something. Make multiple options. The multiple solutions. Also multiple solutions also train you to use a null hypothesis mentality. So many good benefits here. Okay, velocity over perfection. Let's say I told you to make a painting of the beach and you did this. You came back three months later, hey, here's my painting of the beach. Actually, as it turns out, these are not the aspects of the beach I was thinking of when I said I want a painting of the beach. What would have been easier to get feedback from me was, would be to build something, paint something very simple like this, right? So the two concepts, complex and simple. Choose a simple one and iterate. You take a screenshot of this. These are all the sort of advice that I give. Again, these are situational to what you're doing, but they can be super beneficial. So again, with these experiments, you're going to do less work, you're going to learn more and you're going to do it in a faster time frame because you're going to, you're going to have a lot of variations, but you're going to make short prototypes and you're going to test frequently. You're not going to keep thinking this is their last test. So we stopped wasting engineering time. We collaborated. You learned how to make some metrics and reverse engineer solutions in the problems. We talked to customers, you created experiments. This is going to be accelerating your growth because you're going to be testing a wider set of ideas sooner and faster to find the good one. And not just pre deciding. I'm going to take Q and A in a second. I would love for you all to go here and fill out my survey because I am one. I want to get better at all this and I want to see if. Oh, you're so nice, Hadi. Here's the link. So this is my tips to you. And then your tips to me can be just anything about presentation and things like that. And I'll share it with Lloyd and then stay in touch on Twitter. I keep it super clean and focused on product and try to be the things that are relevant to my followers. And then I have a newsletter and then just my website. I kind of update articles every week or two and just write about what's important to my teams. And then Lloyd's put where the recordings will be on the traction conf. Website and YouTube channel. So yeah, go ahead and throw questions in either the chat or into the Q and A box and we'll just go from there.

I started my career in product. I was an engineer, went into product, but it was a startup. And so really I needed to learn to sell. I needed to learn to do consultative selling. When you're that first person in a startup, you're doing a little bit of everything when there's no product, right. You're like talking to customers, trying to figure out what solution to build based on the problems they have. You're doing discovery, you're doing a bit of everything. And so I love working at startups because it builds your muscle for product discovery and sales. It helps you craft the messaging. So Omar's question here is, what about customers who say, build this feature and I will buy? What do you do there? My general learning has always been if you keep building what different customers ask, you'll never build a scalable solution. And generally customers ask for a faster horse. They don't ask, build me a car or a Ferrari. So you got to focus on listening to the problems first. So what's your advice there?

Yeah, these are hard. So when you, I would say that you're not a consultancy because and you're not an outsourced engineering firm, you're a product company. And you need to remember that in the long run you want to serve 100 or 1200 clients. And I would do this off a multi tenant platform and that's how I built Power Reviews. And I made a lot of hard decisions as a CTO head of product at Power Reviews. Now if you decide to just copy paste that code base, you are going to make sure that your older clients are stuck on an older code base that will have security issues that will have a lot of problems or you can have a lot of spaghetti code if you build everything in a multi tenant platform. So I think there's technical issues. The big thing is you have this revenue pressure to make money as a startup and you're looking for five to 10 clients to have the same idea. Okay. So if you just build it for one, it's very, very risky. And people will do this because they will. You want to link arms and as a product manager, you want to make sure that it's clear that you're making a group decision because you don't want to put this on your shoulder and say that this is the direction for the future on one client's advice. Okay. So first thing, if you do it make sure you make that decision as a group because it could go very poorly. They might not even use it because they say they want it, but they don't end up wanting it because priorities change. The second thing is the if you are talking to enough users, then you can help drown out some of these singular voices. I find that product teams that stay in their own groups get the most important problems and only those from the sales and the CEO. If you're not out there talking to enough clients, customers, prospects, sales and CEO won't trust you. And I'm not sure they should trust you. And so the when you say that one client, sometimes it's through the filter of a lot of clients you're not listening to. And if you knew if you talk to two clients a week and you got that one request, you would know if that request was aligned to where your customer base is going or not. So volume helps drown it out. If you do make that decision, make it together. And just remember as a consultancy, it's so much more expensive to hire the engineers to build something for one one client. So that client is basically treating you as outsourced engineering. In fact, I have a client who's really big who's done this with a startup and now their feedback to me is they're not listening as much because they're starting to grow and they just got funding. And so you could take this trajectory of bootstrapping your development by using a couple of clients money to start your company as long as you can break away and create a product company. If you don't break away and you keep creating a consultancy, you will stall growth because you'll have a lot of technical debt and you won't have developed a vision and no one's going to follow you. The only people are going to join you are the people who want to tell you what to do. Because you're good at saying yes.

There's a couple of reasons in product and especially as a founder, you need to get really good at saying no. Even like Trello. We had Trello CEO a while back and he said don't listen to customers feature requests, just ignore feature requests. Listen to the problems and creatively come up with solutions to the commonality. Because the worst thing is not knowing how many people it's going to reach, what's going to be the business impact and then building one off, one off stuff and then you don't have a scalable startup. And so tied to this is how many interviews are enough now anonymous attendee ask and My question back is that's an important question. How many interviews are enough? But how many interviews have you done if you're depend on the stage also like how early are you. Startups are built in phases and phase one is validation, phase two is product market fit. Then you figure out a reputable channel, then you scale. And generally I feel if you can't talk to in the early days and this is probably I have a high benchmark but if you can't talk to hundreds of customers when you have no product and then at least get 10 to 15 pay you to try it out in a B2B space when you have no product, I think it's going to be very hard for you to hire salespeople to later sell it when you've built something without talking to customers. So what's your insight here? How many interviews are enough?

Everybody in my business will tell you it depends. And so I'm a more practical type. So I'll go out on a limb and say things that I'm sure you'll find holes in. But I need you to start somewhere. And the one person who's written about this, it's a 20 year article. A lot of people have, but Jacob Nielsen wrote this article 20 years ago. That's test with 15 users in groups of five and in each group of five you learn about 80% of what you need to know. He was doing usability testing, which is the user confused. Can they complete their task when we do value testing it's more complicated than that. But you can still learn quite a bit in these groups of five to six users. If you're talking about something that's two to four weeks to build, that's low risk. Maybe five to six users, eight out of 10 users, you're looking for validation. If you're looking at two to three months worth of work, maybe a few more users, 15 to 20. If you're talking about this entrepreneur I was working with, it's the whole company's idea. Extremely high risk. Where do I start building? Do I build the whole thing? Do I spend $200,000? No, you do it in waves. Lloyd said right. He has to find one person that will will commit to buy this thing and use it and we'll use it like in a prototype form, but then find another. This idea that you can't learn anything from a handful of users often is a way not to test out your insecurities about the product. You can think about pre revenue companies. Once they start making revenue, then they start to Get a multiple, right. We don't want to be treating our product like not testing with users because we don't want to get the valuation on it. We want to really learn. So I would start with five, grow from there. The amount of risk you're taking will tell you how many users to test with. I would also say if you're a healthcare company and your user population is the world, I want you to test with a few more users and round out your demographics. If you're a computer vision company, are you going to test with only white people? Stop doing that. Right. Like you can't when you choose the 5 to 10 people, you may decide the idea looks good, but I'm going to test with more people to get validation before I start to build it because I have the world as my population. So that's the starting point and how you would scale users, either through risk or through demographic risk or through business risk.

Now, do you recommend meet customers individually or as a group? I have a very opinionated view on this, but hear it, Jim.

Always one on one. I'm not a big focus group person. What are people doing when they're using your application? They're just there generally by themselves. They're not like maybe a bunch of people around FaceTime or there's group dynamics in certain products. In 99.9% of the products. It's not a group dynamic thing.

I completely agree.

One of the things.

You launch before you talk to customers, right? And then you get tens of thousands of people or thousands of people. You do the scalable when you're not supposed to scale in the early days and then you start seeing churn and it's very hard to fix. It's like you build something and now you got to reverse engineer and fix the user experience. You waste a lot of time and money like you said. And what I've learned, all the success has come from saying, okay, what is my ideal customer profile? Where do they eat, breathe, drink, sleep? Who is this title? What is the problem? What is the day in their life? What is the job they're trying to do? How do they do it today? Because a solution like this doesn't exist. What are they jangling together? And if they had a magic wand, what does a delighted state look like? Kind of thing. And so I would send emails then saying, hey, research. Really research the person on LinkedIn and whatnot, script the email, send emails saying, hey, you're an expert in the space. I'm an entrepreneur working to solve XYZ solution. Do you have 20 minutes for your time for some advice. Not looking to sell you anything, get them on the call, understand the jobs to be done the day in the life and spend all my time doing that because it also helped me nail down the messaging. It also is hard to navigate when you're trying to do this discovery in groups. So Omar actually further expands on his question. We sell to HR talent, whoever you sell. Most companies have a laundry list of requests at any given time or of the buying journey. What framework Jim, you recommend for product prioritization?

Most of these frameworks are a self reflective journey, right? I do Rice reach, impact, confidence and effort and I write them all down. Maybe I talk to some engineers and it often is just a way to reflect my opinion of these things is as I do the weighted scores and I sort them into my spreadsheet. I compare the top result with what was in my mind as the top result. So I like them as a self reflective journey. Then they look at maybe what was the contribution of it being high or low. The issue is often reach is one of the only things I can do before I do, I can determine before I do discovery. So if you do discovery along with Rice, you can influence what is the impact of this product, how confident am I that's going to be adopted? And when the engineers sit in and help devise ideas, they will get a sense of the fringes of the idea, what the depth of it is, what users really want out of it and they can give you a better sense of the effort. So I think Rice without discovery is mostly self reflection and most people will put their finger on the scale and push the idea they want to the top. And then some people will do discovery of course and they realize that nobody wants it and that's when the reach goes down. So discovery. I like Rice if it's informed with some qualitative. I don't really like weighted shortest job first. A lot of these like quick win scenarios, I believe in the Kano model like you do need some quick wins, some delighters especially in business software, but they can be small. I think you need to do tech debt 20 to 40% of your time. And I don't want to blame the engineers. So let's call it product debt and tech debt. And somewhere in that middle I want to see because you have some commitment. You do, but I want to see that prioritization be informed with discovery and rapid discovery. So that's my thought about prioritization.

We're like at a phase where you get a Lot of feature requests. And I see this, I love Rice as a framework for a few reasons. It's a framework that you don't only use for product prioritization, but you can use it for marketing prioritization and also figuring out new markets effectively. You're starting with how many people is going to reach and then you're going to what is the impact? Financial business impact, what is your confidence in it and then what is the effort involved? And even from a marketing perspective, people just have this T shirt that says I love it when you talk data. To me that's our company T shirt. But I love to hear that this is how many people it's going to reach and how it's going to reach them. Don't do anything if you don't have the reach sorted. And in the early stages when you have no product. Yes. Talk to hundreds of people, understand the problem and creatively come up with a solution. But then as you evolve, you get all these feature requests and some are you don't want customers telling you what to build. You need to understand the problem. Like you're saying, I think once you get to a mature product and you've got these feature requests, I think Rice is super helpful. That's my opinion on it. Right. Like how do you prioritize otherwise? Like you got, you, let's say you, you got a laundry list of things. But like the worst is having a laundry list of things and each one of them is asked by exactly one customer. You never build anything.

I would suggest the one thing I wanted back when I was running product at Power Views was to have a client count on every feature. I almost linked back into my salesforce. I would love JIRA to have been linked to my salesforce. So not only could I get the client count, but I get the client size, like the deal size. So I could basically put deal dollars behind. I could put my potential churn dollars behind something because for us it was not just churning customers. Especially now in downturns, it's churning dollars. This is the lesser known metric in SaaS because most companies will keep customers but lose money as customers Renegotiate, go to 3/4 1/4 deal instead of 1 year deal. There's a lot of things that companies will do to you during downtime. I was at power views during the 0809 downturn. So the laundry list again, you're looking for some consensus out there. You're looking to do some discovery on them because you want to get to the problems. So turn your laundry list of slow solutions into a laundry list of problems. Do card sorting on the problems with your clients. Right. It's hard to card sort solutions. They're apples and oranges. Problems are much easier for people to identify with and prioritize. So turn your laundry list of solutions into a laundry list of problems. Go back to the same customer. Make them prioritize other customers problems because they only think about what's happening to them right now. Expand their brain a little bit. So just a little bit more due diligence on that laundry list is going to make it a little bit easier to handle.

How to onboard potential customers for discovery interviews?

Yeah, short interviews, like 30 minutes. Get in and get out. Make sure they feel valued when you're talking to them. You don't have to agree to their ideas, but you can make them feel valued when they give them. So that helps you get them back. For customer for consumers we're talking about 25 bucks for 30 minutes. That's my rate right now for business professionals. Might be going up to 60 bucks for 30 minutes, 50 bucks for 30 minutes. Depends. And so I'm not afraid of compensating for my own customers. I'm looking for the quarterly business reviews where I've got customer success managers. I can sit in on those calls and take a few of those 60 minutes. Fifteen of them probably. So one of my best friends in my company is my head of customer success. If I'm in B2B and I'm talking to them about how important it is for product to be in touch with customers, I'm getting all my product people and my heads of engineering onto client calls. And at the last part of the client call, you can turn it into a little bit of discovery. Hey, let me give you this link. Share your screen. Click through. So for consumers, you're just going to pay them. For business folks, you're going to use your customer success team. You can also use recruiting services. You just need to vet that people have the problem. Right. You can use professional testers. Not really professional, but people have signed up for these things. As long as you can verify with the story they tell that you believe that they have that problem. So I do think you could find users and that's one of the ways. Those are a couple of ways that I get in touch with folks. And there's userinterviews.com, i use them a lot. They don't sponsor me. I pay for their services full price. And there are other companies like them to recruit.

Figure out who Your ideal customer profile is nail that down. Especially if you're in the B2B space. Scrape a list of those people and reach out to them via LinkedIn or email or both to understand if the message is resonating. And a simple email like this and I did this, all three companies is hey, I saw you're an expert in the space. List the space they're in, personalize it based on something they wrote about or they said on social and say you're an entrepreneur looking to solve XYZ problem. You would love to get 20 minutes of your time. I like the 20 minutes. I read this book long ago in my early days with school called Spin Selling. It's a good product interview style book, but it's actually a sales book is a spin sense for situation, problem, implication and need payoff. It's you're asking about the situation, the problem they're facing, the implications of the problem and then the need payoff is like in a perfect world, how would you see it working? And I love reaching out directly because what ends up happening in the early days pre product market fit is if they say oh yeah, if you had magic wand solution would work like this and I'd pay xyz then you can immediately ask them, hey, can I add you to my sort of pilot list or beta list? You can probe with two questions, would you be willing to pilot this for me? And then you send them a recap email after the call and then add them like Kickstarter, add them to your regular updates, right? Like they become part of your subscriber list that you can constantly follow up with them. So I like reaching out directly and so on because then you have the double whammy of them becoming your customers. Jim, what a great pleasure man. Thank you so much to learn from you. I took a bunch of notes as well. I'm a big fan of the product games, so thank you so much for joining us. Love and peace my friend.

Cheers. Thank you.

Thank you for listening and we hope you enjoyed this week's episode of the Traction podcast. If you enjoyed the show, please leave us a five star review and you can find all the information mentioned in Today's episode at TractionCoff IO that's T R A C T I O N C O N F IO.