Hello, and welcome to the bottom skills podcast. I might pass in this I'm the CEO of Qualitas and we have reached the final episode of our lean startup series. And we're going to put lean into some context. That's all right. We're going to put it in somewhat of a bigger picture. Because lane is such a great methodology.

It's such a powerful tool. Um, I'm, uh, as you have probably guessed from this series, I'm a huge fan, but I think it's also important to realize it does a particular job. And if you want to use it. There were different times and places to use it, but it also needs to work together with some other practices as well.

And so I'm going to try and map them all out for you. So it's a bit of an audacious undertaking, but I really think that this is a great exercise now that we've got a very good [00:01:00] sense of some of those key practices of the lean startup. Let's put it into a bigger picture. Okay. So let's take the challenge of trying to put lean startup into one sentence.

And I think it's the loop that we've talked about on this series. And let me pitch it to you. Lean startup is all about build, measure, learn. If there is anything. That can summarize the lean starter in just a few words. It's the loop. Cause it all comes from there. You know, you need to build your MVP. You need to make sure you have the right data.

You need to learn and ask yourself pivot or persevere. Which growth engine and so on and so forth so much inside of it, but it spins off, uh, this central point of build measure, learn loop. And I [00:02:00] think this is the real power because you know, the. The context here is that the old way of building software was what we call the waterfall approach, which starts with this heavy requirements and specifications.

And it differs all of the testing, all of the learning and measuring till the very end. And frankly, that's why it was becoming really an outdated process in such a fast moving world. So. Lean startup really, isn't an essential tool. Uh, if you want to build, measure, learn, if you want to test and validate, um, it's essential, but let's do it ourselves.

An exercise of two parts. First, let's make a quick inventory of some of the other practices. You need to build a great product, but let's also kind of put it, um, Let's talk about when they, uh, when they happen, [00:03:00] um, when they occur, when should they, um, be used within the journey of building and managing a product.

So I think something that's very close to this, uh, idea of build, measure, learn, which is in the lean startup, is this idea of rapid prototyping. Now, rapid prototyping for me. The the real core of this is that you test. If you can get the job done, uh, for your end users, by what I call stimulating the senses, the thing about rapid prototyping.

Cause you don't conduct, uh, sort of a traditional focus group and say to somebody, Hey, would you like to maybe consider this idea? Now you actually build a light version of it and you actually get them to try and complete a task to try to actually try and use this model, this sketch, uh, this light version of your product [00:04:00] and rapid prototyping, because it stimulates the sensors.

It gives you all this, uh, feedback. So you need to. This is really interesting. You actually need to do both the lean startup and rapid prototyping. So if you really want to build a world-class products, you need to have this practice of rapid prototyping. So where does this interact with link? Well, um, you build something, you don't have to build a full product.

You can build a prototype and then the results of which is something that you can measure and learn. Now, another thing. That really is close, is adjacent to rapid prototyping. And lane is design thinking. Now some people might actually say rapid prototyping is part of design thinking, but I like to elevate design thinking to being the following idea.

It's how you empathize with users, not only to prototype, but to survey, to interview, to almost be ethnographic, to be like Sherlock [00:05:00] Holmes, to really obsess about their world, their jobs to be done. So what design thinking does can help you develop a much better hypothesis at the start of your lean startup process?

So with lean it's like you're going to build a hypothesis. Okay. Well, if you use a number of the practices from design thinking, you can start already much closer to success if you use design thinking, because let's face it. If you, um, to say, Hey, I want to do something in financial services. Then, how do you know where you kind of kick off with your lean startup approach?

Well, I would always use design thinking to find out where the biggest unmet pains and unmet gains are existing in the market. Who's not solving some problems, what's, what's up for grabs. And, and then I would, you know, take the build measure, learn loop, uh, to that area. [00:06:00] Okay. So we've talked a little bit about how lean startup interacts with rapid prototyping and design thinking.

Um, let's now go to a big one. Let's go to agile software development. Now I think at the core of the agile software development is the idea of building small teams who have a focus on. A prioritization of working code over lots of lengthy kind of waterfall ESC documentation. Now those agile teams will work.

Probably using scrum probably with a two week sprint and you know, what they should build, measure and learn within that two week sprint. That's where the lean startup comes a great agile process. We'll have the measuring and learning from lane inside of it to make sure that they're. Team or building something that the user actually needs and [00:07:00] wants.

So that's the inter interaction there. Now, all of this will get you to a product that you launch and that's where you really, really, really need to go out in the world and to do some growth marketing. Now. It's really interesting here. I think you can argue that growth marketing takes a lot from lean startup and growth marketing.

Is this idea of you've got like a funnel. Which starts with, you know, generally awareness and goes right through all the steps to customers, referring you to, to new customers. And this is the funnel and growth marketing obsesses about all the steps in the funnel, because traditionally we only focused on the early parts of the funnel.

It's got a huge test and learn, uh, flavor to it, growth marketing. It really used the new way of doing marketing or traditional, uh, brand marketing. Um, [00:08:00] and again, once your product is live, that's when it's time to use it. Okay, so I've hit you with five big ones. So we started obviously with the lean startup, but we went to rapid prototyping, design thinking, agile software development, and we just talked about growth marketing.

Now there is one more and. The reality is that all five of these, let's say methodologies practices. They're all done by PayPal. No matter how obsessed we are with all of the skills, mental models that come with them. What we've just talked about is, is no one human individual. Does all of this in a silo, in a tower in isolation, all of this work is done in teams.

So we have to talk about culture [00:09:00] because culture is what drives teams. So if you want to put the lean startup into practice, if you really want to inspire, motivate, and get people really. Moving in the right way, then you really do need to consider. This idea of how you build high-performance teams. And we talked a lot about this in our agile masterclass, so I don't want to get too distracted because you know what I'm like, I'll get, I'll get all excited...

Hello, and welcome to the bottom up skills podcast. I might pass since I am the CEO of Colton's. And we, again, ask this question, shall we pivot or persevere with our product? And this is an okay central, uh, critical, a fundamental idea inside of the lean startup. And we are going to dive into it. It is. I got to tell you this one's a good one.

And you know what? I honestly think it is so underestimated because I see way, way too many times companies persevering with products, services, and experiences that really should have been pivoted. And what's really fascinating is if you actually look a lot of successful companies, they're made up of a series of really well [00:01:00] thought out rigorous decision-making around this choice between a pivot or to persevere.

So I'm hopefully going to decode and unlock this for you today. This is a very. Very important, uh, piece of the lean startup. Um, it is an essential thing to embrace. Just it's going to help you build a better product and it's going to, as you would only expect from Eric Reese and the lean startup, it's going to give you some very strong accountability on how to build a better product to make something that's actually worth using and worth building.

Okay. So a little bit of context here. When we talk about this pivot or persevere question, it's all done in the context of learning, right? And it's the build measure learn loop. That is the lean startup. And I got to tell you it's all iterate, iterate, iterate, continuity. You don't [00:02:00] just ask this question.

Once you ask it all the time. Do we pivot? Do we persevere because you're in a continuous cycle, a continuous loop of growing your product. Step-by-step question by question, proving out your hypothesis or disproving your hypothesis and building a new one. So let's, let's kind of try and bring ourselves into what the pivotal persevere question looks like and how it works.

