Product Discovery and Development Strategies Masterclass with Moshe Mikanovsky

But for all the founders here, and, you know, we have so many amazing people around the world that are founding companies like you guys. This is one of those things that from product management, we're trying to help you understand what are all the things that we have to look at. And that's what I will try to do today. Okay, so let's, let's start with that. So first of all, who am I? So Again, my name is Moshe Mikhanovsky. I'm a product director at Root Quotient. Root Quotient is a product innovation company. We are a global partner of Founder Institute, as I mentioned before, and we have clients all over the world where we're helping them to build products, innovative products. That's what we love building. I've been in digital products development for many, many years. I started as an engineer. I was working for about 20 years on the engineering end of things. And then after that, I started moving into product management, which I was doing for the last about 13, 14 years. You can see some of the companies that I worked for as a product manager in different positions, like Points International, Firmex, Procom, and Rethinking. And below that, some of my clients that I build products for. So I had the privilege to work with some great organizations, loyalty programs at airlines like Alitalia and Virgin Atlantic and Hilton, some banks for recruitment like TD Bank and BMO, and also with Bloomberg for some risk information for financial risk. So as I mentioned, I'm the product director at RootQuash, and I also host our podcast. It's called Beyond Product, and this is a podcast that we started recently. We already have quite a few episodes, so you're welcome to check it out. We are hosting over there founders of startups that are building something interesting and they're using technology to help them with the development or with the, the, the solution they're building. And there is a lot of tidbits over there that will help you from their experience. They're giving through the podcast a lot of tips there. And I'm also a professor. I'm teaching at Schulich School of Business here in York University. So that's about me. Now let's start diving into our topic today. And I have a little agenda for us here. First of all, we'll go into why do we even need product discovery. Then we'll talk about the discovery in order to mitigate risks. I will introduce a tool that we are— we have built and used at RiskQuotient called the Product Risk Radar. Which will then go dive into the 4 discoveries. And eventually, we'll talk a bit about who owns the product discovery. So why product discovery? That might be obvious. And I'm sure it's probably obvious to everyone here today because you joined this webinar. But in general, there are really things that we don't know, we need to be humble about it. So we don't know what we don't know. And we need to go and understand what are the things that we should really do. And the things that we think we know might not be the right things because maybe other people don't have the same experiences we do. Therefore, problems or solutions we're looking for might not be really the right thing to work on. We also want to reduce the risk of building the wrong thing. So because we don't know many things, sometimes we will go into directions that will not really work in the market. So we, we, that's, uh, something we really want to reduce, um, and we want to reach this product market fit, which is quite elusive sometimes. How do we get there? What is it exactly? But just to reach it, we want to reduce the time that it takes us to get there. So by doing discovery and continually doing that, we can reach it much faster. So that's first of all about the why. Now let's break it down into two types of problems. There isn't only about solving something but in finding the right solution. There is also what we call a problem discovery. So the problem discovery is really about what is the right product, and the solution discovery is what is the right solution that will actually make that problem solved. So if we're looking at the why, why is it that we need to solve a problem or do problem discovery? The why, the answer, the question we're asking over here is, are we spending our time and resource on the right problem? So there could be many problems out there for us to solve, but what is really the right problem for us to solve? Then on the other end, why are we doing solution discovery? The question we have to answer over there is, is the solution we're building going to solve this problem? We might be able to build many different solutions, but not every solution is actually going to solve it in the right way. Even if we think it is going to solve it, we really need to do discovery to find out and get some evidence that it's actually working. Now, the next— after we understand the why we do it, we need to also ask which one, because there could be many opportunities for, uh, for us. An opportunity here is, is a key word. Um, on the problem, we can identify many problems that we can solve. So the question is, which one is the most important of them to solve? Uh, even if we have one problem in mind, we always go into the details of that problem and we start finding and unearthing new problems. So then, are we finding a new problem that is even more important to solve than the one that we initially thought? We always have to, to have that in mind. And then, which one on the solution side is it solving in a better way than other existing solutions? And here I would add also, which of the solutions we're trying is solving it in a better way? So for looking at existing solutions and also looking at different options for us to solve it, which one of them is really the best way? That's where we should put our money at. So if we're looking at everything overall and everything going to these opportunities, so which of the opportunities is the most promising to develop? On one hand, to solve the biggest problem that we can find or the most painful problem. And on the other side is the solution that will solve that. So now that we are talking about the problem and the solution, the idea in understanding the why behind why we need to do discovery, the idea behind discovery is, is really to mitigate our risk. So let's look into, first of all, what are the risks that we have when we build products. This is a based on Marty Cagan. He is a partner at Silicon Valley Product Group, and he identified 4 products that I want to share with you today. Sorry, 4 risks in the product. So the first one is value, and that risk is saying, is there value to our clients with what we're creating? So that can go into both the, um, product— the, the problem. Is there a value for the clients for us to solve the problem for them? And also, when we build the product, are we creating value to them so they will be— they will want to use it? The second risk is feasibility. Can we build it? So this is a, a risk on our end. And is it feasible to us to build it? And when we say that, is that going to actually whatever technology that we know or is available to us or we have to go and learn, is it going to solve this specific problem? The third risk is usability, and this is about can the user understand it and use it? If the users will not understand our solution, they will get stuck, they will not be able to really fulfill the problem, the solution for the problem that they came to fulfill, then they will not use this solution. So we are asking over here, can they understand it? And we want to reduce that risk. And then the last risk is viability. And this is about our organization. Can our organization support it and sustain itself? So with all the money we spend on it and the resources we spend on building the product and the people that we have to put in place, and then the product that we're building, Are we actually sustainable? Do we have a return on investment? Can we grow the organization? So this is more about the value to us rather than the value to the clients that we talk about in the first risk. So these are the 4 risks. And then for each one of the risks, we are doing a specific discovery. So at Root Quotient, we, um, we are doing these 4 discoveries, each one of them specifically to solve or reduce the risk for each one of, of, of those. So for the value risk, we're doing a feature discovery. For the feasibility risk, we're doing the technical discovery of all the technology. For the usability risk, we're doing a creative discovery for the user interfaces, or if it's IoT, for the sensors, whatever the interface that users are using there. For the viability, we're doing a business discovery. Each one of those is helping us to mitigate that risk. Now, there are many methods to do these discoveries, and I will mention some of them later in our presentation. But what we found out through this work with our clients is that it was hard for them to see the big picture and to understand where is that higher risk, where is it that we really want to go next, prioritize our discovery. We don't have unlimited time and resources, no one does, and therefore we want to really identify where out of those 4— and there might be multiple places— but where should we really focus on next? What is the highest risk that we have, and therefore what is the highest discovery need that we need to put on our roadmap? So what we did is To help them, we build a visual tool that is called the product risk radar. And with this radar, we are showing them, we plot the radar with all the risks in one place, and we have a very clear picture where is it that we have to go next and then start doing this discovery. So what I will show you next in the following slides is how do we visualize those risks on the radar? And then what are the measures that we use there, etc. So you will get understanding of that. I will also use some examples from companies that hopefully most of you know, I think all of you will know, I think all of you will know all of them. And those will give you some really interesting examples of what risks they had and what were the— why they might have failed when they failed, and therefore learn from, from others, you know, how to mitigate risks in the future. Okay, so let's, let me start introducing first of all the product risk radar. So what we're saying is that the problem is always in the middle. You always have to really understand what the problem is, do discovery on the problem, but then you will not build the solution without understanding the problem. The solution is somewhere on the outside. If you imagine you're going from understanding the problem in the middle to reaching the solution on the outside. If we're going this way, outwards, we're getting as close as possible to the solution. Then we are breaking the radar to these 4 quadrants, each quadrant for each of the risks that I explained before. So we have the value, viability, usability, and visibility on the risks. And then I have, um, we have spokes for each one of them. And each one of them, it's, uh, you know, quite simple. We could have done many, many spokes over here, but we We have grouped them into 3 spokes. I will explain each one of them in details later. The measurement on those spokes that we're using is a measurement of evidence that we have. So for each one of those, we will say or we'll ask those questions, what evidence do we have that we actually have enough data, enough information? Could be qualitative, it could be quantitative information to tell us that we have high risk or low risk. The closer we are to the problem, the higher the risk will be. The closer we are to the solution, the lower the risk is going to be. Then we have those zones, and the zones is where we're saying if the number that we have here between 0 to 10, on the evidence level that we have is somewhere in this blue zone, then this is a high risk and we should really pay attention to that. And when we're looking at the next two bands over here, we have a low-risk zone, and then after that is a safe zone. So the idea is really to get to that zone over here. Now, what does that really mean? I will show you later on when I'm talking about each one of the spokes. But the idea there is to really look and think about what evidence do we have, try to plot that, and then understand our risks. So, so let's dive a bit more into that. So on the value risks, uh, we're looking at, um, 3 spokes, and each one of them is divided also between the problem and the solution. Now the idea there is that when we're only looking at the problem and without the solution. And, and, and the problem is not just, you know, what is it that the users is trying to achieve, but also what do they have in their hands right now to achieve that. So if they have other products or if they have other solutions, maybe they do it in an Excel spreadsheet, whatever the, the things they're trying to do. And that's the question that we're trying to, to ask over here. What are the things that we know about the problem. And then when we look at the solution, we will look at our idea of the solution, whatever stage that idea is, whether it is early stages or we already have a solution for them and we're building new features, whatever that is. And then saying, how much evidence do we have on that area? So let me start breaking it down. So the first spoke that we're using is pain to remedy. And the, and the On the problems idea, the pain means what is the real pain to the users? How painful this is for them that they will really need a solution? And we know that we want to build medicine, we don't want to build vitamins. But even in vitamins, when someone wants to have healthier lifestyle, etc., there is a big market for that as well. Maybe vitamins are not as painful as when someone is sick and they need medicine to heal them, but that will be a different problem to solve. We're always looking at, is it a real pain and what size that pain is? On the remedy end of things, when we look at the solution, we're looking at, do we provide real remedy to this pain? We always connect it to that specific pain. And there should be an alignment over there to see, yes, there is an actual, um, solution there. There is an actual remedy. Uh, the users are, uh, relieving some of the pain that they have. Um, the next book that we have is about users and clients. So when we look at the problems, we're starting to think about, okay, so who are these people? Who are these, uh, users that will be able to— that will need our solution, that have this specific problem. And then we, on, on the, the other side, we have clients. And this is the conversion spoke where we were saying those users will become clients. They will be willing to pay us because we are creating real value to them. We are actually converting them into clients. Now, the last spoke that we have over here is testers to promoters. And on the testers end of things, this is where we, we need to look at, do we have even anyone that has this problem that we can reach and we can do research with them and get evidence, you know, that they will actually be willing to use this product? Do we know where to find them, where they are, etc.? And then on the other end is promoters. So once you have users, you have clients, it's not enough that they're just clients. You actually want to have people that promote your product. They will really start selling it for you. And if you're familiar with NPS, this is what we're looking for, to have higher level of, uh, net promoter score, which is those promoters. So higher promoters. Um, here I have an example, the first example for you, um, to, to see, okay, what does it mean to really understand those, um spokes and, and, uh, those criteria for value risk. And Quibi, if you're familiar with them, uh, it was a company that was founded in 2018. They were trying to create a short-form streaming platform for mobile devices only. So they were founded by Hollywood industry executives. They knew how to build quality movies and quality TV, and they aimed it to millennials. So they were sure that millennials are going to use it because they are using mobile phones and they're on the road and they want high-quality content. You see how much money they actually spent. They had huge funding there. They, you know, they had two series of funding And they were really positively sure, as you can see in the quote here from one of the founders, that they know their users better than the users knew themselves. But what eventually happened is after 2 years, they actually closed up. And they closed up mainly because those millennials that they thought wanted this content, they didn't really care about that. They didn't look for high-quality short-term content. And they were quite happy to stay with the other products that created more organic, people-generated content. And they were happy with seeing the high-quality ones at home or on their computer, but not on the mobile. So really, on the problem end of things, they had a very low evidence that millennials really wanted that. And they might have clients like users. There is plenty of millennials out there, but they didn't really convert them. There were no conversion there. And definitely there were no promoters or not enough promoters to promote them. So now one thing that I want to highlight over here, and I didn't yet go into the other coordinates, is that usually there are multiple risks that might affect. It's not just the value risks. So other risks might affect as well whether you will be successful or not. But I wanted to share with you specifically here that they have that problem of not understanding the users. In their case of Kwibi, they also had a black swan event with COVID Unfortunately for them, COVID started. But it wasn't just that problem. The main problem really was that their users didn't really see any value in it. Now, how do we do discovery for— and what we call feature discovery to mitigate the value risks? There's many things you can do over here. We have prepared for you a playbook that you will be able to download at the end of this workshop. It's quite a hefty playbook. You have a lot of different tools over there that we listed for you. It's all in one place, so you don't have to look for them too much, as well as also explanation on how to plot your own Radar. One example that I show over here is hypothesis definition. This is a common hypothesis structure that you can use if you don't know it yet. But one of the tools that we have to do feature discovery is to define our hypotheses and then validate those hypotheses. The hypotheses are really assumptions that we have. So if we assume something about how our users are behaving or if we will create a specific solution, then they will be able to solve it in a certain way or alleviate a specific pain. In order for us to really, first of all, be able to understand what we have to go and research, We really didn't need to define those hypotheses, and we need to prioritize them as well to say, where is the highest risk that we have here because we don't have enough evidence and we really need to find out? And then we can define different ways to test it. We also give you in the playbook some ideas there, like creating a fake door, If you're not familiar with those terms, don't worry about it. It's all explained in the playbook, and there is also links to referral sources that we recommend you to use. There is quite a bit of sources out there in the world, so we try to put everything in that playbook for you, to help you. But just to go quickly with this, research can be done in many different ways. You can observe the users. You can look at the competition, learn what the competition is doing. You can go and try to look for people that try to solve it. Maybe even people that try to solve it in the same way you're trying to solve it and maybe see why they failed. What were the reasons? They probably learned something in the way. We already mentioned the hypothesis validation. You want to do value testing with users, not just— usually we're tending to do usability testing with users. So we will create some mockups or wireframes and we'll ask them to use it and they will go through the steps of doing it. But we forget to ask them, are they seeing any value in it? Will they use it? And you really want to do this validation as well not just your usability testing, but also value testing. And another great way for you to do value testing is ask for payment. So ask them to pay for it, because then you will see if they're willing to spend money on your solution. Even if you don't have yet the full solution, you, you can start by asking them for their intention to pay, And then when you have your first version or an MVP, you can ask them for payment. And it doesn't have to be a big payment as long as you ask them for something. And collecting feedback is another way that we, we always need to get feedback on the things that we have done. So you can do it by interviews, you can do it on the test that you're conducting for hypotheses and other things. You can do it in the usage of the product. It all depends also on the stage where the product is. Okay, so now I have a poll for you and I want you to answer this poll. So I will switch over to the poll and the question is, who in your mind, or do you know, owns the value, risk, and feature discovery? And in the poll I have some, um, Let me see if I can see it also. I am not sure. Does everyone see the poll now? No. Okay, I think Ian is coming up and he's going to bring the poll.

