Ask me Anything about Testing Business Ideas - Alex Osterwalder and David J. Bland

Okay, let's get started with our little informal session. So welcome to everybody for joining. So David Bland and myself will host this informal session. Ask us anything about testing business ideas. You know, just you can shoot ahead. And this is if you want, sponsored by the masterclass that we are going to run in September. And if you're interested in that, if you thought we gave some good answers, some smart answers and you learned something, please join us at the masterclass which is taking place September 15th to 17th, three half days online. And we'll go very deep there and in a more structured way than today, of course, with all of this content on testing business ideas. David, anything else you would want to mention regarding the masterclass that I didn't. You didn't say yet?

We're just really excited. So I circled the webinar code for everybody. Basically we're going to be going through a lot of really hands on interactive things. So I think that's something that still people, I don't know if they've come to realize yet. It's not sit back and relax and have people talk at you. It's like putting you to work. So just be prepared to do a lot of work exercises. We're probably not going to talk for more than 10 minutes at a time. So it's a lot of hands on interactive stuff. So I mean we put a lot of hard work into it. So just be prepared to work if you come and show up.

Yeah, so today will be a little bit unrepresentative regarding format. Today is just free flowing. You won't have to work that much. Just listen. But at the masterclass for sure you're going to, at the end of the day be exhausted because we're going to go fast and through a lot of stuff and get you to work. Right. Not just to listen, but actually work on the strategizer workspaces. Let's kick it off. We got a couple of great questions from all of you guys. I think we had, we had, you know, a really, really, really big number of questions. There were over 100 or so, but we selected a few. So David, I'll let you kick it off. Which one would you like us to start with?

Yeah, I thought, you know, there's all these methodology questions we got and I thought maybe just to ground us before we jump in is just to kind of sketch out the overall kind of process because I think some people are still confused about overall what it looks like. And so I'll just do this really quick and then we can Jump in. But there are a lot of questions around hypotheses and experiments and connections and segments. And I just really quickly wanted, because this is something that Alex and myself and Alan actually created for the book Testing Business Ideas. And so when you start off, you know, you have some questions about your market and your opportunity, and it's like, how do you go and make a decision? All right. And so there's kind of two sides of this equation. There's the business design side, and then there's a testing side. And on the business design side, you want to ideate, you want to create a prototype, you want to assess what your options are, and then kind of decide on where to play. And so there is some work to be done there. You know, obviously, we do a lot of canvas work there, both like BMC and bpc. Right. Then where's your risk? Let's make some hypotheses about where our risky assumptions are. Let's run an experiment, let's learn from that, and then let's go in and make a decision that maybe actually informs our strategy on the business design side. Going through this loop over and over and over and over and finally getting to a point where, oh, yes, now we want to scale. And I just felt like it's nuanced. But, Alex, I wasn't sure if you had anything to contribute here. I mean, you helped create this design, but basically, overall, there's a structure here where you have to balance the business design side and you also have to test. And obviously, we're going to work a lot on the testing in the masterclass, but you need both.

Yeah, we got a lot of feedback on people like this, but there are also people saying, well, why do you guys have to redraw a thing? But what we do at strategizers look at what's there and then ask ourselves, is that good enough? And what we've seen is there's great foundations, and we obviously, all of this is built on the shoulders of giants. But we felt like we need to have a simpler, very clear process that covers both sides. Business design, shaping your ideas and the testing. And this is the simplest process and visual that we could come up with that really would cover both sides. And as David just said today, we're not going to go much in business. Design was actually one of the undervalued areas. Right. How do you compete on business models, not just products and services? So there we can spend a lot of time. But then what we also felt is testing is not good enough yet. Can we Professionalize a little bit more. So we build on top of what exists, but we try to make it almost bring it to the next level. Let's graduate, you know, to a university degree or a PhD. And that's what we're going to talk about at the masterclass. We'll look at some of this today. I'll actually ask you, David, maybe let's kick it off with. So the first part, their hypothesis. Somebody was asking two good questions, right? So Timohan from Germany was asking how to phrase a strong hypothesis. But let's take that one second because I'd like to go with the first one. You know, how do we actually prioritize hypothesis? Because we still see, and I'm curious what you see, David. Still a lot of teams, they don't even think hypothesis, they don't break their big ideas or products down into hypothesis and then they don't prioritize, they just go, oh, we're going to go and test, we're going to build something. Right. But the hypothesis phase is crucial. So this question, techniques to prioritize assumptions from Neron, our friend Neron in Thailand, incredibly important. And then I'll have a follow up questions once we went through the kind of prioritization. But I think that that's the heart, right? And I'm curious, David, do you still see people who don't do hypothesis first but go immediately out and test?