Okay. First let's just get the definition, right. A pivot is, you know, if you think about it, it's a change in the strategy without changing the vision. So what I mean by that is you can have this huge vision. To help a particular customer segment. Maybe it is to fix a big problem in the [00:03:00] world. That's great that doesn't have to change, but how are you going to get there?

Right. What's the strategy for doing that? That can change a lot. And the pivot is this moment where after measuring. We changed the hypothesis and we try a new approach that might yield better results. Okay. So let's unpack, unpack that a little bit. That one's pretty, pretty deep. So, you know, you, you, you, you're building a product.

Um, let's say it's a podcast app and you have this idea that there's not enough conversation and commenting and sharing of podcasts. It's all a bit ad hoc and it's too hard. And your vision is that you want to get the very best, uh, relevant content to people around the world. You think it's too hard to find there's too much hidden treasure.

Um, there's all these rough diamonds hiding out in the world and you want to make it easy for people to [00:04:00] discover new podcasts. Okay. That's your vision of the world and you think people will be much happier if they, uh, if they get access to lots of different podcasts, but you might have a particular strategy for maybe you emphasize the commenting of the podcast, or maybe it's the sharing of the podcast or the liking.

And you might try this as a strategy in your prototypes, in your MVP, and you might find. That let's say you did it all around reviews, but people just don't want to write reviews for their podcasts. Maybe they don't want to write it because they're too busy listening and you can't do two things at once.

Maybe that's what you discover. So you can still stay true to your vision of helping people discover new podcasts, but maybe. Instead of doing it through the commenting it's through liking or maybe your strategy is not to focus on the [00:05:00] liking, but there are different ways of doing it. Maybe there is an algorithm that measures your consumption and you don't have to do anything in that creates a recommendation engine, just like Amazon.

I mean, I, I'm getting a bit excited here about this product actually, but my point is this, you could go so many different ways of. Having a strategy to realize this vision of a precast discovery service. So my point is that you might test one of these and you may discover that the strategy is not right, and you're going to try a different one.

Then hopefully that will yield better results. That is a pivot. You're like we tested the route. We just couldn't get the results. Not enough. People were reviewing, liking, writing, sharing the podcast. So, you know what. We are going to try an [00:06:00] alternative strategy to achieve the vision. Now what's so powerful about pivoting is that if you go to Jeff Bezos, CEO, and founder of Amazon, he says, be stabbed on your vision, but flexible.

On how you get there. And this is exactly what Eric Reese says in the lean startup too. Like, don't be too attached to the strategy and, Oh my gosh. Do I see people so attached to a strategy, particularly in the corporate world, people selling a strategy and then it's like, it can never be changed because that's what we promised to the boss.

No, I think you should do a differently, you should promise a vision. With a plethora of strategy, possibilities that you will test validate in order to discover the right one. Okay. So we've dealt with the first half of this question, the pivot, right? So you can stay true to your vision. You can change the [00:07:00] strategy and I just keep testing, looking for results.

Now what's the other alternative to the pivot persevere. This means a totally different situation where you've got this vision. You've tested a strategy. And the results look pretty good. Some might even say encouraging. Now, this is where you really need to persevere. Get really forensic and rigorous, go deep into all the little tweaks that you can do.

And, uh, I remember. Working with a great creative director in the U S and he always had, when he was persevering with a great idea, he always had this, uh, visualization of, um, a point system when we would make a great, uh, Television ad. [00:08:00] And you'd say, you know, you started a hundred and every, uh, every time you change it, you need to be pushing the quality towards a hundred out of a hundred.

Likewise, you don't want to make too many changes and start sending it to the negative. So in this case, I want you to imagine that you have. Some early stage results that give you a, like a 60 or 70 out of a hundred. And what your job to do is if these numbers look good, you want to continually see gradual improvements through your perseverance.

So you're testing your product and you're like, Hey, the engagement is slowly but surely continually increasing and compounding. So, if you go back to our previous episode, we were looking at the engines of growth within lean startup. You would want to see an improved usage frequency. If it's a sticky [00:09:00] product, I would like to see an improvement in the firewall coefficient.

If it's a viral growth engine and you would want to gradually, but surely. Improve your cost per acquisition for a paid product. This is what you want to do now. Here's the trick. Here's the gotcha. There is no scientific standard to making that pivot or persevere decision. It is question of judgment. Okay.

So. It can be, um, subjective. I wish it was more black and white, but here's a rule I would encourage you to consider. You should pivot. If you continually get diminishing results of improv...

Hello, and welcome to the bottom up skills podcast. I might pass in this. I'm the CEO of quality tents, and we are going to talk growth engines. That's right in the next installment of our lean startup series. We're going to talk about how to grow our product. And you know, the interesting thing about growth is it's absolutely essential for a brand new product.

Because it's going to start out a little smoke. So we really need to grow because a sign of growth is a sign of demand for your product, which means you're kind of solving a problem out there. That's actually worth it. Solving. And that's really the pursuit of lean startup to build products that matter to solve problems that are really worth solving.

And there's many different ways that you can grow your product. And we're going to [00:01:00] talk about those. I'm going to give you some examples and I'm even just to get a little meta on the topic. When I talk about how these different versions of growth actually can be combined. Bind, but I did want to just take a moment because as you join us on this lean startup series, it's a great book by Eric Reese.

I thoroughly recommend that you grab it. I w do want to kind of put everything into a little bit of context. Yeah, importantly, there's half a dozen or so episodes that come before this one in the lean master class where you'll get some great tips, hints, uh, suggestions on how you can validate your product, how you can test and learn.

And I do want to make sure that you go and have a listen to that. If you enjoy this show, you should definitely check out, uh, the shows on. A minimum viable product venture [00:02:00] hypothesis, the build measure, learn loop. So, you know, really do, um, go back and study those if this peaks your interest and don't forget, we've still got a couple more.

Uh, episodes as part of this lean startup series. So make sure that you, if this is really, uh, helpful this show, make sure you go and check those out. And if you do want any more information on, uh, lean startup as a methodology, we've actually got an entire masterclass at bottom-up dot IO. It's absolutely free.

And I'm really encourage you to check that out. Um, there's a lot of good stuff there. And if you like that, there's actually a lot of others over a dozen different courses on there. All free, go check them out. Bottom-up dot IO. All right. Well, I mentioned that there were three different engines of growth.

They are sticky, viral and paid. So three different engines of growth. And we're going to talk about each and every one of those. [00:03:00] Um, so let's get into what this idea is. On a sticky, uh, growth engine for your product. So the starting point here is you've got a product. It might be a SAS product. It could be a paid app in the app store.

Um, whatever it is, and frankly, It can be both digital and analog. I want you to imagine that your growth engine, the way the popularity of your product grows is through being sticky and inherently. What we're talking about is this paradigm that when you're making the product, when you're managing the product, your focus is on making sure that customers come back and use the product or the service as much as possible.

Really high on engagement, lots and lots and lots of use. And there's a couple of, uh, key metrics you can use to know if you're doing that. But [00:04:00] an example I'd love to give you is, um, You know, a service like Dropbox, uh, they really depend on, um, people came back and using the product a lot because, you know, you're, you're paying some money every single month for your storage.