Uh, so it is there. If everyone clicks polls, it should be there. Uh, I will try to set up the next one, the next poll for some reason. Yeah, it's not taking over. I just need to play around with the settings. But yeah, we have somewhere— we have 2, 3 people who voted. So if everyone can click the polls button underneath Q&A, you should see the first one that's there. Yeah, we have some coming in, uh, Moshe. So that's okay, I can give them, uh, you know, uh, some time here to We have 15 votes, so early, but it's basically a split between CEO and product.

Okay, let's see what more people are saying.

Yeah, 22, 26, so it's splitting. There's some, some people sprinkling in design, but it's, it's pretty much an even split between CEO and product after 31 votes, right? A little bit on the product side. Is it the right answer?

Well, let's wait for the end because there will be. Um, yeah, um, no, these are, these are good answers and I'm glad that people have found it and are able to. Um, I see some people still don't see it, but that's okay.

Um, yeah, it's at 43 votes. Uh, 45% is for CEO, 2% is for engineering, 4% is for design, 40% for product, and 6.82% for sales and marketing.

Oh, okay, interesting, very interesting. That's great. Maybe at the end, I don't know if there will be at the end ability to see the answers for all the polls, or maybe—

Yeah, it should, it should be everyone who votes can see it in the same time. I'll set up the next one so it takes over the screen, but yeah, if you want we can move on.