Yeah, happens a lot because people get excited about testing and we get a lot of kind of, wouldn't it be cool if we did this and this and this? And it's one of the things even I found myself falling into early on when I was coaching teams, which was I want them to be excited about testing, but your test has to actually de risk your strategy, right? So you have to be very careful about this. Because if you just run experiments just for the sake of doing them without doing the hard work beforehand, you'll get the illusion of progress because you're running experiments and completing them. But as we all know, it's more of just an output metric that's not an outcome or an impact. And so being able to do the hard work of okay, where's our risk first is very, very important. Otherwise you look busy, right? The team looks busy, they feel good. They feel like, oh, we're talking to customers and we're doing all these things. But if it's not tied back to your risk, it's kind of like innovation theater. So with the mapping that we put in the book and that we've Been working on for quite some time. What we see as a prioritization is a very, very simple two by two where you first you write down your assumptions and then when you map them, they end up in different places as far as importance and evidence. So for example, importance in this regard is important to success of the business, the success of the endeavor. And so what has to be true for it to succeed and then evidence. And Alex, you and I went around when we were writing this book which was, wow, you know, we get these high. And this is another question we had about like strong opinions, right? We get these really passionate people in the room, right? And they want to be right. And they've actually their whole career has been based on being right. And that's why they're in the position they're in, right? And so, you know, they want to say, oh, I know this is good, we know this is true. And then we'd ask these questions like, do you have evidence? Like, well, no, I just feel it's a gut feeling. I'm like, okay, do we have any observable evidence that it's true and quantitative or qualitative? And that actually when we first started doing this, with this axis of have evidence and no evidence, we started getting to the root of the problem of, oh, well, if we don't have evidence, then we should probably go find out versus just having people convince others in the room that it's true when it's not really based in reality at all. So that was a really learning moment for me, Alex, like working with you, it's just, wow, we have to get to evidence and we have to have everything rooted in evidence. Otherwise we just kind of convince ourselves we know the answers.

And for me, I remember the first time using this with Colgate, Palmoleff. Right? Because I used to use just important and unimportant and not really go deep into have evidence, no evidence. I was just assuming we're just going to have assumptions there where we don't have evidence. But then when you I started looking at your assumptions mapping, we collaborated and we came improved a little bit. I think for me this was a real breakthrough. But I had to use it to understand the strength of it because people tend to put too many things up on the left corner because they, as you said, they have a gut feeling or they had two or three interactions. But when we say have evidence, it means you've done really substantial stuff. You didn't just talk to five customers, you talked to 50. It depends, of course, on the industry in Pharma, you might only have one customer, which is the government. But one of the things here, if we get back to what you also just mentioned, the strong opinions. So Niran was asking, well, how do I deal with that? So let's say you have somebody maybe in a management position with a strong opinion putting up a sticky note up on the left corner, have evidence, and it's important, but clearly it's not the case that they have evidence. How do you deal with that?

Yeah, and it's really interesting to me. I find it happens more when we're not doing this facilitation. So it's easier for them to do that when there's no. They're not writing it down, they're not visibly placing it somewhere. And so I really rarely had the occurrence where somebody didn't back down and they said, oh, no, I just know. And then we say, well, how do you know? And it's like, well, I just know. It's really like as a leader, they can't necessarily, like they'll start to lose credibility in front of their team. So I haven't really had a situation where, you know, a really opinionated leader put a sticky up and wasn't willing to move it. Because we do this in a group setting. We do this in a context of desirability, viability and feasibility and also, you know, adaptability even. And I really haven't. I know it's a fear that people have, but in all my teams I haven't had situations where, you know, an executive just wouldn't budge because it's so relative. It's like it's really tough for them not to back down. I'm not saying it can't happen, but I just, I rarely do see this happen when we're doing the exercise.

And I think that comes from the fact that when you talk to somebody without the visual tool, it happens. But as soon as you have that visual tool and you have the scale, have evidence, have no evidence, it's practically impossible to kind of back out. Right. Because if you don't have. And in particular, we say what evidence is, right. We talk to customers, we have sales, we have this and that. It's impossible to put up the sticky note and not have the evidence because as you said, you lose credibility. Right. So leaders will not want to lose face. So putting up a visual tool is more powerful than one thinks. And one additional aspect, just having this up here, what was really interesting in that project that the Colgate one we collaborated on. Right. Fortunately, we can't talk about the content, but the context is pretty interesting because I was facilitating the ideation session where we ended up with the hypothesis up on this. You were not there. Right. I was physically in New York. You couldn't make it. But then I handed over the hypothesis to you and it was actually pretty easy for you to take over. That was a really, really astonishing thing for me, that because we visualize them, because we prioritize them, it was relatively easy for you to take over.