Likewise, you might argue that the likes of Snapchat or a CRM tool, Zendesk, or even Uber, they all have a sticky requirement to them. They've got to get their customers coming back time and time again. So. Really important because if it's sticky, you will grow. Uh, you know, if you go back to the example of, you know, lean startup, superstar, Dropbox, they know that if they, uh, have lots of people using the product regularly, people are going to stick around and pay that subscription fee.

Uh, some might say the same paradigm exists for Zendesk. It's a paid B2B service. Really important that people stick [00:05:00] around and use the product. So this is in the world of being sticky. Now, how might you measure if you're actually hitting the Mark? I mean, there's a lot you can measure. What do you measure if you want to know if you're being sticky?

Well, I think there's a couple of ones, first of all. The the most important one here is in terms of engagement, what is the usage frequency? You know, anybody in this case, who's got a sticky growth engine you're going to be looking to get well beyond once per month as a usage frequency. You want to have them coming back as much as possible.

Now there's some other kinds of more customer lifetime, uh, uh, metrics that you can use. You definitely want to look at your churn rate. Now what's a symptom of a very highly competitive environment is you will see competitors are churning through customers. Great example is mobile [00:06:00] providers. So let's think 18 T in the U S let's think, uh, BT in the UK or.

Yeah, perhaps Telstra in Australia, these kinds of companies are always churning because there's a little differentiation between the products and services. So what happens is customers jump from one product to another, from one provider to another, and that's what we call churn. And what you want to avoid here is having a leaky bucket.

Like you win 10 customers, but you lose eight in the same. Uh, period, if you're doing that, then the net effort is you've only increased two. So what would be really good is if you can win 10 and keep nine, uh, that would be some much better economics for your sticky growth engine. Now, you can also look at your, uh, rate of retention or your rates of acquisition of customers, uh, particularly, you know, For more mature products, you want to [00:07:00] try and retain customers for more months.

So you might say our average customer lasts. For 14, 16, 18 months. If you can expand that lifetime, uh, make the product more sticky over a longer period of time, then you've really got something. So this is really powerful because then you can look at these data points and ask yourself, are we being sticky?

Enough. Okay. So that was the first one. That's the first engine of growth that was sticky. Let's go to number two. That's viral. Now viral is super, super interesting because it's essentially this idea that when a customer comes on to the product or service that they actually will recruit another customer.

Really really interesting idea. Sounds simple. It's actually pretty hard to, to design for. I'll tell you that much. And, um, a great example of this is obviously, uh, Facebook now. Um, you know, [00:08:00] what's interesting just to play with this. I think Snapchat, who also. Has to be sticky, also needs to be viral. And I want you to consider this, that it is not a mutually exclusive system.

You can have the requirement of being both sticky and viral, but let's stay on track with the viral for a moment. So another, uh, service that has quite a viral nature is PayPal. And if you look at the commonality between Facebook, PayPal, and Snapchat, they're all creating networks. Or marketplaces as really interesting.

So what happens is Facebook, PayPal, and Snapchat all get better. If, as a user, you recruit another user to the platform. So what's kind of fascinating about this is this is both the strength and the weakness, particularly of social networks, so they can grow incredibly fast. So, um, a [00:09:00] great, uh, additional example...

Hello, welcome to the bottom-up skills podcast. I might pass since I'm the CEO of quality runs. And here we are, again, it's lean startup and we are going to discuss measuring product fit. And boy, is this one going to be good? Because when I first discovered these three levels of product fit, it made so much sense similar to when I discovered rapid prototyping and how helpful that is in the journey of building a product, this measuring fit.

Uh, thinking, and this three-step framework I'm going to take you through is fantastic. So there's actually, there are three types that I'm going to take you through. I'm going to discuss how you actually achieve that fit. And I really want to place it in perspective. So that you feel [00:01:00] that you know where you are with your product or service and how you might build out, um, through these three stages.

And, um, this is going to give you the chance to know where you are on this journey as a designer, creator or entrepreneur. Okay. Step number one, there are three stages of fit. The first stage of fit is what we call problem-solution fit. Now, this is largely making sure that the problem that you, uh, might have in yours.

Business idea, product idea. You're actually just want to make sure that the product problem that you perceive we've actually existed for users now, right? The reason why this is so important is we so often guess that a problem exists and it's a very famous adage that so many products, uh, solutions looking for problems.

Um, and. What I'm encouraging you to do here, when you think about the problem, solution fit is to go out and make sure that the problem [00:02:00] solution fit is actually there before you do anything else. Now, obviously the previous episode, we talked about MVPs and how you can test your ideas. What you would want to do to bring the two episodes together.

If you're looking to create a problem, the solution fit very early stage, that's the problem exists. You want to go out there and you want to recruit potential customers or users, and you want to determine through a survey or through an interview, or even if you're just doing a diagnostic, discover how their world exists around a given problem.

So, this is large, if we think about areas of expertise, there's going to lean heavily on user experience in design thinking, because you're going to have to have empathy for the user and, um, What you will do is you'll use a tool code, a value proposition, canvas. This is a very good way to map what the [00:03:00] problems and solutions might be.

And this breaks down into a number of different areas. And if you want to know more about that, you can head over to bottom-up dot IO, where you can get all our free masterclasses on design thinking on lean on agile, because we break this down a lot more than we're doing just on the podcast. So back to value proposition, canvas, this will have the user's pains and gains matched to how you relieve them and how you create gains.

And so I think, um, A way to think about your approach here with these recruited users is it's all about discovery. You just want to be one curious cat, does this problem really exist and be honestly be tough on yourself? Because the worst thing to do would be to go out into the world and build a product that was built on a problem that actually didn't exist, or maybe the problem exists, but the solution was a guess and you [00:04:00] didn't actually validate, is this the right.

Solution. And so I think a great way to think about the journey of stage one problem-solution fit is it's a search for desirability is the solution idea that I have the thing that's going to solve things. Is it really desirable? Like when people hear the idea of like, Ooh, that sounds good. It's like Uber taxis, but better, faster, cheaper, safer.

Oh. Yeah, well, that sounds pretty great. And you could just riff on this for, for ages, but you really want to make sure that you've actually uncovered a really strong problem and a really strong possibility on how you might solve it. So let's assume you've got your problem-solution fit. You can move to stage two.

This is called the product-market fit. Now at this point in time, we're starting to adopt some pretty serious of lean thinking, uh, some pretty serious product management. [00:05:00] And what you're really looking to do here is to use a couple of tools. You might have a prototype. You might even be at MVP. You might be, have a little bit of code now.

Uh, you might have a landing page, something up and working. And at this point you want to use that stimulus to validate product-market fit. And the thing that captures that thinking is going to be what we call a lean business canvas. And this goes beyond just the problem and the solution, right. It's going to look at everything, including your customers and your segments, and, you know, value props, unfair advantages, but it's also, and this is why it's getting more on the business side.

So also going to have, you know, revenues and costs associated with doing this idea. Now, when we talk about with whom are we testing in a product-market fit, we're actually going out to early adopters. So we go out to them and what we want to do is have them successfully complete a task because [00:06:00] that's when we know that we actually have product-market fit.

Yeah, we had an idea of the problem solution. Then we put it into action and early adopters did it. They were happy. They were satisfied and you know what? They were prepared to share to advocate and to create what we call the viral coefficient, which is where for every user you attract, they bring in another customer.

