Validation for corporate accelerators - Board of Innovation

Hi, I'm Taryn from Board of Innovation and welcome to the webinar on validation during corporate accelerator programs. In a previous webinar on corporate accelerators, you learned the why? Why do we actually do this? How to scope out the key questions and then the operational part, how to actually set it up? What are the governance and roles that are involved in this webinar? What you'll find out more about is actually what this means. What are the key activities that help you to validate your business ideas during a corporate accelerator program? And finally, you'll also get some best practices and tips from our team to yours. And as always, you can find out a lot more online on our website to look at how you actually use a corporate accelerator to validate your business ideas. So what does this mean? What is a corporate accelerator? Well, an innovation accelerator is a program to develop, test and grow new business ideas within a few months or a few weeks outside of typical organizational processes and deliverables. What does this actually mean? Well, how do you know if a corporate accelerator is actually right for you to start? These are some of the key questions that we receive. We have some ideas challenges we'd like to work on, but we have no idea how to actually act on them. Another starting point could be we have a strategic objective to bring this many projects to market by a certain date. How do we actually take those ideas and get them to market? And finally, sometimes we also receive the request we want to address these specific market trends to stay ahead or keep our competitive advantage. What should we actually do about that? And this is where a corporate accelerator comes in. This is where it could really fit your needs and benefit your business ideas and take them forward through a guided journey. The accelerator program will not press promise you a magical solution, but what it can do is help you gather the right evidence in order to make these crucial decisions. You will be able to decide should we launch, should we pilot this solution, should we scale it, should we actually iterate? Should we go back and check a couple of things one more time? Should we pivot? So this is going on a good track, but we should make a couple of changes or should we completely kill this project? An accelerator program will help you validate those key elements to help you make the right decisions about your business ideas. So when we look at the accelerated journey format, which you may remember, we actually start with scoping. So scoping out, what is the challenge? What is your actual starting point, and what is your idea that you want to take forward? The next step is problem exploration. So this is the part where you really want to go from a user's perspective and validate if this problem is a problem worth solving for your end customers and for your users. Once you've decided upon that, you can then go into solution development. How do we develop the right solution to meet the right needs? Not necessarily how do we build the right solution, but how can we decide if our solution resonates with the needs of our customers that were expressed to during problem exploration, we then move on to business model definition. So can we identify a sustainable way to deliver value or create value from our business idea? And then finally, once you have brought together all these elements, you can then pitch and form a credible pitch that really takes into account all the evidence that you have gathered along the way. One key part throughout this whole process is validation. Validation of desirability, such as your customer actually want this and viability, will it create enough value for the business to actually sustain this project? If we want to zoom in on just the validation aspect of a corporate accelerator, we're then looking at problem exploration, solution development, and business model definition. In those three phases, you will then be able to validate and test your most crucial assumptions to see if this is a problem worth solving, if this is a solution worth developing, and a business model worth launching. And depending on the stage of that innovation funnel that you're in, you'll need to validate completely different elements of your business idea. So what is validation actually? Validation is the process of gathering evidence as well as learnings around those business ideas through experimentation as well as user testing. In this way, we can be able to make foster more informed and de risked decisions. So what does this actually look like? In reality, it gets pretty messy, but if we simplify it, it comes down to three main things. We use validation in order to make sure that we have validated our problem assumptions. Is this a problem worth solving? Validate our solution assumptions and those key hypotheses. Is this really worth building? And finally, a validated business model and the assumptions that are associated with that. So is this really worth launching? So when you start out, step one in the validation process is really to say, okay, depending on what stage we're in, what do we want to learn? What are the key assumptions that we want to take a look at? And what can we then use for evidence that we can take a decision later? So step one, identify what do you want to learn? What are your crucial assumptions? Step two, here we're looking at choosing and designing relevant experiments that actually help you test out those assumptions that you identified in step one. So whenever you're deciding, which experiment should I choose, what should my experiment design look like? Always ask yourself this one question. Does it actually test your assumption? The final step is actually then interpreting all the results, all the evidence that you gathered through experimentation, and then making a key decision. What should you do next? What is your decision? And don't be afraid to make those difficult decisions, because they're now backed up with clear evidence from testing. For example, some decisions are made every day. If we take a look at Killed by Google, you'll see that there are various projects, business ideas that Google has launched and subsequently killed or even killed before launch. This is the process of validation, being able to make these really tough decisions. Because at the end of the day, life is too short to build something that nobody wants. So let's dive into it. Validation. What are those key phases? What's involved? What does this mean for me? If you start with problem validation, so really being able to test your assumptions that surround your user, Some typical questions that we get, some typical starting points are, which problems? Which customer segments? Where should I start? What should I focus on? So if we start with desirability, do they actually want this? We look at which problems do they currently face? How much do they really care about this problem? What are their current alternatives, if any? And this should give you an indication of how large that problem is and if it's something that's really worth your time and effort in solving. Another question could be, which segments in particular face these problems? How frequently do these problems actually occur for them? So also give you an indication of how significant a problem may be? And then finally, viability, Viability looks into as well, which problems do they face, but from a different perspective. Now you're saying which problems do these users face and how valuable are these problems? So not how frustrating or how really how much do they care, but how valuable is this a problem to these users? And if you look at which user segments face these problems, another question that you can ask here is how large is that segment? So what is my potential here for capturing value? And then finally, how will these problems evolve in the future? Something that could be a really big problem now might develop in such a way that it may be irrelevant in the future. Make sure to keep this in the back of your mind so that you're not solving problems that may eventually fade out a year or two from now. So looking at problem validation step by step, the first part, if you can remember, is defining what you want to learn. So you're in the problem validation stage, and here you want to learn what customers really want, not what you think that they might want. This leads us to customer empathy research, which is a really crucial part of problem exploration here. It's a collection of activities that seek insight into user behaviors, their goals, and their needs. The end goal, of course, is resolving these issues through the design of products and services. What is typically involved in this stage? Well, empathy is really recognizing the emotions of others, being able to put yourself in their shoes, and understanding their perspective and their reality. So our approach within a corporate accelerator program is then to say, what do you want to understand? Understanding really the why behind those users needs, collecting stories around that, and then finally validating your assumptions about their point of view and validating your assumptions about their unmet needs. Some tools that we use at Board of Innovation throughout the validation portion are of an accelerated journey include Persona, customer journey mapping, fragment cards, assumption mapping to then uncover all your hidden assumptions about their situation, and then finally going for validated learning. So actually testing them and being able to gather those learnings. So, for example, if you start with the question, do people really have this problem? Your assumption would then become customer segment X has this problem when they are in this particular scenario. So really taking it from a question that you have to saying, this is our stance, this is what we assume. We assume that this is what they will behave like. We assume that this is their reality. And that's something that you can actually test. You can't really test a question, but you can test an assumption. So, for example, I will take you through this male fertility test on Wired. It was listed as one of the top products in the how do we reproduce section. And it's called the Daddy Kit. The Daddy Kit is available for $99 and it is a home diagnostics kit. So according to the Department of Health and Human Services, about one third of all infertility problems have a root cause with male factors. So that is already some desk research, some stats that tell you the size of that problem, more or less. But then it says the testing and storing of sperm usually involves some really awkward moments in an institutional room with a couple of old magazines. So really getting into the problem or the unmet need or that uncomfortable part. Yes, the issue or the frustration with traditional methods. So here the question would then become, do people really have this problem of awkwardness during sperm testing? Your assumption might then become, well, married men over 40. So already narrowing down on a target segment, and why do I choose married men? Over 40. Well, more research. So some of your assumptions can be based on existing research. So. So it appears that married men 40 and over have a decreased sperm count compared to men aged 20 to 29. They are also more likely to pass on birth defects, neurocognitive disorders, and increase the risk of miscarriage. So now we've narrowed it down and said, well, we assume that married men over 40 who get tested will find it awkward to provide sperm samples. And in an institutional room, that is then our assumption. We can test this assumption. And that's why you have to choose the right experiment to actually then test that assumption. Different ways of actually validating problem assumptions, looking at testing, there are plenty, but let's dive into just a couple. So one of the most common is actually interviews, where you actually engage with potential customers or users, and that will experience that problem. That is not to say that you're interviewing or interrogating them, but more so a conversation. You're looking for stories, you're really looking for their why, their motivation and their behavior. So here you're going to kind of ask and listen. Another method is observation. So really being able to just watch. Often people are really bad predictors of their own behavior. So observation could be a really powerful tool to just watch something in context, behavioral patterns, body language, emotions. And finally, you could actually immerse yourself. So really kind of participate and really feel the problem firsthand from your own perspective. The key thing here is that we're not saying let's do away with market research. That is really important, but it's really important when you want to narrow down on a problem, when you're still exploring a problem. What we want to go for is insights research where you speak to fewer people, but you really get a lot more stories. You get over 100 insights into the what and the why, their behavior, their needs, and a little bit deeper into their intrinsic motivations. Because at the end of the day, we aren't our users without research. We're actually designing for ourselves. So if we go back to the example of the Daddy Kit, one question might be, do people really have this problem of awkwardness during sperm testing? Our assumption was that married men over 40 who get tested find it really awkward to provide sperm samples in an institutional room. What kind of tests could we actually run to then check our assumption? Well, the one is an interview. So you could actually interview some men and say, when was the last time that you had to give a sample? It doesn't have to be sperm. It could be something else. How did you feel what was uncomfortable, what was awkward? And actually don't even lead them, just get them to tell you a story of the last time and likely they will bring up their actual feelings about the situation. Another way is to observe. So what you could do is sit in a doctor's room for the day, with permission of course, and just watch how people feel when they come in and when they go out. And finally you could immerse yourself in the situation. If you happen to be in that target group, you could take the experience and do it yourself to actually feel firsthand what that might be like. And finally, when you've explored the problem and you really want to narrow down to see how many people actually experience this particular problem in this target group that I'm looking at, then you can launch a survey. The survey will give you the numbers to validate the problem that you have identified. The final step in the validation loop is then interpreting the results. Here you want to make an evidence based decision. So you're asking yourself, have we validated our crucial problem assumptions? Is it a problem that is worth solving for our customer and what decisions should we make? Some typical pitfalls or some typical kind of cautions that we have here that we've seen with multiple teams is you really want to empathize with people and that's great, but make sure that you also target really relevant profiles. So as your problem exploration journey evolves, you want to make sure that you're interviewing very key people that actually fit in with your target group to make sure of the quality, your insights. Secondly, a curious mindset and the willingness to explore are great, but you really also have to keep your focus. So make sure that there is a point at which you're stopping diverging and you're starting to converge around a key problem. And then finally, you really want to listen actively to users and don't jump too fast into forming conclusions. In terms of solution validation, once you've decided the is a problem worth solving, we really want to not ask, okay, great, so what solution do we build? No, instead you really want to ask, okay, great, what do we want to learn next about our solution that will help us design the most relevant offering for our users? So some typical questions that we get here is, will our solution offering actually resonate with our target customers? Is that worth building? And in terms of desirability, we look at, does our solution meet their needs? Are we solving their needs in the best way? Does our value proposition actually appeal to our users? How will the users respond to this offer. So those are kind of key questions about the actual idea itself. When you look at viability, you really want to know if they see value in your solution. How many users do we have the potential of reaching with this solution? And do they actually, how do they perceive the value of what you are creating? So in this stage, you really want to maximize the learnings by minimizing the time it takes to test things. If we go once again, step by step, you start with identifying what you want to learn, what are those key assumptions and what's involved. So you want to ideate on potential solutions. You're going to be developing concepts, you're going to then select the concepts that are the most relevant, and then you're going to want to check does this resonate? And only 1% is actually creating the idea, the rest is actually testing it, executing it. So from board of Innovation side, our approach during an accelerator program, the validation of this would then include what do you want to understand? Really going into the behavior towards your solution and then saying, can we validate our assumptions about our solution? And then there are some tools that will help you along the way. And I think the most crucial here is actually then after assumption mapping, using the experiment card to be able to design an experiment that will help you to validate those learnings. Another key thing to mention is that one is that assumption, which is that inherent idea that you have of what it is like in reality. So it's a statement that you believe to be true. I would also like you to think about a hypothesis. So as we start leveling up our experiments, you then are open to creating a hypothesis, which is a prediction that you can test. How do you predict users will respond to your solution? And then you can test that prediction. So, for example, if we return to our lovely dad kit, so what they came up with is this kind of diagnostic test in a box that they can send to you at home. So that's great. It really kind of alleviates the one unmet need of the awkwardness in the doctor's office, among other unmet needs, but it also opens the space for new assumptions. And one assumption could be, do people worry about their sperm being sent to off site via mail? So maybe you've solved the problem of it's less awkward because you're in your home, but now they have to send it off site. So are they actually worried about that? Are they uncomfortable about that? So your assumption would be, men will trust our kit to preserve and protect their deposit throughout the shipping process. It could be as simple as that. And the kind of test you could run again is an interview. You could observe them. You could even run a smoke test, which is designing a fake landing page before your service or product even exists and testing their reaction to it. Another way you could test this is actually by concierge. So if they're worried about sending their sperm via mail to the lab, what you could do is kind of fake that service already by collecting it yourself, taking it to your own lab yourself. But you're first just testing the interest and testing that assumption. So if we take a look at the landing page that they have set up, one thing I want to bring to your attention is turning the assumption to a hypothesis. Your hypothesis then might become, well, we predict that 40% of men who view our webpage in a two week period will actually take the decision and click the get started button. That means that they're actually interested in your value proposition, they trust the information that you've provided and they're willing to take that leap. So that's a first start in really understanding the experiment that can help you test your, your crucial assumptions which you have turned into a hypothesis. It's really key when you are looking at the different experiments that you could possibly run, is focusing on a minimum viable product, so not building out your full solution, but really kind of taking it step by step and only building as much as it takes with just enough features to satisfy the early customers that will help you get the right feedback for further development. So you're just building the core features that will help you to realize your value proposition and help you to actually test your assumptions. You're not building the full scale solution. From Board of Innovation, we have some validation tools that can help you actually choose the right experiment. It's called the Experiment Picker and that you can find online. And then you can actually say, okay, so maybe when I start out, my MVP will look at qualitative data and I'll really try to speak to people, find out how they interact and as time grows I can actually look at some more quantitative data, so get the numbers behind it and actually then increase the fidelity of my type of prototype that I'm using in order to learn. So these are some tools that you can keep in mind of actually how to go about solution testing. So the question you want to ask yourself here is, does it actually test your assumption? And then finally, when you want to interpret all of these results, when you want to make that evidence based decision once again, you really want to say, have we validated our crucial assumptions before we can actually move on. Is it a solution that is worth building? Does the evidence point to that for our customer? And what decision will we make? Will we continue? Will we pivot and change something? Will we say, okay, at this point, there is no significant interest. We should kill the project? What is the decision that you're going to take? Some really common pitfalls here, and I really want to stress that it's something that you should be mindful of, is really be specific in testing. Avoid testing too many assumptions in one experiment. You really want to be able to understand correlations and causations. So you don't want to test too many things with one experiment. You want it to be very clear the outcome and what that actually means. Then embrace time constraints. Don't run experiments for as long as they take to show results. That is a no. No. You really want to time box your experiments to be able to decide, okay, what if I learned? And make sure that you're limiting the amount of variables. So, so we're not running something for two days. We're not also running something for one month or three weeks. What we could do is run something in two week periods. That's the kind of typical industry standard. You leave something running for two weeks and it kind of eliminates the inherent biases that might occur with leaving it for too long or leaving it for too short. And then finally, you really want to invest time in setting good metrics. So declare your expected outcomes up front. A good metric really needs to help you take a decision. A good metric should have a ratio. A good metric should be comparable. There should be a benchmark. It should include your prediction. Because in this sphere, we're really good at kind of post rationalizing something. And then you have this hindsight bias. Oh, this is what the results are showing. So it is probably a success. Make sure that you set your success metrics up before you actually design your experiments and make sure that they are in place, that you're declaring your expected results up front. Because at the end of the day, if you plan on just seeing what happens, you will always succeed at just, well, seeing what happens. Because something is guaranteed to happen. Just be upfront about it and what you expect so that you can take a good decision. Finally, we want to go over business model validation. So does it create, capture and deliver value? It's the last part of your validation journey. And here we want to ask, will customers be willing to pay for our solution? What is their perceived value? Is there enough interest to sustain our growth? And then from a viability side, what is the potential value that is captured from our solution? How will we price our solution? And can we get some clear numbers about the frequency of purchase or use? So these are typical questions that people seek to answer during business model validation. And at this point you really again want to go through that leap and say, what do you want to focus on? So here saying, is it not just a solution that people love, but can we create a sustainable business around that? We want to say, what do you actually seek to understand? Can you visualize your business model and be able to kill it on paper before it's too late? And then the tools that you can use to help you throughout this journey beyond the business model canvas is the business model kit revenue flowcharts. Again, assumption mapping, ballpark figures. And this is just one example of a visualization that we've done with the business model kits and some assumptions that we can immediately see. So these start off as questions which we can then turn into assumptions about the way our value exchanges are structured. You then want to choose an experiment. So for DaddyKits, what they did is, okay, people are prepared to pay for the service, but are they actually prepared to pay for sperm storage as well? Proactively. So the assumption could be, yes, men are willing to pay for this in addition to the charge of the diagnostics kit. So one could be an interview to test this or a split test where you show different pricing models and you test people's reaction to that. So your hypothesis would be, if presented with a choice, 60% of men who click to buy well choose the monthly option. So if we look at this home diagnostics kit, it's $99. But then they say your storage plan, you can choose from $9 or $99 for the full year. Again, if you take a classic example, Netflix, they have three different pricing models. They can really see what resonates with users more often. And then they can refine that pricing model and, and change different solution packages to what people respond to and how people perceive the value of those packages. And then finally, you want to make sense of all of the evidence to be able to take a good decision. Some common pitfalls here. You really want to understand who you will compete with. You really need to be honest with yourself when it's time to kill it. If your business model does not make sense and find the time to pivot, allowing changes for a better solution. But this is only the tip of the iceberg. If you want to dive into more about business model validation, go check out the webinar by my colleague Kinan. To wrap up, there's the Accelerator Journey format. So scoping problem exploration, solution development, business model definition and your pitch design. You're going to use validation throughout that we have validation tools and offer that you can find available on our website. And we will also equip you with an accelerator playbook that will take you from step A to step Z. As always, you can find out more details online. Thank you so much. And if you're interested in finding out more, let's connect. See you next time.