Okay, perfect. Okay, cool. So let's move on to the next quadrant, and this is the viability risks quadrant. Again, here I have 3 spokes that I want to share with you. The first one is between legal and compliance. Then on problem end of things, we want to ask ourselves, what is it legal to work on this problem? Assuming that everyone here are working on something that is legal, it's probably quite obvious that it should be legal. If we look at everything in life as a product and also some illegal products is a product, sure. I mean, some people maybe are criminals, but in general, that's where we want to see. And usually that's not a big risk for us if we know the domain that we're working on. And then on the solution side, we're looking at, is it compliant? Are we compliant with all the legal needs? So what are the legal needs that we have for this specific problem that we're looking at? There could be here different type of compliances that we need based on the state that we're working at, based on the stage where we are in, based on the local— the locale where we are selling the product. Where our users are, etc., etc. So here we have to also see what evidence do we have that first of all we know the compliancy and then that we are compliant. And the more evidence that we have that we are compliant, the lower the risk that there will be issue there. Second thing is market size to a business health. So on the market size things, we want to see What is the size of our market that can sustain us? And we know sometimes that we might be very optimistic about, you know, we have a market size of billions of billions users and billions of billions of dollars opportunities, but it's always good to scale it down, especially in the beginning of our journey. Even over there, we want to see, do we have enough clients, potential clients in the future, and will be able to grow the business, you know, sustainably. And then on the solution end of things, we need to look at how— what is the health of the business with everything that we're doing to support the product, and do we have an ROI there? Now, the business health and some of the aspects over here could include things like You know, do we— can we support it with the people that we have? Do we need— how much manual stuff that we have to do that cost us money at the end of the day to support a specific product? What is the operational cost that we have to— the technical operational cost, any type of operational cost that we have? So, so all goes into into the business health. And that's, um, uh, if we don't have a high, uh, health there, we, we have a risk, of course. And we'll see it later in a, in a good example for that. Um, and then the last one is on the ethical end of things. In the problem side, do we have an ethical problem? So what are the values we have as, you know, uh, founders, values as people, as human beings, and value as an organization And is the problem aligned with this, with this, uh, with those values? And then on the other end of things, once we have a solution, um, how do other people see it, see us? This is our ethical brand. Do they see a company that is ethical, uh, it's following its values, uh, or it's creating issues with their solutions with your product that other people— sorry, one second, my power just came out. Here we go. So do people see us as ethical? And therefore they might— they will use— they will tend to use our product more than other products that may not be from highly ethical organizations. That happens a lot with different organizations. Let's talk here about viability risk example. You might remember or you've heard the stories of the dot-com bubble in the 2000s that blew, and one of the most known companies back then was Pets.com. It was an online pet supply store that were trying to sell to retail consumer customers, so it was B2C. Uh, it's founded in '98. It even went IPO in the short time that it existed, uh, with a total funding of $300 million. Um, and, um, the revenue, as you can see, was very, very low. Um, now these days there are several companies that are doing very well online selling, um, you know, pets, um, food and pet supplies. But back then, this was actually a real issue with the viability of the organization. Some of the reasons that they fail, and you see like 2 or 3 years that they existed, was it was very expensive to operate back then. There was no cloud, so they had to create their entire infrastructure for to support this business. There was no smartphones. People would have to order their pet supplies from the internet, and it wasn't as available to people to do. They lost sales on every unit that they sold. Many of the problems they had was like shipping. It was very expensive to ship big pet food packages. And At the time, things like books were fine to ship, but, uh, so the model worked for Amazon that started selling books, but, uh, to— with the pet supplies, it was much harder. Um, and people also were not as used to this technology. So you see also over here, there are other risks, but really the risks of business health, what was— what caused them at the end to close up because they were worried about all of their investors and they didn't want to continue that route. Um, here again we have a lot of tools that we collected and put in the playbook for you, um, on how to do a business discovery. It starts first of all with business alignment. You want to make sure you have alignment between your organization vision. What is the vision for you as an organization in the long term? Where do you want to be? What are the big problems that you want to solve? Then what is the strategy for the organization to get there? From, from that, you want to define your product vision and how that aligns to the, to the strategy of your organization and the product strategy. Um, now sometimes when you start, you may think that product vision and company vision are the same thing. It might be if you have one product, and it might be if your vision may not be big enough, but usually these are two different things. Um, think for example about, um, uh, Tesla. They're trying to reduce emission in the world. That's their company vision. And then they have different ways how they do it, where the Tesla car is one of those ways to reduce emissions and get to net zero. Here I have for you a screenshot of a product vision statement template. This is a common template that you can also find in other places. We are using it as well, but there is a lot of resources out there in the world as well. And like this one, we have more templates for you in the document. Next, you want to define what success means to you. This you define in like specific KPIs. The playbook goes into the details of leading KPIs and lagging KPIs, what the difference between quantitative and qualitative, how you instrument it into your product. So there are many different, uh, ways there that, that will help you with that discovery. Um, market size is another thing that you need to research and you need to discover what is the real market size. And like I mentioned before, uh, you don't want to go with unattainable or too big market size, and you don't want to go with a too small market size. So you need to really to understand, uh, what is it that you can go into and that it is a sustainable for you. On monetization, we, we have examples over there about different ways to monetize and, and how to test it and what you need to do to discover the right one. Same thing with the compliance, the parameters and, and areas that will impact your compliance, looking into areas of compliance that you might not think about. And things like that. Many of those things you might already have. One of the things we find helpful in the playbook is to put all of them in one place. So if you already know the compliance, you can put it in there, and then it will help you understand the level of risk that you are. Go-to-market, we are talking here more about what do you have to do internally in the organization to be prepared to go to market. Like, what type of support do you need internally in order to support your stakeholders? And what type of customer support you will need? And maybe what educational information you will need to create? All of it in order to help you with your, with your product. But each one of them will impact your business availability, because at the end of the day, there is a lot of cost related to that, which is the last item over here. Okay, so here we go into the second poll. And on the second poll, I want to ask here, uh, who wants viability risk and the business discovery? Same, uh, answers, um, as before. Oh, here we go. Now this is a poll on the screen. Awesome. Great. So if you can go and vote there, we'll give you a few seconds. I don't see the results. Do I need to click on it to see the results there? I guess. Okay, let me, let me vote something.