So I think this is a slightly different mentality. Um, you know, obviously you're still going to be curious here, but do you want to have a real strong bent? For validation. Do we really have something you really want to make sure that this is a viable and feasible product? The idea was desirable. We saw that in a problem-solution fit, but now can we still deliver on that promise, but also be viable, right?

Make some money. And two, is it technically feasible? Really important questions. All right. I know we're covering a lot of ground. You're like, Whoa, Mike, this is a lot. [00:07:00] Stick with me. We've only got one more stage to go and that's called distribution conversion fit. This assumes that you've done the first two levels of fit.

Okay. So we're all good there. Now we previously, we, we really convinced early adopters. Now it's all about working with your large-scale mass audience and you are using your paid at your earned and owned media to grow like crazy. Growth is the key here. It's the key mentality and you want to achieve growth through seeing traction for your product and profitability for your product.

So you want people to really love it and be bringing new people in. But if you have to pay to acquire your users, you need to make sure that you can cost-effectively acquire a customer, and that you don't have some really expensive cost of acquisition, which is really going to hurt your growth. So this is distribution conversion fit and together this journey of problem, solution fit, product, market fit, and [00:08:00] then distribution conversion fit.

It's the life cycle of a product it's so clarifying when you sit back and you look at these because really it is quite phenomenal that years and years of hard work with lots of people and effort and. So much testing with users, it fits so nicely into this three, uh, stage, uh, the process of product fit. I hope what you see here is that if you continue to test and learn, you'll enjo...

Hello and welcome to the bottom-up skills podcast. I might pass since I'm the CEO of confidence. And today. We're going to talk minimum viable product. Yes. Building a minimum viable product. Otherwise known as an MVP is such a good way to test your product idea. And what's neat about it is why build.

The entire product, whether it's digital analog, all that code or that infrastructure, why build it all. And then test when you can test really light versions, uh, light ideas, sketches models, prototypes, you name it, uh, really early in the process. So you can get a better idea of if your product really works for the user.

So today we're going to discover all the different [00:01:00] ways you can test and learn surveys, prototypes, or even feature driven for minimum viable product. So we're going to get into the good stuff. Now, the first thing I want to say here is some really hardcore lean startup folks would, um, Not always want to do surveys and interviews, but frankly I really liked them to kind of set the scene and to get you kind of comfortable with the market that you're going in, the segment that your customers and so forth.

You can do a lot of rapid prototyping and a lot of, uh, testing and learning after that. But I find it can give you some very, very good insights. So I'm stretching this concept of what can be the minimum viable product to include, uh, surveys and interviews. Um, but of course, we're going to talk about some prototyping and of course we'll get into some, uh, [00:02:00] MVPs.

So I'm going to break down each three. Types that I've just bucketed for you and we're going to get into them. And hopefully this gives you some inspiration about how to test your next product idea. Okay. Let's talk about surveys and interviews and how they can help you test your product idea. Now, uh, you might hear these formerly talked about in terms of quantitative and qualitative research.

Well, they really talking about is a survey, which is quant and qual. That's the interview. And you're looking at either doing surveys or user interviews. And I want to share with you just a couple of really cool tips and tricks that I've learned throughout the years and some best practices to help you get the most out of testing your idea.

Without a doubt. If you're going to do a survey, one of the most important things is your screener. And I love to use a screener as a way to create a [00:03:00] segmentation of my audience, of my customer, my user. So let's just take this idea that, um, we want to develop a new app for, for getting podcasts onto a smartphone.

I would have a screen that starts the survey. Asking them a couple of different ways to describe themselves. And this will help me understand not only some usage insights, but it will, might give me a little bit of a sense of which segment of all of the podcast, listeners and users might be a market for my product.

So I would have something like, uh, on the survey. First question is, you know, what, which best describes your podcast usage? I'm hooked. Um, I like podcasts. I've listened to a few shows or lastly pod. What? And obviously you can expand them on these and give them a context, but this could be really powerful because I might discover that people who like podcasts would listen more if they had [00:04:00] particular features or experiences.

In their podcasting habits and then I'd be off to the races. I've got something to build a hypothesis around. Um, some of the other questions I'd love to ask is, you know, what's the biggest pain that you experience, um, what trips you up, um, and, um, In a second round of, um, uh, surveys and interviews, you might start getting into asking people to evaluate an idea or a visual asset that is, uh, almost a poster.

If you will, for the, for the given product solution that you want to build. And do you ask them to write it out out of a scale of 10, 10 being amazing one being not so crash hot and you can propose something and ask them how interesting is the proposition? How likely would they be to share it or how likely they might be to try the product?

What's really interesting. These are all very good early indicators of whether you're [00:05:00] onto something with your product. So there you go. You don't have to build any code or you don't have to build any physical product or distribution. You can just get in front of users, either through a survey or interview.

You can ask some of these questions and you're actually already starting to test your product. Now, let's say that goes very well. And you're pretty excited, uh, from your interview and or your survey. And now you want to build a lightweight prototype and, uh, this is really gonna help you see if you've got a.

Problem solution fit. And you might, uh, have a product demo. This was famously done by the guys at Dropbox. They just made a video of their product. And so many people liked it. They then decided to build it, or you might get into bringing the experience to life through different what we call versions of a minimum viable product you could have, uh, you could crowdfund it.

So just think about Kickstarter. You can put it up there. The product's not [00:06:00] built. You might have a. Picture or profile prototype that you show, or you might get in front of real users. And frankly, this is some of the best stuff where you do what we call either a  VP or wizard of Oz. Um, the concierge, when I want to focus on, because that's actually what Zappos did when they launched, they actually needed to test whether people would even buy shoes online.

So what they did is they made a website and they only fulfilled orders. If someone actually purchased and they had no stock and then they would run down the road, buy the shoes and send it well, pretty soon they got so much response that they actually validated their hypothesis through their MVP and then three that they were ready to take it to the moon.

So, yeah, this is the second bucket. This is the rapid prototyping. We've got a whole master class on rapid prototyping. So if you're interested in that head over to bottom-up dot IO and you can sign up for the free master class that. Now the last bucket is [00:07:00] building a feature driven MVP and, um, The reason I say that's different to a concierge or wizard of Oz.

MVP is you're really moving into to test a new level of, uh, user experience. And it's generally much more work than the earlier two buckets. So we had bucket number one of testing of MVPs. Survey or interview that's number one, number two was prototyping. All right. Number three is building what we call feature driven MVP.

Now this is particularly good for software folks, people building digital products, and there's two things you really want to do here. You want to test either for. Task completion, which is a very, very, very strong indicator on your product. Can they get the job done? And if you want to take that to its highest order where you're actually really starting to get, uh, product market fit is when not only can you bring an early adopter to your feature driven [00:08:00] MVP?

Not only can they complete the task, but where they actually would recommend it. To a friend they're so satisfied that they would actually be prepared to not only purchase this given product or service, but actually they want to share it with a friend. And if you can get to that level with your MVP, you can have enormous confidence to go out into the world and actually build your product.

For real, you might want to raise money. You might even want to get people internally. If you're at a large enterprise to get behind your product. So let's just zoom back and look at what,...