Right, yeah. And we had been. And I personally been facilitating this with hundreds of teams over the years. I first picked it up from Jeff Gothelf and Josh Seiden, who I worked with, wrote Lean ux. And teams would try to prioritize. I mean, there's all kinds of two by twos out there, but I felt like there was something here with regards to themes. So desirability, viability and feasibility. Right. So having different colors does help you kind of key in, like, what kind of risk do you have? You know, is it something like, can we do this or is it more? Should we or is it more? Do they kind of question. So that little kind of tweak to the exercise does help you visualize what kind of risk you have. And ideally, Right. We don't have people that are putting a bunch of feasibility risk right away saying, can we do this? When you haven't talked to any customers whatsoever, so that helps. And then those. The axes that have evidence, no evidence. We first started with known and unknown, and then certain and uncertain. And it really wasn't until we got to the evidence, you know, Alex, working together, that I think we call this the clueless corner up here. Right, Exactly. Whoa. And so from there, right, when we talk about this, focusing there and basically moving over, just kind of like, you know, the full picture here of you're starting over here with your canvases and kind of moving over to mapping. So there is a couple. I mean, we're going to go through this in the masterclass, but it's extracting, writing them down, having kind of a format for that, and then pulling them over and having a conversation that flow and then from there moving over to experiment design. So it's really this, like, missing piece that I think we've been struggling with for so long of. Wow. People keep running experiments that aren't matched to their strategy. What is it? And finally we found something that worked after hundreds and hundreds of different teams.

And I think to a certain extent, the formulation build, measure, learn was misleading because people took build too literally. So they started building actually, before asking, well, what are the underlying risks? So working on these hypothesis, first, number one crucial. Because otherwise you can't test an idea. You need to break it down into smaller pieces. So, David, how do you phrase a strong hypothesis? So Timo Hahn from Germany was asking that, how do we know it's a good hypothesis? Strong hypothesis, yeah, it's very tough.

Like, we're still, even scientists still argue over this as well. We have the pleasure of working with Dundai. Right. Who also helps us out with some of this stuff. And so I think what happens is we just don't word these really well at the beginning and then it makes it very hard to test. And so I stopped screen share. If you want to draw, that's fine too, Alex. But the idea of, you know, we believe that. So writing it that way is more belief. You open up to the idea that it's a belief that you have to go prove or disprove. And it sounds kind of silly, but writing it that way matters. You know, we believe you're opening yourselves up to the fact that you might be wrong, that it's a belief. And the other thing is, you know, we keep working with, is it testable, is it precise, is it discrete? And so these are the criteria we're going to be applying in the masterclass to help people practice this and practice writing. Right. Because you can take a very kind of general statement that's hard to test. And until you apply that rigor to it, you really have a hard time designing experiments for it. And I think that's where teams get tripped up. They go, oh, I'm not really sure how to write this. And then maybe I'll run all these tests and it doesn't matter. I won't have a clear signal. And so this idea of testable, precise and discreet, I can't stress this enough. Like, during the masterclass, we're going to be breaking these down, explaining these to you in depth and having you practice on it, because you're going to have to practice doing this. It doesn't come naturally. You have to, like, train your intuition and practice writing these. Yeah.

And that is so important, right? Because, you know, when I see this, people will buy our products. Right. That is not a good hypothesis. Right. By our product here. So how could we just. Very quickly, you know, we won't go into details because we don't have enough time. Otherwise, you know, if we do everything here, which we won't be able to do in 45 minutes, because this is the masterclass three half days. But let's just take this one as an example. Right. What's wrong with this, David? People will buy our product. It sounds like, oh, that's a great hypothesis. Right. That's what we're going to go and test.

Well, first we might start with people who.

Grandmothers, people in Silicon Valley.

Yeah. And then will buy is also like, can you. Is there something specific there? With like pricing? You want to test, is there intent? Like, there's all kinds of things. And then your product, it's like, are you testing the whole product? Are you testing a piece? Like, so we really start kind of applying the criteria and breaking it down into something. We could feel like, oh, we could actually go do that and see is it a leading indicator or on the right path, because people are our product. It's like, okay, well, what do you do? You just build the whole thing and launch it and see if people buy. Like, that's how we've been doing things. It doesn't work very well. And how do we test our way through that? You have to kind of start breaking it down and being more specific.

So I deliberately took one that's so hard that you're going to lose your hair. So here's the thing, right? People, completely abstract. What does that even mean? But we see that all the time. So it's almost ridiculous how bad the hypothesis are. And you don't want to go too deep at the beginning, but at one point when you start testing it, you want to make sure you're testing very specific stuff. Right. Because if you take the whole thing, one person will test if people are interested in the feature, another person will test if people have that particular pain. This is just too big. You want to break it down at the beginning. I think that there's a lot of work still to be done on hypothesis, and there's no need to be as scientific as a scientist, but at least a little bit better so we can compare the data.