Yeah, if you click, you should see the results, but I can— do you see the results, Moshe, or no?

Yeah, now I see them coming up. Okay, great. So I see 59 votes, CEO 43%, engineering 6 and a quarter, Design 6%, product 32%, sales and marketing 9%, support 0%. Okay, good. So there is more votes coming in. Excellent. Good. I think it's, it's, uh, the trend is still there that most of it is a CEO, like 44%, and then 34% product, and then small percentage, less than, uh, 10-5% on sales, design, and engineering. Okay, perfect. Let's move on to the next section. And the next section is about the usability risks. So now we're talking about can the users use the product? But we still have some questions here also on the problem and not just on the solution. And that's mainly on things like what are the things available for them today, how they solve it today, and what is their full journey in, in this area of the pain that they have. So the first spoke here is between user constraint to user-centric. User constraint is all about what constraint do they have in the journey where the problem is. So constraints could be things like accessibility, uh, you know, they either cannot read well, they cannot they have accessible issues with their— how they move around or things like that. Or there could be things like other constraints in their environment. So let's say they are in a location where there is no internet connection and they need to use a specific product that cannot— will not be able to connect to the internet. Or they only have mobile phones and they don't have access to a desktop, or other things that you will see as you do the discovery. What type of constraints do they have? And this is all in the problem area. Once you create a solution, then you will have to, to, to see, is it, is it user-centric? Is it built with the user needs in mind? So, uh, only when you see users are actually using it and utilizing it and solving the problem you will be able to actually see that it is user-centric or not. The next one is frustration to ease of use. With the solutions that users have today in the problem to solve this specific problem, what makes them frustrated? They are stuck in different area and they just can't go on to the next one. You probably have seen it yourself with product that you have used, where you're like, oh, I wish this was designed so much differently because I'm— I don't really understand it, or I can't achieve what I'm trying to achieve, or this product is no good, or whatever it is. Um, so those are type of frustrations that you will see when you recently discover, uh, the problem and you look at how users are using, um, the, the current solutions. And then, um, the ease of use you will see with your product do the users really understand it and don't get stuck. And ease of use could be many different things like less steps for them to do things, etc. But at the end of the day, it's really about they solve their problem and they solve it in the best way possible. And the last thing is from user psychology to design know-how. So the user psychology affects a lot what people are using when they have a problem. So what type of solution they will choose and what will be their state of mind when they actually use something and get to a specific point in the process. And it's not just in the beginning when they have the problem, it's throughout the entire process of using any product. So if you will give them different way to, to, to do in the product, you might frustrate them or you might create anxiety there, or you might create a state of mind that they will be more susceptible to continue using it or not. And then on the design know-how, it's more about do you know how to actually design to elevate any of the issues that they have, any— elevate any of those frustrations, but also fit it to the state of mind where they are. Um, so, so all of those will do— will go into usability. Uh, the example that I have over here is Google+. So if you remember back in 2011, um, Google tried to create their social network to compete with the other existing social networks. And one of the main things they also try to do over there is to integrate it fully with the Google ecosystem. So unlike the other social networks at the time that were not so integrated, that was one of their unique value propositions they were trying to do. They spent a lot of money on it when they started. It's estimated that more than half a billion dollars was spent on it, and this is just on the, you know, to start it. When at the end, when they closed it down, 2019, they had only 200 million users on it. Um, but they really believe that there is a place for a new social media. And what happened over there is that there was a lot of, um, issues with the design. They were trying to do things that were quite innovative and where it did not exist in the other social media platforms. Um, something like the Google+ Streams that made people very, uh confused and they didn't really understand how to use it and they just gave up at the end, those people. It's been shown that 90% of the user sessions on Google+ lasted less than 5 seconds towards the, the end of its existence in 2019. So really people tried it, they wanted to use it, they actually been forced to create a Google+ account because of that integration that Google created between all their services, anyone that created a Gmail account was forced to have a Google+ account. So it wasn't a lack of users, but there was really the lack of usability there that people just didn't really understand how to use it and just gave up. So here in our playbook, we also have, you know, quite a bit of resources for you. The screenshot here is from the user journey map. This is a quite familiar user journey map. Some of you might have used it before. And it's really trying to understand the mindset of the user, What is it that they're thinking? What is it that they're feeling? What are the pains that they have? And then once we do that in the journey, and, and when you use it, you, you should create any number of stages over there of your journey, of your product journey. We can also list what type of opportunities do we have to actually help them with that. So that's again one of the tools in the playbook. Other things here are like, how do we understand the users? So really, the importance of doing this discovery is to understand the users, to observe them by observation, either try to do the work. So sometimes when you go into their shoes, you get a much better empathy towards What is it that they're doing and how they do it and the pains that they have. They're designing from their point of view. The user journey map will help you with that. And also we have a whole list over there of things to look for when, when you try to design, to look at design for success. So things like happy path, accessibility needs, and also design for failure. Like identifying edge cases, looking into validations of information, many things like that. We're also talking about familiar versus innovative. We saw what happened with Google+. They were trying to be innovative and people just didn't get it and couldn't use it. So there is a balance there sometimes between how much innovative we should be versus we should really create something that people are very familiar with and they will be able to use it right away. So there is no, um, issues for them with that. And then usability testing, uh, there is a lot of material there. We also include a link to some great resources outside that are talking about how to create user testing and etc. But the idea there is to Find real users and always test with real users. Not like— it's not enough to test it with yourself or with your friends, but with the real user that has the real problem. Create clickable mockups, plan your testing and conduct them. Get analytics on, you know, from, from your data, from your products once it's already live. So how do you collect this data and stuff like that? Things like A/B testing and session replay, a lot of— Okay, then the third poll here is about who owns usability risk and creative discovery. So we have the poll and let's vote. So I see the votes are coming and we have already more than 40. Um, almost 10% are saying the CEO, uh, less than 5% engineering, 58% design, 21% product, uh, 7.8% sales and marketing, and no one support. And there is more votes coming in. I will just wait a few more seconds here to let more people But we already— I don't think that the trend is changing here with the more votes we're seeing. So I do see here most people are saying design with over 55%. Next, 22% is product. Next, 10% CEO. CEO has a lot of work, doesn't it? And 7% sales and marketing. And engineering tool present. Okay, cool. So let's continue. Last is the tech— is the feasibility risks quadrant. And here we have also 3 spokes. The first one is about how do we fail fast when we— so the problem that we have is this problem that we there is enough technology out there that whatever solution that we'll try to build will allow us to experiment and fail fast. So if we're thinking about just software, that's much easier these days with different mockup systems and different prototype systems. And remotely, we can go and ask people to, to test things. And there is services these days for user testing online and stuff like that. If we think about hardware and software like IoT or other type of product, it becomes much more complex because how do we do mockups with hardware? With these days, with the 3D printing machines, it's actually much easier than it used to be in the past. But there are definitely things that are harder to fail fast. So, so that's one of those things that we want to look at. And then on the solution side, we want to look at build lean. And, and this means, can we, with all the technology that we have, are we set up to create products quickly, release them quickly, and then start getting feedback from the users so we can iterate on it? Because part of this discovery we were talking about, you know, the technical discovery here Part of it is really understanding what works for users. All the discovery is that, and therefore we want to release things as fast as possible and get the feedback from them as fast as possible. The next spoke here is between emerging technology and standard technology. And emerging technology is very early ages. So again, is the problem that we're facing here and the solution exists in the area Is it like emerging or even before then emerging and it doesn't even exist? If a technology doesn't exist to solve it, it might be sci-fi. It might be really well in the future when something will happen. But at least we want to start with something that is an emerging technology. There will be still risks over there because we will have less people that might be familiar with it or using it. Then on the other end of things, if something is already a standard tech, then everyone will be able to use that. Everyone will be able to afford it and we will have much easier time to sell the product. The more standard the technology, the less risk that we might have. Then the last one is tech ecosystem to tech know-how. On the problem end of things, do we know the technical ecosystem of the problem? So when we create a product, it's not always just that product and that's it. There is a whole ecosystem that might be around it. So users might use other products at the same time. Uh, they could be physical or digital product. Uh, the user might have, um, the main product that they use and they will not move from that product. So How do we fit into that ecosystem? And then do we also know, first of all, what is this ecosystem? And do we know how to integrate with the ecosystem? And then the tech know-how. Do we know how to build in the best way? So whatever technology we're choosing to use, we also need to be able to know how to use it. If we don't know how to use it, we need to see how easy it is to learn how to use it, or can we hire someone to to build it for us. Now, the example I want to give over here is a bit Project Titan. This is the— out of the four, this is the one that was ended recently, actually this year, 2024. This is the Apple car that Apple envisioned back in 2014, a full self-driving car that does not require human intervention, no steering wheel and no pedals. So they really wanted to change how people were driving, or not really driving, because they wanted the car to be fully driving without the steering wheel, without pedals, without any interaction with the users. And if you think about it, this is a bit still a science fiction, um, and that's probably was the issue why, uh, they closed the, the, um, this product. They've gone through a lot of problems in the 10 years of iterating on it and getting different people to manage it, etc. But one of the main— and you see how much money they spend on it, uh, $10 billion, like a billion dollars a year, um, and how many people, um, were on the team and, and laid off, uh, this year because they closed it. Um, but, but really the problem over there is that they could not fulfill this vision that they have of no human intervention and no steering wheels, no pedals, no nothing for human to, to touch on the screen and tell the, the car how to move. And it was an immense technical challenge that even for Apple was too much to overcome. Um, so, so they decided to drop it. Now, Apple, and also in the previous examples of Google, they could probably afford it. And a lot of the technology that they developed is going into other products that they, they develop. But for us, you know, as founders of startups, we can't afford making mistakes like that. So we should definitely see that, yes, this is something feasible for us to do. So on the technical discovery, the playbook is divided into 3 sections. One is technical considerations, things like, you know, do we— what is the technology, how much it will cost us to acquire this technology, um, what, um, is it available for us, is it a good fit to solve et cetera. On the business operational, we have things like, you know, how, what is the competitive edge that we are creating by using this specific technology, the cost to acquire, what DevOps or operational things do we need and how much it will cost us to operate it and things like that. And on the non-functional considerations, We have things like security considerations, scalability considerations, maintainability, you know, is it— can we maintain it? Is it easy for us to maintain it? Or just the cost of maintenance is going to be too large for us? Things like speed and performance of the product, of the technology, etc. And our last poll for today, and this poll is about the feasibility risk and technical discovery and who you think is responsible for that. Let's see the votes coming in. Oh, this was fast. So 34, 40 votes. So we have the CEO 22, engineering is 55. Uh, this— it's still coming in, so it's still moving very fast here. Design 7%, product is 14%, almost 15%, and 1.5% for support. Okay, so we are kind of like now establishing a bit of numbers that don't move a lot. So right now we have engineering 60%, CEO 14%, product— oh wait, this is moving a bit— Product 18% and CEO 13%. Okay, good. But overall engineering almost 60%. Very cool. Now I want to next put it all together because there are a few things that we have to be aware of when we plot the risks and we understand, you know, how to do it and what are some of the gotchas there. So first of all, Um, when do we, when do we do, when to do product discovery? So product discovery really should be done over time, and it should be done, you know, all the time, I would say. Um, the idea there is that it could be for the first product, like 0 to 1, or it could be for any enhancement, any version, any change in the market. So things that happens will impact, you know, the risks of, of your product, and therefore the need for to do discovery. The important thing over there is to really have a balance so you don't do it too much and you get into rabbit holes, and you don't do it not enough. And that's usually what happens. People don't do it enough, and therefore they go into directions that if they do enough discovery, they will find out maybe it's not the right way to go. Then you also want to do it throughout your entire domain. So you want to see that you do it like on the product level, on a feature level, maybe even on a portfolio level if you have multiple products. Now, when do you plot the product risk radar? I would recommend, and that's what we do with our clients, to do it quarterly at least. You can plot it more often. The idea there is to see at this given time what are the risks And where are we on the risks and what should we do next in order to reduce those risks? Now, I want you to pay attention to a couple of things. The first thing is this is really directional. So it's, it's by using evidence. So on each one of those spokes that I mentioned, you, you're using an evidence here to say, okay, I have enough evidence to say that, um, let's say on pain to remedy. Okay, so this is a big pain. So, um, I, I collected information from many users. I have qualitative information, I have quantitative information. I looked at the competition. I see that there is a problem there that, um, people need support with them. And I feel that, you know, the evidence is somewhere around, uh, 4 for the pain or 5 for the pain. So, you know, this will be subjective to you. And when you fill it up, do it, you know, with your team. If you're, you know, alone, do it on your own. But in general, as you go over time, you will see how, how that works out for you and use it as a direction. So it's not a specific number that you have to do something with, but it's more as a direction like I showed you before, with the different plots of the different examples. Also, we tend to be overconfident. We tend to say, okay, we know everything, we have a lot of evidence, everyone told us this and whatever. We need to make sure that we are not overestimating this and overconfident about this. Be more conservative about your evaluation over here that will help you see the risk in better ways. Now I wanted to give you another example of a full plotted one and see where they might have— or a successful company, actually one that still exists. And this is Zoom. We all know Zoom. It's a cloud video communication SaaS platform for anyone here that doesn't know them. And I plotted the, um, the radar both for pre-COVID and post-COVID. So what I've done here is pre-COVID, they were mainly, uh, their clients were mainly B2B clients. If you never heard about them before COVID uh, was probably because your company or one of the companies you worked with didn't use it. I don't remember, I used it because one of my clients was um, using them. So I use Zoom, but I also use some other systems, um, and, um, some other video conferencing. Um, and then they had some high risk in the competition with similar products. So, uh, you know, the uniqueness there, it was there, but there were other products that were very similar to them. So it was higher risk on um, you know, what is, uh, um, not high risk, sorry, uh, there was some risk over there closer to like, are people going to promote them or tell them to other people? And, um, they had, you know, quite a bit of clients, so they're quite healthy overall. Uh, they were not a standard yet. I cannot say they were standard. If we look at post-COVID, their— the, the number of people that promoted them during COVID and told people about it and, and actually, um, um, it created the, the market for them, I would say. Um, it, it grew them, uh, um, a lot. And, and part of it was also that the, uh, pain was much bigger at the time because We all moved to work from home and we needed something like that. So there's a bigger pain to resolve over there, and therefore it was also a bigger remedy at the time. And there was a lot of new consumers, users, clients, so many B2C clients that use them. And it even became almost like, I would say, a standard these days because people will use Zoom as like verb. Let's Zoom. Even if they're not using Zoom, I've heard and I've used it myself many times before. So they are even healthier on the risk than they used to be. Now, so I asked you on the polls who owns the product discovery, and we got lots of answers over there. But in general, if you are familiar with the Product Team Triad, Product team is basically the team who are building the product. And usually there are 3, 3 roles on this team. The roles are a product or product manager, design or designers, and engineering. So different developers and QAs and whoever build, you know, developed the product. And they work together in a team in a collaborative way to, to to build it. So if we are looking at the radar, we will see that product is actually responsible for the value and for the viability. Design are responsible for the usability, and engineering are responsible for the feasibility, because these are, these are the areas that they're expert at. The designers will be expert at what, what does it mean for the users to use a specific product, what interfaces they have, what psychological issues or state of mind, better words there, they will have. They will know the design, how to do a user experience that will work for the users, make it easy for them. The engineers, they will know, you know, all the different technology that is available out there. They will be in the best position to actually go and understand the technology available technology to do prototypes, the technology to build lean, uh, technology that is emerging or standard, and etc., etc. And then the product is more on the business end of things, of the problem— what is the value to the users and what is the viability to the organization. Now, uh, many of you wrote CEO in as an answer to many of those, and it does happen that the CEO takes that ownership very early stages when you don't have, you know, all of those roles on your team. So if your CEO is also the engineer, they will also take care of the feasibility. In many, many cases, in early stages of organizations, if you don't hire a product manager, the CEO will definitely do a lot of this work over here, the value and viability. But it is something that over time will be too much on their plate to actually do. And usually we'll start hiring product people that will take care of these things. But in general, you could have different people wearing different hats, or you can have multiple people that are doing this. So you will, in a product team, you might have several design engineers, one product manager, and one designer, and they all work collaborative to see what are the risks that they have right now, what is the highest risk, how does it align with our product vision and company vision and strategy, and then what are the different discovery methods that they have to apply in order to reduce this risk. And this is about it. So first of all, thank you so much for being here and giving me the time to share all of this with you. I have a QR code for you here that you can scan and download that playbook. So in the playbook, we do have the description of each one of the coordinates of the radar and the spokes and how to plot it exactly. So it's very detailed in there with really leading questions for you to lead you through the process, as well as this, you know, for each one of discoveries, the means to do discoveries for each one of those, to reduce each one of those risks. Feel free to connect with us at rootcaution.com. Also on LinkedIn. Feel free to connect with me directly as well on LinkedIn. And we also have our podcast. So if you are actually interested, not just to watch the podcast, but also to be on the podcast, let me know. I'm always looking for guests. And we'll take it now to question and answers.