hello and welcome to the bottom-up skills podcast. I'm Mike Parsons. I'm the CEO of tents. And we are continuing our journey, our adventure into the world of lean startup. And today we're going to talk about the mill build measure, learn loop. Yes. It's going to get pretty loopy and it's really important to get into this idea of the loop that is inside of the lean startup, because, you know, if you think about a completed product, that's shiny polished.

It's been through all sorts of prototyping, MVP, it's the full deal. And if you actually look at it, it's actually, you can break it down into literally hundreds of small little tests that have been done since day one. And the [00:01:00] power of this loop is that if you learn each time you build something, you measure it.

Actually, you know, what the product gets better. Uh, you de-risk mistakes, you don't make assumptions. You start to shift from guessing to knowing you're more confident you have more insight. And you know, at the heart of this is the opportunity to, um, really. Enjoy the process because let's be honest, building a product with very, very complex.

So together on this episode of the bottom-up skills podcast, let's decode this scientific method that's behind it all. And let's see how we can continually test hypotheses and, you know, really embraced data, uh, in the use of these little kinds of experiments you could call them. So that we can really, uh, be onto a good thing to know what users desire what's technically feasible.

And honestly, let's make [00:02:00] sure that we've got a viable business offering too. This is all at the heart of the build measure, learn loop. Okay. So let's think about, um, this loop, this loop is something that you could do. Uh, from everything to some of the core functionality inside the app, to the name of the service, everything you can build something, put it through some sort of test with users.

That's that's really, really important. Then you say, okay, let's look at the data and ask, what did we learn? And then once we've worked out, what we've learned, we can then start to inform our next decision. So this is the build measure, learn loop, and you just keep doing this. And I think a great signal inside of any product team is how much they're learning.

So they don't have to hit the home run from day one, but you can be really sure that I'll get that if they're learning. And so using this [00:03:00] loop as the key tool to do it. So you got to start with, you know, obviously a fundamentally good idea, and then you've got to structure that into a hypothesis and I'm going to.

Yeah. Tell you a little bit about how to do that in a second. And then you've got to go, okay. Let's work out. Um, how are we going to measure it? You collect some data after you've tested it. Now it's really important that you always test with users. Um, don't test with yourselves as product owner, because you're going to be full of bias.

Now you've got to really, really test with real users. And then you're going to have to make some, some decisions based on the data and, you know, challenge yourselves about what you've learned. Um, Ask yourself, do we revise? Do we stop? Do we persevere? Do we pivot? There's all sorts of, um, ideas here. Now.

Here's the thing. You can do that with each, uh, core feature each, uh, user story. Uh, or you can start to zoom [00:04:00] out and apply this to the business itself. And so you can see some really significant pivots, uh, have happened from businesses that end up winning, uh, providing a service that was, looks nothing like where they started because they used this loop and they kept learning all the time.

And actually they abandoned their early ideas. In fact, most successful startups end up succeeding. In an idea or a version of the product that is radically different to where they started. So it shows you how much learning is really crucial because we often don't really start with the best ideas, even though no matter how good and no matter how talented we are.

In fact, sometimes we've got some pretty rotten ideas, but actually if you use this loop, You can look at your, whether it's a logo idea, product idea, or venture idea, just look at it as a starting point. And if you continue to learn, you should get incrementally better. [00:05:00] Now there's a lot inside of this loop and I want to focus on something that's going to come back a lot in this series, which is like, what's the hypothesis.

And I really like this because it just helps me simply structure a product idea and its proposition to the customer and to the user. And inside of this hypothesis can be certain. Parts, uh, elements or aspects of the product or service that we can test and will change a lot. And I'm just going to take you through what this might look like, so you can get a good sense of, okay.

I know there's a loop. I know we're going to build, we're going to measure, we're going to learn, but I'm going to give you, um, the structure of, uh, of the venture hypothesis. So you can start to wrap your mind around it. So this is an example of our structure or template that you could use yourself. So I want you to imagine this is a venture hypothesis, a [00:06:00] business idea, a product idea, and here we go, a certain persona exists and they have a certain problem scenario, situation.

And currently they're using certain alternatives to kind of get this job done. But if we offer our time target value proposition, our solution, right? Then we'll observe success through key metrics such as onboarding engagement, et cetera. So this would be. Basically your idea in a nutshell, and let's just break it down and see what is inside of the hypothesis and see how we could break this apart and test it.

So the first thing you'll notice I mentioned is a certain persona exists. They said differently, a certain customer, a certain customer segment exists. Well, that's something that B can be tested because you're going to want to go for [00:07:00] a. Let's say health obsessed 40 year old men. Let's just say, that's your persona where you need to go out and actually validate that th there are a lot of health obsessed, 40 plus men in the world, and then you'd have to go to the next part of your hypothesis and they have a certain problem.

Okay. So you can go in test the problem. So you can do a lot of, uh, very, um, simple interviews and surveys to actually qualify. Does this problem exist? Is it the biggest problem and is it a problem that they really want to solve and therefore would be prepared to pay for this problem scenarios? The next part of your hypothesis that you can test.

And again, this is, remember this is all inside the loop. You're going to build, measure, learn. Each one of these things, you build something you actually measure and test it with the user, ask yourself what you've learned, and then that informed what you build next. But [00:08:00] we're not done with the hypothesis because you'll remember that the third part, after we say a certain persona exists and they have these problems, we then say, currently they are using these alternatives.

And in here are lots of clues to either what you should do. What you could do better than what's currently on offer, or you might have to go radically beyond because they're currently meeting the needs of users. So understanding how people get the job done today, even if it's far from perfect, really essential as part of your hypothesis, and really, really crucial to go into test, to learn, um, put it through that loop.

And then you say, if we offer our value proposition, what it's, what's going to relieve their pain, what's going to create their gains. This is our hypothesis. Now you can test this ...

Hello, and welcome to the bottom line skills podcast I might pass since I'm the CEO of quality tenants. And today. We are continuing our journey into the lean startup. And the topic of today's episode is everything about learning. Learning is so damn essential as you will have seen from the previous episode, the foundation of the lean startup is not guessing.

It's not just about having ideas. It's far more far more about. Execution and the key to this lean, uh, loop, uh, that we talked about in the previous episode, the key to making all these iterations work is learning. So [00:01:00] it's okay. If you don't have all the answers at the start. In fact, that's the essence of working in a lean and agile way that you won't have all the answers, however, you're on a quest to get them.

So the first rule. Of the lean startup is don't assume anything, make sure you test learn and validate and you know what you can actually test from day one. And that's the power of lean startup. You can test things like. Uh, the user problem, uh, the idea you have for the solution or how the experience of providing that solution may in fact work.

And there's a great tool set of tools, actually, a set of canvases that can kind of capture all of these learnings and they can be your North star to keeping on track and avoiding all the pitfalls of building a new product. So I want to tell you a little bit of a story about this idea of challenging all [00:02:00] assumptions.

And I've chosen to kind of famous lean startup case studies. One is with the, uh, shoe, uh, retailer Zappos, and the other is with Dropbox sort of unfair management, uh, service and both of them challenged assumptions. And here's how they did it. So is that part, um, Back in the day, the idea of people actually buying their shoes online and not going into stores was kind of a crazy idea.