Yeah, I think a question we had is what people. What do we mean by discrete? And by discrete you can't necessarily have. It does like, we believe this and this and this and this and this. What will happen is you'll run this giant experiment with a bunch of different variables, and then you'll never really know what caused it to pass or fail. So by discrete, we're meaning, like, break it down. You know, very, very, very small things like look for conjunctions, look for the ands and ors. And you don't want to have a really long statement with a bunch of different conjunctions in it. And therefore it just. It makes it harder to test. So we recommend discrete as far as break it down. So hopefully that clarifies what discrete means.

Yeah, I just made it worse. The one we had. So. So we have a bad case. People will buy our product and use it every day. Right. So those. That's not one hypothesis. Those are two. This one's not precise, not discreet, and is not testable. So good example of a bad case. Right. And people, we could get more specific here. As we said, we take features of the product, etc. So, David, which question do you want to pick next?

Oh, there's so many good ones here. Maybe we can talk about the B2B one. So we have a question. Can you address the B2B context, which we always hear. My starting assumption is that testing might be a little more difficult, but I could be wrong. And that's from Tim in Ireland. We do a lot of work in B2B. I have to say, it's really interesting to see the shift in B2B right now because consumers and people typically expect B2B products to feel like B2C products now, which I think is really interesting in its own right. But Alex, I mean, when we talk with B2B stuff and we're going through this experimentation, I think the biggest thing is everyone just expects to be pitched and sold constantly in B2B settings. So we're constantly saying, can you facilitate something where you're not pitching them, like do a speedboat or do a buy a feature or do cart sorting, but do anything where you're not just. You break this expectation, this framing that you're coming in to sell them, because quite often you're just trying to figure out if they have a problem. And so I think it's funny when we get this B2B question over and over again, that's probably the biggest hurdle is just getting past the, oh, you're talking to me, you're trying to sell me something, just get to it.

I'd add two things. The first one is people often say, well, B2B is less accessible. I'd say the contrary. Maybe sometimes if you're a startup and you're going into an industry, you don't know, it's a little bit more difficult to get those connections. But in general, you know, we've done quite a lot of work with W.L. gore and, you know, makes Gore Tex and a lot of other things. A materials company in their case, you know that very quickly they Just could reach out to existing customers and get time with them to test ideas. I think the assumption sometimes that B2B is harder comes from the fact, again, build, measure, learn. So, you know, you know, take Gore, you know, they make cables for helicopters, so they immediately think, oh, well, you know, what are we gonna have to make a prototype? It's gonna cost us a lot of money and a million bucks, so we can even test it. This is a wrong assumption. Right. So the thing is, you probably just want to talk about jobs, pains and gains first. You want to use techniques to understand which ones are the biggest pains. That is extremely easy to do when you know about the techniques, which is probably the inspiration for our book. Right. Saying, well, people don't know enough techniques. They kind of just think about building a minimal viable product or interviews, and that's about it. Right. It's kind of the kindergarten version of Lean startup. And I think if you start to understand the whole library or possibility of experiments that you have, you'll see it's actually not harder or easier in one industry or another. Some industries are hard to test, some industries are easy. But I wouldn't say it's B2B or B2B be, you know, B2C per se. And I actually think, you know, B2C. What's often hard is you, you have so many people. You know, if you're in a market with 20 million or 50 million people, the hard part is how are you going to figure out the right pattern when you talk to 100 people or a thousand people? Right. So in B2B, it's often less customers, so it's easier to quickly see the patterns. So I wouldn't say it's, it's easier or harder in one or the other. It really depends. It depends on many different things. Most important is just find the right techniques to test the right thing at the right time.

Yeah. And I think maybe just illustrating what you're saying and what I do with some of the projects we've collaborated on, Alex has been, if you think of B and then. Right. You're going to be. But then there's probably a C there. Right. You eventually get to some kind of consumer. You know, quite often I find these companies we just take for granted that this connection between the last B and C is strong and they know what they're doing. And so quite often your whole go to market strategy and everything, it's like if you're in a supply chain, you're just kind of taking the word for it. The next person down that they are connected and know this stuff. Right? And quite often they don't. So what we've been doing with experimentation has been launching experiments like directly with the consumers and generating, you know, generating our test here, generating our evidence here. And then when we learn this stuff, we take this back to this business we're working with and going, look, we have all these insights. Were you aware of these trends? Do you understand this misalignment between jobs gains and gains? Quite often we use the evidence from the end consumer and a B2B2C to inform the B2B strategy because they're not quite as in touch. And you could look at something like, I work with consumer packaged goods companies and they go through retailers, right? But the retailers control the consumer data. And so even the, even the goods companies that are putting the thing on the shelf don't understand the customer sometimes. So they can't take the word from the retailer because they sometimes don't even share that data. So they have to go around, generate data and come back. And this is really crucial for something new because you want to be able to generate insights and evidence. And when people say, well, no, that's not how it is. You can present evidence and say, actually we have evidence to prove this. So a lot of times I thought this is really interesting technique. We go to the end and learn and then bring it back and use it to inform the strategy. So something to maybe keep in mind when you're looking at your strategy and where you focus your testing efforts. Great.