Awesome, thanks. It's been— yeah, we have a few minutes left. I know everyone has to hop off in a bit. We'll leave the networking portion open, but yeah, Moshe, thank you so much. I think that was a lot of great content. A lot of people are asking me about the deck and the recording. Yes, we're going to be sending it out. I also— I'll re-put it up again here just so people see it, but this is the link. That Morsha was talking about. Go download the playbooks and everything. Let's kind of do maybe 2 questions and then we'll break out for networking. I don't know how long people can stay for. We had about close to 170 people live. We're down to about 118. So let's kind of do— I'm gonna go to the top 2 most upvoted questions. So I'll put it up. Omar is asking, how can I make sure the problem I choose to discover the solution is worth solving in the radar? Example, TikTok and Instagram are now solving the problem of HD videos features, which was already solved by Quibi, but it was not the right time. So I guess maybe you want to elaborate a little bit more on timing and how that's important to the discovery process.

Yeah, yeah, timing is actually really important. And that's where you look into these emerging technologies and into how much people are willing to spend the time on something new. Because, uh, if you're familiar with the curve of adoption, early adopters is always low, but there are always going to be people like that that are early adopters. Uh, in order to be sustainable and to grow your company, you need the, um, the, the big majority of people that will not be early adopters. They do need the technology. Now, even with TikTok and Instagram, I don't know if they are actually spending, um, their, uh, efforts. Now I'm not familiar with, with what you mentioned, so I don't know if they spending it on, um, high-quality movie-like videos or on, uh, content that the content creators are, are putting in. Um, so with Quibi, it was really high content that cost them a lot of money to create, and that was one of the issues, that it wasn't even that it was early for its time, people just didn't care about it because they were happy enough to see low-quality content that was created by people like them rather than by studios in Hollywood.