And so Zappos could have made this huge mistake. They could have gone and bought a ton of shoes, put a ton of them in a warehouse. Can you imagine the expanse of all that warehousing distribution, inventory management, and so forth, they could have, you know, Encountered all of that risk, but they did something very different.

They used what we call a concierge MVP. They [00:03:00] basically tested the idea. They actually went and really just tested this whole assumption, uh, where people actually buy shoes online. So here's what they did. They went out and they built a very simple, rough and ready website and they held absolutely zero inventory.

In fact, one of the founders made a deal with a local wholesale shoe provider that they could photograph all their inventory. And if someone bought it online, they would actually go to. The, uh, the shoe company and, uh, purchase the shoes there and then, uh, shipped them off to the customer of zappos.com.

Now at first sound, this sounds really crazy to do what we call this concierge MVP, where you're basically doing everything by hand. And obviously one of the issues would be you'd be making very little money, but that wasn't really the point, the point of this test of this little experiment. Was how can we in a low risk [00:04:00] way test to the assumption that people want to build shoes, buy shoes online.

And so to certain point, they got so much interest. So many people buying that they knew, hang on a second. Were onto something, but they only invested in all that subsequent infrastructure and people, once they challenged the assumption, once they tested, once they learned, once they validated and they used this idea of a concierge MVP, and this is essential, lean startup thinking.

But let's take it even a level further with Dropbox. They didn't even concierge their experience or their service. They made a demo video, which they published in September 15, 2008. And it was. A fake product. This product could not be downloaded and used. It was a mood video. It was a concept video. The prototype was inside of the video.

Nobody could use it and they published it [00:05:00] and hundreds and hundreds of people saw it. And literally overnight, they got tens of thousands of people signing up. On their wait-list for the product, because just seeing the video was so exciting, it solves such a problem for them that they've got fires all over the place and they need some way to synchronize all these different files.

Dropbox knew instantly that they had to hit, they hadn't deployed the software, they hadn't incurred all that cost. They made a demo and you know, this is what we call the wizard of Oz, MVP, and other great lean startup concept. And this is all about just creating the illusion of the actual. Product that you intend to build, but you build a quick video just to check.

Hey, do people really want this? And this goes at the heart of lean startup and this idea of that we should always be learning. So what I want to do for you now is give you a little [00:06:00] framework of three sets of tests that you can be using all the time. And I hope that this helps you kind of frame the sort of tests and so that whatever stage you're at you can apply some of these tests so that you don't make the assumptions that lead to.

Bad products. All right. So what are these types of tests? First one you can do is you can kind of test, do users really have the problem you can test. What kind of overall need or jumps to be done does this fulfill, and you can start to play around with what if this solution existed? Would you be interested?

And all of these can be tested in surveys and interviews, or what's formally called a quantum qual research. And so the great news here is you can dip your toe in and actually see if there is a, um, some, some leading indicators. If you will, as to whether this problem really exists now. Let's assume you did those.

The next thing you could go and do is [00:07:00] start to actually test your product idea. And we talked about some of the concierge, a wizard of Oz, MVPs, some other things that are really classic, lean startup thinking you could create a landing page. For the product, which isn't, which isn't available yet, but you can test demand through the landing page.

Another one that can be really valuable is you could set up a go fund, me or a Kickstarter page for the product where you actually ask people to donate and look, frankly, if people see this proposition and aren't prepared to donate, well, then maybe you need a different product. So the whole idea here is that without building the actual product itself, the second bucket, uh, gives you the chance of testing your product idea without that time, effort and investment.

And the key thing here is that Eric Reese, the author of lean startup, he's like, you only want to build it once, you know, there's real interest, demand, desire [00:08:00] for it. And so very often. People build products that are not solving a problem that users actually have, or maybe it is solving a problem. That's not very big.

All of these tests that I've just mentioned will help you get a better feeling for, is this a problem worth solving? And it's a really important concept. Is this a problem worth solving? Now, let's assume you did a little bit of a survey in an interview. You tested the product idea. Now you want to shift into a different type of testing, some sort of prototype testing, and there's two things you want to test for here.

The first one is you want to test, uh, can users get the task completed? That's at the core, the essence of your product. And if you're building software, you know, I would really encourage you to use envision or Adobe XD to put together, um, a mock-up a prototype sort of a model or a sketch of the solution that you're envisioning.

And you will act...

Hello and welcome to the bottom-up skills podcast and my passions own the CEO of Qualitas. And boy today we've got a whole series. We've been to design thinking and agile, but today we start on a totally new chapter. We're going to do a multi-part series on the lean startup. And frankly, I'm quite the fan.

Of the lean startup. So in this episode, I want to lay some context. I want to give you a little bit of background to lean and what I'm going to hope to do is point out to you what really defines it, um, as a great. Method to use when you're going out in the world to build a brand new product. All right.

Let's get into it. And the [00:01:00] story starts with a gentleman called Eric Reese who wrote the book, the lean startup. And I really want to share with you the most compelling part of his kind of founding story. And, um, it all starts. With failure. And that's why it's so interesting. He spent five years as a co-founder in a startup.

They spent over $40 million in funding and they built a product. They didn't nobody wanted to use. Now for many of us, this is a bit of a heartbreaking, it's a bit of a gut wrenching experience to spend so much of your life building a product that it turned out that nobody really wanted, but being ever so stoic.

Eric actually used it as an opportunity to kind of dig into the, you know, the [00:02:00] rapid process improvement universe and dig up this, um, Idea of lane and to really reinvent it through the eyes of a startup and those startups are generally software based and moving fast in the modern age. So I cannot tell you how powerful this is as a starting point, because he's literally written a playbook that has.

Taken off it is absolutely, uh, a global phenomenon now in anyone. So largely not only in the venturing world, but the product world, even in the enterprise world, you will find that not only are people trying to be agile, but they are trying to be lean as well. So I'm very excited to share with you what he put into the lean startup and how powerful it really is because he's effectively.

Written the book he'd wish he had read at the start to avoid [00:03:00] those five years and wasted $40 million. So let's look in to the learnings from Eric Reese and the lean startup. So what is this thing? Okay, so it's a methodology. So the good, good news about methodologies is they tend to be step one, step two, step three.

They tried to be repeatable. And that's certainly the case here with lean startup and is particularly good at building products. People use it for building businesses as well. And, um, Sure. That's, that's fine. I think it stands alone as a great way to build product and it needs to go hand in hand in hand with many other practices, but I'm going to try and pick apart what it's very special at and where it contributes so much value.

So. As I said, it's a methodology for building products and it's, what's really important is we emphasize building the [00:04:00] right product. It's very fast. It's very iterative process. And it really strives to determine is the product viable. And, um, viability is an, a very important, uh, topic because if we really go and ask ourselves is something viable.

We're saying really are the economics going to work out? Can we capture enough value now to reinforce you? What? I think this is so important. It's actually, it's not that hard. To build a product that, you know, users find desirable, but where it really becomes challenging is, is it technically feasible? And from a business model perspective, is it viable and lean is so damn good at helping us work out.

Is this a product? And here's the keep it, is it worth building? This [00:05:00] is really, really important. Um, nuance in it. Is it really worth building? Because I know I've personally made products that may have been either. Feasible, uh, or desirable. Um, but that doesn't guarantee it's going to be viable, that there's going to be a good economic model.