Eva is actually asking, of course I knew we were going to get called out on that when I wrote down a bad example. So much to being visual and concrete. So if I can quickly share my screen, David. So of course we were called out on not showing a good example of a hypothesis. So I quickly crafted one. So this is one that goes in the right direction. And maybe David, who has much more experience with this, is going to hammer me on this. So I wrote down purchasing managers, maybe we could Even in Fortune 200 companies, corporations have a budget of, you know, let's say $500,000 for this category of products. Would that be, in your opinion, a testable, precise and discreet hypothesis? And don't hesitate to destroy me in front of 20,000 people if you.

Well, I mean, one, it's certainly better because you're being more precise, right? So purchasing managers, you could even be more like, what type of purchasing managers? What type of Fortune 100? But this is much better. And then putting in a number for that Budget, you know, and so that's a number that you can aim for. You know, it's not just a random budget. You can actually put a number in there. And then for this, why I like this one, is it actually starts to narrow in and gives you options to run different types of experiments. So you could do, you know, you could do a speedboat with them. You could do buy a feature, you could, you could do some other types of things. And it's not so locked in that you only have one option. And I think that's the balance here that's really hard is sometimes when people write these, they're either so big that they're impossible to either prove or disprove and they're not broken down, or they're so precise that you literally design the experiment in the text. So here you could still go in and find, Use different methods to find out what the budget is. And then from there you can move on to, okay, just because they have the budget doesn't mean they're going to use it on what you have. So what else can you do to kind of get stronger strength of evidence? So this is, this is exactly, you know, I would say the only thing is we believe, but, you know.

Yep, yep, yep, yep.

But yeah, I mean, this is exactly kind of what we're trying to do.

I didn't, I didn't fail the test. That was stressful. Okay. So I changed it, you know, life. Because that will lead us to the next question. It's one we get a lot, right? You know, how do I test services? So I turned this from product into services.

So.

So I think there's this general belief that, oh, I can't test services. And I think it goes back to the build, measure, learn kind of thing. So, David, what is your experience with making experiments around services? So who was asking this question? Actually, several people. Anabel Ferreiras, Luke Smaers. How to best test or pilot service products. I would take away the word pilot because later on, let's talk about testing first. Right. So a couple of hints from your experience what you've done around services.

Yeah, there are all kinds of interesting ways there. And so anything consulting is super easy because you just literally, I mean, we even do this right, where you have a value proposition, you're testing it with customers, and then you manually concierge deliver it until you productize it. I would say some of the more interesting ones I've worked on is a cake baking service, which was really interesting. And a lot of it was not so much the product of the cakes, but the ordering. What's the service look like as far as what kind of cakes people want and what experience do they expect. And you can test those really quickly. Like we would literally test those in the store with people buying cakes, like right in the store. And this is one of the biggest retailers in the world, so there's a lot of things you can do, but you apply the same principles. Okay. So it's a lot of the same, you know, what's our riskiest assumption? How do we go test that? It's just the tests aren't, you know, your typical product test. Right. You're testing the service and you're testing the experience. And a lot of concierge, a lot of wizard of Oz, a lot of, you know, manual things, because you're trying to see out like what's the commonality here before we go and kind of make it a repeatable process. So I find the services actually aren't that hard to test, actually. Sometimes they're easier than products because you could literally just test it right away instead of with products. Sometimes you have to kind of do something as clickable and interactive and all that. But with services, I don't find this to be challenging at all.

Right. And sometimes people just don't think about what they could do there. I actually do think coming up with more innovative services, that's probably the hard part in the whole thing. So two things I would point out in addition to what you just said is the first one, well, you know, you still need to look at jobs, pains and gains, Right. So people forget sometimes before you actually test the solution, product or service or any features. Well, please validate, you know, find some evidence for the pains you're relieving and the kind of objectives and gains you're creating. People forget that that is often or 99% the starting point. So you don't start with the service. The other one I would add is, you know, even if you are looking at a, you know, testing a service, you don't need to build a life scale service. You could put down a brochure, a PDF that describes the feature of the service and a price point and people will be able to give very strong feedback on that. Right. Or, you know, if we go back again to understanding the customers, just, you know, in services, if you live with the customer for a week, you know, if you're a consultant, if you just, you know, and people will allow you to do that, you go and watch them for a whole week in return for some Kind of other service for free. You will learn so much. So people tend to forget these kind of things. So I'm really on board with you and say, hey, service is actually not harder at all, probably harder to innovate, but there's just some misconceptions there. Right David, I'll give you now a really difficult one that you get all the time and you know how to answer. Tada. How many experiments do I need to run? How do I know I'm done and I can go and do this and do that? Right. So not just one experiment. It's already good that people go beyond, but we often get this question like how much is enough? What's your answer for that one?