Yeah, I remember that story. I think it's a good playbook. It's a good lesson for everyone. Another really good one was, obviously, if you're based in Toronto or Canada, is when Rogers did ShowMe and Bell TV did CraveTV. I remember meeting someone PMs at ShowMe, and they shut that down within like 8 months because they couldn't figure it out. And Bell did a whole other playbook where they're like, hey, let's just like not create our own content, we'll do one or two, but let's just tap into these other networks and just have the rights and bring them.

Right.

So it's always interesting, very brief time in 2016 where this happened.

Yeah, that's a great example because Crave did bring HBO Max to Canada. They have all of their content. So that was a great content there that people wanted and HBO did not bring. So the partnership over there was better than just trying to create your own.

Yeah, ShowMe was just trying to do all net new content and stuff and all that.

Yeah.

Okay, let's do— my favorite part of these webinars are the Q&As actually, but they're always at the end.

All right, Jacob, I went a lot over the the time that I was supposed to do. It's all right.

Whoever wants to stick around, everyone's gonna get the recording, and then whoever can stick around for networking, great. So Jacob is asking, many of us face time constraints during early stage, during the first being first to market. How can the playbook strategies be implemented efficiently for smaller teams? I think this is a good question. So how do you dumb down the playbooks and the frameworks for an early stage founder that's trying to become potentially a more market leader?