Value's going to be created. Customers are happy and willing to pay for the product or service. This is where lean helps. And what's so special. And why I love lean startup so much. Is this all about learning? It's all about this journey. That is defined at not by, you know, do you have like this amazing idea, right?

Um, it's this total fairytale that we're told that someone has an idea and then that makes them a gazillion dollars, lean startup acknowledges the hard truth. It's in the execution. And to take you back to Eric's [00:06:00] story, he spent five years and $40 million learning that he didn't get the execution. Right.

So if you learn along the way, You are way on track of forgetting execution, right? And therefore, what's so great about, uh, the lean startup. It doesn't matter how little, you know, at the start, what really matters is your rate of learning. And that's why it's so, so damn important. So to frame this, before we move on to some of the important aspects of lean startup, this is a way to know.

If your product's gonna make enough money, is it truly worth doing? And this is essential because actually, you know, the barriers to entry to building product have diminished. So there's a lot more products out there. And there's also quite a lot of products that are no good, but that's a whole nother course and masterclass and discussion here on bottom-up skills.

So. Let's have a [00:07:00] look at some of the surrounding practices around lean that you may have heard of perhaps, um, you know, you may have heard of, um, lean manufacturing, which goes, has a lot of heritage in, uh, Japan. Obviously it intersects a lot with some of the, the agile practices at, uh, Toyota motor company.

So, you know, definitely check that out if you're interested in it. It also has another intersection with agile in terms of the practice of Kanban, which is really focused on, um, feature driven development. Um, traditionally not very time-boxed. Um, now another couple that you might have heard of is, uh, just in time, uh, just in time manufacturing, um, you know, this whole idea of trying to only consume the resources at the very end, and this is perfect because then you're not left with a whole lot of inventory [00:08:00] just sitting around in a warehouse.

So there's a lot of, uh, process improvement, um, and agile connections with the lean startup. And if you're at all interested in any of those, just have a look at that greater world of the lean method beyond lean startup, what we're talking about, but go into the lean method and you will find a world of different methods and practices there.

So let's come back to software. Cause we talked for a moment then a little bit about, you know, manufacturing. Um, and some of the other related practices, lean startup is largely and foremost for software. And prior to lean startup, the way a lot of software got built was using what we call the waterfall process.

Now waterfall created all sorts of nice structure and certainly in people liked it a lot. You'd start with writing and requirements, doc, what does it need to do then? You write the specifications of, okay, this is how we think [00:09:00] the system, the software will do it. You design it, you implement it. And then once it's implemented, you do some testing before you launch it.

Now in this day and age, that's pretty crazy. And there was all sorts of bad habits that got, uh, related to the world of waterfall. First and foremost, people would write a requirements that were. Uh, between you and me, they were largely just one big guests. And, um, often in, particularly in large organizations, because we have agreed the requirements in the specs, that's what we promised to the boss.

Hello, and welcome to the bottom up skills podcast. I'm Mike pass and zone the CEO call the tents, and we are here at the final destination of our rapid prototyping series. And I thought, you know, we've been insanely practical for the last 10 plus episodes of this series. Let's step back a second and ask ourselves, why does rapid prototyping matter?

What on earth is this all about? Let's just remind it. When we're talking to our colleagues, to our friends, to our bosses, let's just remind them why this is such a great tool and why it's so relevant. If you're out there building a new product or service. So where do we begin? Well, [00:01:00] I think the elevator pitch here is when we think about why does it matter?

What is the value it creates? What is its purpose in the world? What, what, what is rapid prototype been doing for a soul? I think it's about the shift. It's from the shift of guessing what a great product might be to knowing what a great product is. And the power of this is that invariably, most people, when they sit in a boardroom, they get out PowerPoint and they guess what a product should be.

In fact, Sometimes hundreds of thousands, millions of dollars get spent on nothing more than a good PowerPoint deck with some groovy icons, some funky fonts, and just a guess. And that's so good and well, um, [00:02:00] you know, but you know, those ideas, in fact, this is really crazy. So many of the biggest products in the world.

The original idea they had was completely different. YouTube, Instagram. They were completely different things before they became these zillion dollar successes. And so even the best product people in the world are guilty of doing a bit of guessing. What it turns out is once people actually get a chance to use your product.

You start to know what actually solves the problem that they have, what helps relieve pains? What, what helps create gains, um, and rapid prototyping is the agent to move from guessing in the early days. To knowing. And I think, you know, who wouldn't want to do that because as a startup, then you actually know if you've got something and as an [00:03:00] executive in a large company, you can de risk your project.

I mean, fantastic. So it's all about giving us so much more certainty about the product services actually going away. And the reason that this is so cool is you don't have to go out and build the entire. Before you can actually test it. You can actually start testing immediately from day one. And this is great because if you just build like a model or a sketch, some sort of light version of the idea, you can actually get some great feedback.

And so you can start learning from the beginning and we can avoid that old school waterfall approach to building product where people spend so much time and effort only to realize they've built something that actually nobody wants. In fact, the creator of the lean startup, Eric Reese, he talks openly [00:04:00] about the fact that what inspired him to write the lean startup, which loves experimenting and prototyping by the way.

What he did. And he confesses that he was part, yeah, he was a founder of the startup that spent five years, $40 million to build a product that nobody wanted. Now, if you want to avoid that, regardless of whether your startups scale up or large enterprise start rapid prototyping, stop guessing. Start really knowing what people want.

And, you know, I've seen this across so many different types of companies, you know, I've personally been involved in rapid prototyping projects and products, which were for small startups. Well, for some of the largest companies in the world. So it works for everyone. And I just want to kind of double click on this and [00:05:00] tell you that I've done everything.

I've tried to think of the craziest variety of products that I've actually used rapid prototyping on. And this is, this is like, this is as crazy as it gets. This is the breadth. Of, uh, businesses you can apply rapid prototyping to. So I have done high-tech biometrical authentication for a bank. I've done media prediction algorithms for a consumer goods company.

I've done cancer detection devices for a large healthcare company. I've even worked with a famous fashion brand to create a whole new pair of jeans. And at the heart of all of these was rapid prototyping. My point here is simply it can be applied to anything, algorithms, high tech security, medical devices, genes.

Of course the easy [00:06:00] one here is like apps, products, services, digital SAS kind of things. Um, but it can be so much more than that too. So rapid prototype, I mean, anything can be prototyped. Take it from me. As long as you use the principles that we've set out in this whole series, uh, which we also said yeah, in our master class, which you can get for free online at.

At bottom-up data here and you'll actually be able to take the mass class for free as well as many others. So that's bottom up.io where you get to enjoy, uh, as going even deeper into masterclass, into rapid prototyping. So, yeah. It can work for anyone and it can work for anything. And the real hot of, of rapid prototyping is the chance to create something with the end user.

And it is a tool that you will find yourself coming back to [00:07:00] time after time. And do you know what, whenever you want to do something new, prototype it. Whenever you have an idea, ask yourself, how can I test it? How can I validate it? How can I learn if it really is the right thing, because too often people are leaving this validation way too late.

And look, I think if you're going to pivot pivot while the idea is still a sketch on a piece of paper, um, don't pivot once you've written the code, I want to come back to this story of Eric Reese, author of lean startup. He talks so much about the idea of experimentation and about validating. And this is what makes rapid prototyping.