My consultant answers it depends. But my closer to reality answer is about 12. I know that you're like, where do you get 12 from? Well, if you run this for about 12 weeks and you run an experiment a week, you're going to have enough evidence to understand whether or not you should make an investment, like an informed investment decision, whether you pivot, persevere or kill the thing. Now it's a pretty arbitrary number, I admit, but I don't want teams getting too excited or too depressed after that first experiment. So I've watched teams interview one customer, they like it and they go, let's go build the whole app. I've watched teams like try to run ads to a page that didn't convert well and they said there's no hope here. And we actually made that one a really successful product. Later we just were using the wrong channels and the wrong words. So if you run an experiment a week for about 12 weeks, you're going to have at least more than just anecdotal evidence. Right? You should have talked to a lot of customers, you should have had some real value exchange and whether or not people be willing to pay at all. So a lot of desirability and viability testing can happen in 12 weeks. And I've personally been a part of products that you all use today, probably that we were onto something in six weeks. We had kind of, I won't name the company, but one of the experiments we were running through, we had actually more active users in six weeks than they had a product that was around for five years. So it was kind of awkward. But we were onto something, right? With a focused team that's cross functional and it's open to learning and moving quickly. It's amazing how much you can do. You can outperform like 90 person project teams where people are just giving 5, 10% of their time. So my short answer, 12. But the reality behind that is you need to be doing something every week for at least 12 weeks to get a better understanding. Because I don't want you making big decisions off of, like, small anecdotal, low strength of evidence experiments.

I love that answer. And I'm just going to visualize it. Right? So if we start with an idea, a business idea, sketch out our business model canvas, Value proposition canvas. We need to admit that uncertainty and risk is often very high. Depends, you know, how innovative is the idea. Version 10 of an operating system or a phone, probably not that risky. But let's say you're coming out with something new. Well, your task is to de risk, right? So you do experiments. And I love what you just said, David. Right. Because that's something. That rhythm is something I learned from Steve Blank and from you. Having an experiment a week here over these three months, two to three to four months in this first sprint is crucial. So in this phase, well, probably we're more around desirability, maybe a little bit of viability, but we're not going to test feasibility. Can we actually build this? Can we scale it, et cetera. So up to here, you have a certain number of experiments, and they're very fast, Right? One a week. Once you start building something, probably you can't, you know, if it really needs to be functional, MVP with a real feature. It's not just a brochure. It's gonna take a bit longer. Right. So here, maybe we have a bigger distance for the second sprint. Right. And the reason I'm bringing this up is this is really how a lot of companies organize. Now, the example I use when we talk portfolios is Bosch, where they give teams. And I think it's already a nice, decent amount. Three months. Whoops. Three months and €120,000. You can do a lot already. And then those teams that make it to the next one, they get six months and they get €300,000, so they really start to build certain things. Right. So the kind of cadence, you know, keeping this up is super important. So here's a question. Follow up. Now we're more organizational. David, how do you react when you hear, let's say you have a new client, you're working on a sprint with a client, and you hear the team say, well, our leaders giving us 10% time to do this. What's your reaction?

Your leaders aren't designing an environment where you can be successful, is my reaction. So this is hard enough when I lived as a startup. We were not sustainable at all. And we still failed giving all our time and effort, energy to the this kind of work. And you're asking somebody in a corporation to just do it in their spare time. And so this is a lot of hard work. Even just how do you get to your customers? You might have to try all these different ways and pause and unpause ads and all these things. So ideally, when I've seen this work really well, and this might sound somewhat controversial, IS teams dedicate 100% of their time to this. And I know, Alex, I've had this conversation a few times in the past where I was like, nope, teams. I mean, we were able to get more users in this product, it's an MVP in six weeks than you all did in five years. It's because we had a fully dedicated team. This is all they were doing. So there's a compromise in the middle there, of course, but 10%, it's so rough because as soon as you complete that experiment, other things are going to come up and then you're going to forget why you're even running it, and then the data is going to be stale and then you're just going to start all over it. Just the momentum is going to be really, really tough to get going. And so when we talk about leaders, and we have some organizational questions about leadership here too, is leaders have to understand this. They have to design an environment where teams are allowed to focus more time on this. Otherwise you're just. If you don't give them any budget and no time, it's kind of superficial to say, well, I'm recreating the startup experience by not giving you any time or any money. And it's like, well, even startups do have some time and money. So it's just really, really hard to succeed. It's hard enough to succeed when you have the time and effort and energy and it's almost impossible when you don't.