Yeah, so this really goes down to understanding if the highest value that you're trying to create in this early stage thing, and you want to get to market, you know, what is the quickest way to find the value for this highest thing? So the first thing is to identify this one thing, really one thing, that you're trying to create value with. So that's, that's what MVP is really for. So forget about all the you know, bell and whistles around it. Um, just get as, as fast as possible to this higher risk item that— of the higher value that you're trying to, to, to get, and, and get it to the market as soon as possible. Because only then you will be able to, um, understand if people actually see it the way you see it, that there is, uh, that I need to be first to market and there is no way around it. And that's why, you know, nailing down the MVP is sometimes really, really hard because we take time or we are small and we say, oh, we did this and we did that, or we need to build a whole product where you sometimes don't need to build the whole product. You need to experiment. You need to create experiments.

Got it. Thanks so much. I'm going to do this question from Dennis and then we'll wrap up. So Dennis from Uganda is asking, what's the difference between medicine and vitamin problems?

Yeah, so medicine is, um, if you have someone that is, um, I would say one is preventative and one is, um, you know, fixing the problem after the problem already happened. So if you have someone that is sick and is going to the hospital, you need to have a painkiller, you need to have a medicine that will actually will heal them. Vitamin is more a preventative thing, and many people, consumers, will not even know that they need a preventative thing, or they will not have the mindset, or they will not care about it. They will say, okay, when we get to the bridge, we'll, we'll, we'll solve it. Now, you could, you could focus your problem differently. If you focus your problem on the consumers, then maybe vitamin is, it is, because not everyone will have the mindset to prevent it. But if you, um, so, uh, focus your problem on, let's say, a government where the government will say, we want to have preventative measures so we save money on people that in the future will go to the hospitals because they are sick, um, they will be able to see that the problem is much bigger than just preventative of you know, health of individuals, but it's more like how much money can we save by making these preventative measures. So sometimes even vitamin problem or, um, you know, medicine problem, if you look at who has the problem, you might be able to find even a bigger problem there and direct your products towards that.

Okay, awesome. Thanks so much, uh, Moshe. Um, let's wrap up right now. I think this has been super insightful, super helpful. I think for any early-stage founder, going through the discovery process is always a challenge. I don't think a lot of people are even doing that. So, you know, I'm very appreciative of your time and you going through that in such great detail, then offering additional playbooks. You can see in the comments and with all the emojis, the heart emoji, the clap emoji, people love the content. Everyone go follow Moshe on LinkedIn, he's a really good presenter, his content is great on the podcast. I think this is like the 5th time I've seen him speak at one of these online events, he's a really good presenter, so yeah, like, you know, Moshe, thank you so much for taking the time. What we'll do now is we'll break up for the networking. I'm gonna click end session here right now, and then what we'll see is we'll see you'll see a bunch of tables. Moshe will have a table. Hopefully, Moshe, you can stick around for a bit and join yours. And everyone else, we still have about 100 people live. You folks can join any of the tables, get to talk to each other, you know, for 10, 15 minutes, and then we can wrap up. But this concludes our live session. Moshe, thank you so much, and thank you for everyone for joining from different parts of the world.

Thank you very much, I appreciate it.

Perfect, thank you everyone.

Bye.