So damn important. It's a leading central character in the movie of validating your product. And what's so [00:08:00] fun is you don't have to be a guru in Photoshop or illustrator. If you. Pretty handy with a pen and paper you're so on the way to doing great prototyping. So, this is really a tool that you can put in the tool belt.

And this is something that will take all the mystery and all the risk out of moving forward and doing the unknown cause Hey, building a first time product isn't easy. Yeah. Maybe you can take some inspiration. You can borrow from. A few products and services you've seen before, but you've got to pull it all together for the first time.

And that's where rapid prototyping is just so damn good. And I can tell you my last thought here is that I couldn't believe when Tom Shi. Introduced me to rapid prototyping and all those years ago, back in San Francisco, I was like, Oh my [00:09:00] gosh, this is the thing I've been looking for. How do you know if you've got a winner?

And he showed me how to prototype. You spent years at Google prototyping. And it was so revealing when he showed me rapid prototyping. And ever since then, I have been prototyping. All the time, every new product that I've been involved with, we've built prototypes. We've tested with users. And I can only tell you that's not only a great way to do rapid prototyping, but yeah, his whole methodology, this whole framework we have with bottom up rapid prototyping is at the very heart of it.

So I hope you've enjoyed this series. I've got a very exciting series coming up after you can have to come back and have a listen to that. If you want to know what that is, it will be at least as good as a rapper prototyping. Maybe a little bit better. So there you haven't, that's another episode of the bottom u...

Hello, and welcome to the bottom up skills podcast I might pass since I'm the CEO of quality science and we are at the second last episode of our rapid prototyping series. Here on the bottom up skills podcast. And today we're going to talk about one of the most important things around rapid prototyping, and that is working uses this real, real, real underestimation of what it takes to get users working in the right way with you to give you good.

Clear objective feedback, because let's be honest. We don't want them to tell us it's great. If it kind of sucks, we want them to give us great feedback. So how we approach the users that we're testing with, you might call them [00:01:00] consumers, customers, end users, audience, whatever you want to call them. It's all about how you work with them.

And I've learned a few key lessons, uh, having done so many of these rapid prototyping sessions. What I'm hoping to do for you today is share with you some of those learnings so that we can get the most out of rapid prototyping. Cause I truly believe this is an, in such an incredible tool to use when you're on the journey of building a new product or service building a business, no matter what it is.

Rapid prototyping really is a powerful tool to know if your product is actually, if it's any good. So let's start by making sure we're on the right page here. We've got to make sure before we kind of talk about how we work with them, um, which is to make sure we've recruited the right people to come and test our prototype.

[00:02:00] So you might have, um, some basic demographic criteria, you know, age, uh, where do they live and that sort of thing. And it's really important to make sure that you actually verify that the users you're testing with meet whatever demographic criteria is that you have. Um, Now another thing is that, um, just because they're a demographic fit, they might have zero need zero interest in the product that you're trying to test.

So you may want to screen them for what segment in your audience that they are in. And that is generally going to be whether they're in a consideration phase of purchasing a product or service, or maybe some more. You know, attitudinal, um, uh, vectors, like what they like, what their interests are, um, what they believe in, or, you know, you might even have behavior stuff.

So, you know, if you're targeting, for [00:03:00] example, uh, you know, young mums, um, that's like a really important life stage, which creates new behaviors. So you gotta make sure that, you know, the people that you've recruited are actually mums because that's the way you're going to get the feedback. Before we talk about, uh, how we work with them when they turn up on the day or whether they turn up on a zoom call to be a part of our testing, let's make sure we've got the right people in the room because we don't want to go to all of this work and effort and do all this great testing.

I need to realize we tested with the wrong people because that's. Can I make the learnings pretty pointless. Uh, so make sure you got the right people in the room. Okay. So they're in the room. Now an interesting tip that I would give you. If you're going to do a big prototyping session, maybe you've got a bunch of your colleagues, a couple of teams testing, different variations of an idea.

I think you should really have [00:04:00] a green room, uh, which is. A place where you can sit them down, where they can't really hear and see too much about what's going on. Um, that way then you can check them in, take care of them, make sure they understand the purpose of the day and so on and so forth before you bring them in for the, to the team for real testing.

So have a green room that works at amp. So treat. Now, um, what you have to remember is that when people are coming to test your product, to have a look at your prototype, you know, They're humans. I mean, it's a crazy idea. Yes, I know. But they're humans, so say hello, greet them, find out their name, give them a name tag.

Um, make them feel comfortable and the importance of them feeling relaxed and comfortable and that this is not some strange unknown dangerous event, but it's just a bunch of great product people trying to learn how to build [00:05:00] the best product. Once they realize, uh, that this is, you know, actually an experience that can be really fun and interesting.

You'll get along the way with them. So I make them feel welcome. And just on that note, you know, the crazy thing is invariably, I find customers. I really find it rewarding to come and test prototypes. Number one, somebody is actually really, really deeply interested in their feedback, which doesn't happen a lot.

And number two, I think they feel like they're making a contribution to a better product and they really are too. So this is why making them feel comfortable is really important. Now, another big part of setting your user up for success when you're in a prototype with them. Is to give them context, context, it's context, context.

This is really important because. We're often. So in our own minds, in our own heads with [00:06:00] our product that we know, uh, automatically, uh, what situations would call upon them, but your user, your user doesn't know. That information. So you need to provide them with the context and at the start of getting, uh, the direct feedback, that direct response from them.

Uh, you need to actually give them a task to do. I want your feedback on this user journey. I want you to write down 10 cards. I want you to tell me what the total loan amount that you can get from your mortgage using this mortgage calculator. Those are great, clear, explicit tasks that help people. No, where they are, what they're trying to do here.

Now, importantly, once you've given them the task, you might say something. Like it's nine o'clock on a week, day. You've got 30 minutes [00:07:00] before your next meeting. And we want you to use the online mortgage calculator. Tell us what the maximum amount you could get it. Now, there might be some other constraints.

Um, you know, you might do this test on a phone. So you say you're on the train, you're on the bus. Um, you can give all of this sort of context, but it's really important because if you give them this context and maybe you have a few props. Where you're testing your prototype. This is the secret sauce. So this, this is where you evoke the direct route response.

Cause you transport them to that world into that moment. So they feel like it's nine Oh two. I got the cup of coffee and they've got 28 minutes. To get this number before their first meeting of the day. And you will be surprised. The biggest learning that I have is that you don't need to put them on a train to get that experience.

Although that would be like incredibly fun. You can create an environment where they can [00:08:00] imagine it and feel it like it's the direct moment. And why, why does this omerta because if people are feeling comfortable and they're really seeing themselves trying to. Complete the tasks they're really clicking.

They're really thinking out loud, helping you understand how they'd go about it. You will find that they can work with sometimes just 20 or 30% of the actual environment in order to evoke this direct response. And the key thing. Because they're comfortable and they have the context, their feedback is not them guessing what it would be like to use the product.

It is evoking the response as if they're using the product. And this ladies and gentlemen, this is the secret secret secret to why rapid prototyping is so powerful. You create this light version of the product idea, like a sketch. And then yo...