Yeah. And what I like to add is just different wording of what you said. What you put in is what you get out. Right. So it's about expectations management. If you give a team 20 to 40% of the time, well, they're going to be able to do less experiments, they're going to have less evidence, they're going to learn less. Right. If you give a team a lot more time, well, guess what? You're going to have a lot more evidence. So Karen Hunter had a twist on this. What do you say to a business leader who doesn't even believe that experiments are a viable way to learn.

Yeah, I feel like that question is probably rooted in some sort of real life experience here. So it's really interesting. The language we use with executives and stakeholders often isn't an experiment. I mean, that's what we're doing. Right? But a lot of the terminology. Alex, I learned a lot of this from you. How do you make investment decisions? How do you de risk your strategy? How do you go check? And we're not really leading. It's funny, we're talking experiments today, but we don't use a lot of that language. It's a, wow, this seems really risky. How do we de risk this? And it just happens to be that we end up running experiments to de risk it. But I think the language, I mean, Alex, you can jump in here, but I think the language is like the most crucial part here.

I absolutely agree. So I never use Lean Startup. I never use testing per se. I try to use as much reduction of risk and uncertainty, this kind of language. Investment risk and uncertainty, reducing risk and uncertainty. And the other thing I'd add is I just show a lot of examples of people who build stuff based on great spreadsheets, and then it failed. I mean, my favorite example at the moment is. I don't know how you pronounce it. You maybe know David Quibi, you know, the short video platform. So how much did they raise? I think $1.6 billion. And they had, you know, Meg Whitman, experienced CEO, and they had Jeffrey Katzenberg, an experienced Hollywood person, to build a content platform. It's just that nobody cared when they launched it because they didn't experiment. They actually just built the thing. So I think what leaders are receptive to is when you say, look, go ahead and make a big bet, but just know you're investing in something that's very risky and very uncertain. Aren't you better off by taking this idea and breaking it down into smaller testable chunks? So I did use the word testing, right? You can make these hypotheses, but you reduce the risk. And this is a drawing I actually draw. I draw reducing risk and uncertainty. The other thing I would add that I always start all my presentations now with leaders, with exploit. Explore. I say companies have two worlds. Managing the existing. That's a management game. Companies manage that well. CEOs know how to do that. But exploration is a different game. There we're talking about reducing risk and uncertainty. And then you show the examples of those big investments that people made. They failed. So. And then you Know, I never tell people what's right and wrong. I personally just say, look, it's your choice. If you feel comfortable making a big bet, big, risky bet, go ahead. But just be aware that it's possible that you're going to lose those $500 million that you invested. Aren't you better off to make 10 bets of $100,000 and then pick those things that really work? And that I can guarantee you so far that that language has always resonated. I haven't lost a single CEO I've talked to with that kind of very simple language, but there's zero jargon. I just use their yardsticks of risk, uncertainty, investment, and return. And then you have it. Right. So it's also adapting to our audience. I think it's important.

Yeah, it's voice of the customer. You have to use words that they understand. And you know, who. What exec doesn't want to hear that. This is really risky. Let's go de risk this thing and make better investment decisions. It's really hard to push back and go, no, no, I'm going to do. I mean, the thing is, you look brilliant if you get it right, but if you get it wrong, you might as well update your resume. Like, you can't recover financially almost sometimes professionally, like, if you get something that big, that wrong, it's just really tough. So the idea of breaking it down and testing your way through again, we're biased, right? This is what we do day in and day out, but it's just like a smarter way to approach work. And I will say this really quickly. I was on one of the biggest companies in the world I'm working with now, and the exec was on every call pretty much. And going to the teams and saying, look, we're going to test thousand ideas over the next five years and like 99% of them are going to fail. So there are leaders coming around with that language. I don't experience them as often as I would like, but there are executives understanding, like, we have to create the next big thing. We're not going to do that with three different ideas. We're going to do that with a thousand different ideas. I know that's something that Alex, you've been pushing too, but it's really refreshing to hear people say that in a real world context, because I think there's no way you go through that without having a repeatable process. There's no way you get through a thousand ideas in five years.

Absolutely right. And you know, making big bets makes Sense in the exploit world, when you know the customer, you know the value propositions, you know the channels, it's not a risky bet. You're scaling your factories or something. Right. I would suggest. David, are you up for five minutes overtime? Because we actually, you're out of Swiss time, so let's move to. I won't go in any cliches like more southern time zones. I'd like to hear a little bit, you know, because you've done so many of these projects, you have so much experience. Talk to us a little bit about team formation. You know, ideal teams, how do you set that up? What have you seen works? And I know it's very context specific again. Right. But let me see, who asked that? Michael Piercer from Germany. So it's not on purpose that we now have two German questions answered, but tell us a little bit around team formation. So how do you organize your team? But also how do you select and kind of put it together?

Yeah, I mean, it's tough to answer that in five minutes. I'll do my best, but basically. So the way we describe this in the book is around team design and then behavior and then environment. So maybe I can draw. If I can share my screen, I'll just draw this out for you. So. So basically they're different dynamics. And that was a big learning for us. We'd experienced this when we were writing the book, but it was kind of coming out with a way to really put visuals to what we've experienced. But when you think about the team, you think about, you know, we need this team that is capable of kind of learning quickly, you know, and they have to usually make up different functions. Right. But you kind of have your team design. And one of the things I would be careful of is don't look across your organization and go, oh, we don't have any entrepreneurial people here. We just got to go higher outside the organization. That is not usually the case. From my experience, it's that your people were never really given a chance to be entrepreneurial. And so if you give them a chance, you can usually spot those people. Like, who's the person that just pulled off that project when there was really no hope? How is she so creative that she solved something we could never solve? You have those people in your organization, so try not to just look outside. From the get go, you kind of have team design, and then outside team design, you have these kind of behaviors that we keep talking about. And with behaviors, you know, are they open to testing their ideas? Are they customer Centric. There's this kind of things that they'll exhibit that you need to encourage. Okay, so first have a team. Look for the creative people in your company. Have a well balanced team of different functions so they can test different parts. Because usually you don't have one person that can do it all. And then overall think about, and I'm just kind of drawing this out really quickly for you, but the environment. And so do they have things like focus, do they have budget? You know, you as a leader, are you setting up a space for them where it's almost like a garden, right? You're like planting these seeds and you have to tend to your garden. So, you know, I think what happens is we focus so much here on the design of the team. But in reality all of this needs to happen. Otherwise you can have this amazing perfect dream team that can't do anything. They can't get to customers, they don't have any budget, they get pushed in all these other different directions. I think in a way your question is really telling. I think in a way we need to almost take less emphasis off the team design itself and start looking at, okay, are we fostering the behaviors we want to see and are they in environment they can succeed? And this isn't just internal, it's even if you acquire a startup, right, as a big company, how many scenarios have we seen where this amazing startup gets acquired and then the team's like, we can't do anything anymore. We were amazing team, we had hundreds of millions of dollars of revenue and then we're in this environment where we just can't even do anything because of the governance and policies and whatnot. So just be mindful of. It's not just the team design here. It's also, can you help foster the behaviors and then create an environment where they can flourish? And then how do you do that across hundreds of teams? Eventually, because you want a portfolio of ideas that you're pumping through. Because like Alex has mentioned, it's almost like a VC model approach. You're not going to find that next unicorn thing with making three or four investments. You have to do it across many, many, many.

I love that drawing. And you know, I'd really emphasize that the environment, the leadership, that's the role of the leadership to create that environment. Because otherwise all you get is innovation activities, which we like to call innovation theater. So, you know, a lot of activities going on, but they can't get to the next level because they don't have access to customers. They can't get to the next phase of testing and scaling. So this is something we see way too often. I don't think we see a lack of innovation activities. I think we see a lack of good environment that allows the teams to thrive. So, David, should we put up the slide one last time with the discount code for the Virtual Masterclass? And with that we will conclude the session. So, as I wrote in the chat, we'll go really deep in the three days we have together. Of course, more structured with slides and a lot of exercises. So you're going to do a lot of work, for example, on hypothesis, on prioritization, designing experiments. So we really designed, I believe, a pretty good using hypothesis language there, really good masterclass, which we adapted from the physical one. So, you know, we wanted to make it just as interactive in the virtual space, which is a bit harder. But I think we're onto something good. David, any last parting words?

We'd love to have you. We put a lot of time, effort and energy of making sure it's not just a webinar. Right. It's a very, very interactive experience. And I'm not exaggerating when I said we don't speak for more than 10 minutes a certain way. It's by design. So it's really high paced. You're going to meet a lot of interesting peers from around the world. And yeah, we're trying to give you superpowers so you can go off and test your ideas in your company. So, yeah, we'd love to have you. Cool.

Thanks for that, David. Thanks also for Gab for setting this Ask Me Anything session up. And we hope to see you at the Virtual Masterclass. See you there.