S1 E15 | Understanding Prototyping to Learn

The other part is you start to realize there's, there's role what I call the roles of prototypes. You know, there's a learning prototype, there's a communication prototype, there's a milestone prototype. There's different ways in which I like. So for example, a milestone prototype is the number one mistakes that a lot of people make when they go build something and they try to bring it back to management to show them where they're at is they never bring the old prototype and the new prototype to the table to say, here's the progress we made. They just bring the new one. So nobody. And all they know is how far away they are, not how much progress they made. And so communication prototypes are. For example, in a lot of cases I would do a communication prototype to actually help interface like between the engine and the transmission. I need to communicate about what's the interface look like, what does it really mean? And so part of this is being able to use it to actually have language and conversation around the critical aspects of the interface between things.

Welcome to the Circuit Breaker podcast where we challenge the status quo of innovation.

And new product development.

We'll talk about tools and skills and methodologies used to build better products and make you a better consumer. I'm Bob Mesta and I'm the co founder of the Rewired group and I'm one of your co hosts and we're joined by Greg Engel who is my co founder and chief, Bob interpreter. Join us now as we trip the circuit and give you time to reset, reorganize and recharge your brain to build better products.

Hey Bob, Today what I want to do is I want to take a deeper dive into one of the skills that you wrote about in your book. I know we covered in an earlier episode kind of the broad of all of them, but I want to take a deeper dive into one. Okay. And I want to take a deeper dive into prototyping to learn.

Okay. My one of my favorite topics.

So first, can you just give a give a brief description of what do you mean by prototype? What does prototyping mean to you?

Right, so prototyping and prototyping to learn are connected in the context of like I'm going to build something or make something or think through something so I can find out what I don't know. Right. And so prototyping to learn is really about this aspect of like I think Ryan Singer talks about a spiking. How do I spike something up so I can actually then figure out what I don't know around it, right. And then ultimately, when I figure out what I don't know, how do I then prototype to actually fill that space? Like, what do I know, what don't I know? And then how do I actually build a set of prototypes to learn what I don't know and then answer those questions? And that gets back to what I call divergent prototypes and convergent prototypes. Right. Divergent prototypes help me see the spectrum, almost the boundaries of where something might not work or where it will fail. And convergent is about helping me kind of optimize against or manage the trade offs, if you will, between kind of a whole bunch of different factors and cost and performance, et cetera. And so it's a series of actions where I build sets of prototypes to help me understand what to do. And what's interesting is the way that both I was taught and I think the way that the, you know, the general notion of prototyping is we use something called prototyping to verify. And so we build a prototype to verify our hypotheses or what we think is the best thing. And then we, you know, when we get the results, we go like, oh, like, okay, now what should we do? And my thing is, is it's way easier to build sets than it is to build one and then build another and then build another, because we don't actually build a cumulative knowledge.

Okay, so you, you lost me a little bit. So let me, let me see if I can unpack, unpack a little bit and kind of fig. So you talked about divergent and convergent prototypes and you explained them a little bit. But I want you to explain a little bit more. In what situations would you use divergent prototypes?

One way is to think about kind of as I'm trying to figure out what to do or where to go. Here's a good example is in sales, I use divergent prototypes as a wide thing, like 2, 3, 4, 5 things I might actually take to a customer so that are very, very different. So they can actually use that contrast to help understand what they want. And so this is where I would bring like, well, we can do it this way or we can do it this way or we can do it that way and ultimately they can actually eliminate to actually then help them pick.

But how different do they have to be?

That's. See, that's the key in divergent prototyping. They have to be very different where most times people make small little changes like, okay, we can do this one. And like, so, for example, three different proposals of way ways we can work, right? One is like, you know, so for example, I work with a company called Auto Books, right. And what we were able to do is build out three really different ways in which they can engage with autobooks. One is if you want custom, you know, you want your logo on, on the software that we're going to plug into your bank, right? The fact is, and you want to be basically have it, have your logo on it and you want to basically make it sure it does this, this and this. And it's connected to your system in this way. It's, you know, eight weeks, it's a million dollars. And you know, it's. We need these kinds of people involved. But if you want to try it, we can actually white label it and literally have no logo on it, but literally see if people will use it. And we can do that in two weeks. But the price difference is that, that you don't pay anything upfront. But our fees are more on the transactional, on the transactional side for the small thing and they're actually less on the bigger thing. And so that contrast of prototypes help them understand is this more about speed? Is this more about actually money? Is this more about actually making sure the brand is there? Is this more about trying it out like what do, what do they want to do? And so part of this is the, the diversion. Prototypes are actually more about helping people eliminate what they don't want that then help us build the criteria of what they want.

So you're talking about factors or things or levels you can change in that, right? So how many different levels should you be changing in a divergent.

So, so one of the things I. So the, the very most fundamental way is what I is, is the phrase I always use contrast to create meaning. So how do we actually have three or four different things? Because it's the, it's, it's not one thing and sometimes it's not two, but it's a minimum of always three for me. But when you get to really understanding it, there's a whole body of knowledge called design of experiments from R.A. fisher in the 1919s, to be honest. And I learned it from Dr. Taguchi, who is one of my mentors. And we learned how to actually frame systems or frame situations and then basically understand the variables we can change in it. And you can have 2, 3, 4 levels of each variable. But ultimately can we actually then build a wide range of prototypes so we can learn? And that's really kind of the origin of where a lot of the prototyping to learn stuff came from. And so he has something called control factors which are inside the system, the things that we can control and set. How do we know which is the best place to set that parameter? So an example here is very early in my career I worked on injection molding of a mirror case for the rear view mirror for a car. And one of the problems we had is that was shrinking too much. And what would happen is it was actually turns out to be that it would shrink and it would, the lens of the glass was, would kind of snap into place, but when it got hot enough, it would expand. And so part of it was we could, we could upgrade the materials, but the other thing we could do is I could actually mold it a little bit differently so it wasn't so sensitive to temperature. And so part of it was then going in and saying, well, I know how to create the perfect dimensions, but I want to make sure that I can create the right dimensions and have it not expand or contract through temperature. And ultimately we were able to solve the problem without increasing the price. And in some cases we actually increased the productivity of the machine because the things we thought were going to have an influence didn't.

So are in divergent. Divergent prototypes. Are you trying to find the trade offs in a customer system and you're trying to find the. What are you trying to find in a. In that last example? Yeah, in more of a manufacturing.

Well, I would say it's on the supply side. So it's I think of prototyping as a tool I can use on either the supply side or the demand side.

Okay, so now you have to unpack those two words.

Okay, so the demand side is what causes people to say today's the day they're going to actually try something new or pull your product or service into their lives. The supply side is basically how do we build that product to be cost effective and deliver what the customer wants and at the same time make sure that we can do it in a consistent way.

Are prototypes doing both of those all the time? They are, depending on how I set them up.

That's right. And so part of this is to realize most people are trying to do one thing, they're trying to do it all at the same time, or they're trying to say like, I know what the best thing is, let's go test it. And so they don't actually understand the difference between trying to see a range of possibilities on the supply side and a range of possibilities on the demand side. And I might actually, they might not be the same types of prototypes I use on the demand side versus supply side. So there's some work we do that's around jobs to be done around prototyping. Right? It's the prototyping job where we know what the job is. And then what we do is we bring actually a wide range of prototypes or samples to the table. And as we talk people through.

Their context and the outcome they want, and then we show them the product, they can actually go, oh, that one I would never use because of this. And oh, that one I would use. But you know, I think it's this way. And so it allows them to actually start to talk about, fit in a very, very.

Discreet and concrete way.

And that's what we call benchmarking or we call competitive benchmarking. Understanding. Understanding how people choose between the things that could be in the competitive.

That's right. And so our version of benchmarking isn't about how good we are or how bad we are. Our version of benchmarking is actually about prototyping to learn so we can know what the right criteria are when they're in this context.

Because many different things can fulfill a job. I'm not just making a peanut butter and jelly sandwich. And that's my job as a peanut butter and jelly sandwich. It's food.

That's right. That's right. And so part of it is, is like this is where you can compare an apple to an orange, right? And, and so most people want to compare just the way it tastes. But, but when you think about an apple, I don't have to peel it, right? I can eat it right right away, I can eat it without a knife, I can cut it. And so part of it gets back to kind of what's the context you're in? And when would you actually pull an apple and when would you pull an orange? And you start to realize like it's different contexts.

So that's divergent. So what about convergent?

Convergent is on the other side of this, which is really about being able to. Some people would call it optimize, but I actually call it, I would think about it as being able to manage and identify the trade offs. And there are, in any system there are always constraints and, or things that, that when I make it stronger, right, it gets heavier, so I can't make it lighter. So making it stronger and lighter is different, right? Like it's very hard to do. And so part of this is realizing that where are those things that are Bounding us that we actually have to realize we have to make a trade off. It either can do this or it can do that, but it can't do both. Right. I can make the performance better, but it's going to cost me more. I want to actually get the performance up and the cost down. That's where I would do convergent prototyping to help me see the pro, the way in which to do both.

So it sounds like those two things are why we're doing the prototyping, what answers we're trying to get out.

It's all about framing questions now.

What are the types of prototypes? Like, you know, I know there's physical prototyping.

Yes.

That I actually have a product and I'm going to show people. So what are all the different types of prototypes we can deal with?

So there's dimensions of prototyping. As I think about it, one is there's, there's a comprehensive prototype, meaning it's, it's. It, it include. It's basically includes everything. Or there's a focus prototype which is focused on one aspect of it. So I understand how it works.

So when do you use a comprehensive.

So a lot of times I need comprehensive when I go to the customer because the customer will actually judge something differently if it's not complete. Right. Another part is I use comprehensive when I'm trying to actually figure out how things interact or when I assemble things. So a lot of times I can put the brakes on the car, I can put the engine in, I can put the transmission and I get them all to work independently. But now I actually have to know how they work together. And so I have to do a comprehensive prototype to help me understand how almost the things I don't know about when they're there versus focused is like I'm going to work on the transmission and make sure that it's actually as efficient and effective as possible. Given the inputs it gets from the engine and the output. I want to be able to get to the, to the wheels. Right. The other part of this is that there's physical prototypes.

How is that different than the other you talked about? So you talked about comprehensive and then.

You use comprehensive and focused.

Then what is focused?

Focused are those ones where I'm going to focus on the transmission and optimize it to fit into the environment of the engine and the wheels and be able to understand how to optim. Like I have responsibility for the transmission. I can't actually do anything about the engine. The engine. I have to accept the Inputs from the engine or whatever. And so part of this is to realize that I have a very, I have very strict boundaries around it. Right. And so to me, it's, it's being able to say, do I need to do a focus prototype or do we need a comprehensive prototype? Focus prototyping is faster.

Right.

And so part of this gets back to, from a time perspective and a knowledge perspective and what I know and don't know most of the time, what I'm doing is a lot of focus prototypes to then do a comprehensive, to pull it together.

But the focus prototypes seem like that's more in your words, earlier, supply side.

Yes.

Because they're all smart. Can't really see that.

Right.

It's not complete enough for them to do anything. If I'm talking about food, I might be talking about a sweetener system or I might be talking about preservative systems, and I'm breaking those apart. And the customer doesn't care.

That doesn't. Well. And they might be able to perceive the differences. Right. And so part of it is being able to understand because the preservative is there to make sure that bacteria doesn't grow.

Right.

It's not there. And what we really want to make sure is that the preservative doesn't affect the taste or the texture of something. That's all. And so part of it is that that's why we might end up doing a comprehensive. But we got to make sure that this preservative actually works in our cookie.

So that kind of goes with the philosophy of the divergent convergence. It's kind of what are you trying to do?

That's right.

Are you looking at the complete thing that you have to give to somebody or is it more for your learning?

I think the other, the other dimension on this is what we would call physical versus analytical. Right. And analytical is where I might model it, and physical is where I would actually kind of make it and test it in the real world. And so what you start to realize is that what you, you need, you, you need a whole range of those kind of focused and comprehensive as well as, you know, analytical and physical. And a lot of this comes from Ulrich and Eppinger and their book around product development in terms of. I learned this in the 80s around basically how to, how to be very clear about my prototyping strategy to get to what I need to basically bring to market. And I need to prototype both on the supply side and the demand side to then put it together.

But what I'm hearing is as a manager, as a person guiding project teams, as a person in charge of development, I need to make sure my teams understand what is the purpose of the prototype. Because there's many different decisions I have to make. I can't just say, go make a prototype.

Right. So there's. There. The, the other part is you start to realize there's, there's role. What I call the roles of prototypes. You know, there's a learning prototype, there's a communication prototype, there's a milestone prototype. There's different ways in which I like. So, for example, a milestone prototype is the number one mistakes that a lot of people make when they go build something and they try to bring it back to management to show them where they're at is they never bring the old prototype and the new prototype to the table to say, here's the progress we made, they just bring the new one. So nobody. And all they know is how far away they are, not how much progress they made. And so communication prototypes are, for example, in a lot of cases, I would do a communication prototype to actually help interface, like between the engine and the transmission. I need to communicate about what's the interface look like, what does it really mean? And so part of this is being able to use it to actually have language and conversation around the critical aspects of the interface between things. And so part of it is being very purposeful and how we actually take the time to understand when we're going to build something or we're going to try something, what are we trying to do? What is the purpose of it? What is the best strategy to. Should we be using divergent sets or convergence sets? Should we be comprehensive or should we be focused? And should we do physical or analytical? And so there's decisions you have to make as you go into this. So to me, as a manager, what I'm always asking is, what don't we know? What do we need to learn from the prototypes? And basically, what's going to be the best and fastest strategy to actually get the right set of prototypes together?

Yeah, and those are pretty broad questions. So I want to break it down to a little bit more concrete questions people can ask, which is what are you trying to learn? You have to ask the team that.

Or it has to actually start with what don't you know what question?

That's actually a really hard question for people. And you can get away with asking that question and you can help people coach that through. But if you don't know those things, you still, you have to get on what we know first before we can absolutely see what we don't know. What we don't know is night vision goggles. Right? That's the stuff that we don't. You have to be really aware of what you know to know what you don't know. So you have to be self aware first. So it's really what question you're trying to answer, like what will this prototype tell you, why are you doing it, who is it for and what do you hope to learn from it? And if you can do that, you're basically going through the questions of does it need to be physical or does it need to be analytical, conceptual, does it need to be focused? Because if it's, if it's for my learning, for our internal learning, I usually don't need a really comprehensive one unless I'm really close to launch. I mostly need probably more focused, more. What are we trying to actually do? If it's internal thing, if it's external, then I'm probably going to want more divergent, I'm probably going to want more comprehensive and I'm probably going to want more physical. Because to have a customer or someone that's going to go use it, have to use their imagination is hard because they tell you things that they don't really mean that. Yep.

I think, I think the other thing to realize is that is different industries have different standards of how they can make changes. Right. So like trying to change a thing in a car is really hard.

And a long time.

And a long time. And so part of it is that's why we do a lot of analytical focused prototypes. Right. And we're like, we're not putting the, we're doing a lot of stuff in parallel to then kind of bring it together and integrate. Right. Versus when I'm, when I'm making pickles. Right. I can make a batch, put a salt in. Okay. I put more salt, second batch has more salt. We tend to, a lot of people don't think through a good prototyping strategy because it's just easy to make another batch. And so this is where what we would say is people, this is my word, not yours. But I would say people are lazy because they think that the fact is I'm just one prototype away and this is, this is going to be it. And then they get it and it's like, oh, that's not it. Okay, we'll do one more and. And they, they end up creating 3, 400 prototypes, but they're always one prototype away from getting there.

And what we would say is if, if you're talking about one prototype, that's not prototyping.

That's right, that's.

That's verifying.

That's manufacturing.

That's right, that's verifying.

That's not, that's not prototyping. Prototyping should be multiple things because you.

Have to learn and very different things. Where manufacturing is building one thing, am I going to build the same thing?

And even with pickles, that still takes a long time because it's food, right? But think about software. Software is very quick. It's, it's relatively easy with little regulation. So prototyping in that, a lot of people just fly by it. But think of all the mistakes people have made because of that.

So, so this is where my belief is that if you look at the amount of code that's generated, so Deming would always say the quality, like how do we understand the quality of the code? And you start to realize that, you know, 80% of the code that's generated doesn't actually end up in the, in the product because nobody's thought through it. And so there are, there are very good, some software companies where, I'll say 80% of the code ends up in it. And they, they actually give their engineers way more time to think about what they're building and why, and they break things down into smaller scopes where very easily. And so part of this is right now, you know, software seems easy, but I actually think it's more of a, a maturity problem of that it's just easier to build it and try it than actually think about it because they don't know how to think much about it.

So we're almost up on the listener fatigue timing, which is about 20 minutes. So I want to give you one thing, and this is going to kind of piss you off a little bit because I'm going to give you a question that's going to take you. It should take you 20 minutes to answer. I'm going to tell you, you have to answer it in like a minute and a half.

Got it. I'll do my best.

Is a B testing prototyping?

So AB testing is. In the world I grew up in, a B testing was known as the worst way in which to test anything. I think of it as like kindergarteners use AB testing because they don't actually know how to frame the system. They don't actually know what else. And so they go like, okay, I have this thing and then I can actually change this and this and this. And here's a B and let's see which one's better. Problem is, you build a house of cards because when at some point in time you figure out which one's better and you do five, six iterations of a B testing and you get to the one that you think is the best, it I, you keep it. But nothing stays the same. So when it goes, oh, we need to reduce the cost or we need to change this, it literally falls apart because you don't know why that thing works. And so to me, a B testing is, is. It's. I'll say this, it's better than nothing. But at the same time, it's, it's a very immature way in which to prototype, to learn. So how'd I do?

Good. It was probably less than 20 minutes. So that's good. It's a good, it's a good start.

Was it more than 90 seconds?

Maybe, but that's OK because we don't follow rules very well here. So that's all good.

We are, we are rule. We are rule breakers and rule makers.

So in the spirit of kind of how we do things, I want to give. I don't really have homework in this episode questions. But, but it's, it's really take the time to stop and think about why are you building something? Because we're always such in a hurry to build things and we don't understand why we're doing it, what context is it going to live in, all those types of things. So I want people just to take this step back. Re. Listen to this episode. Think about the questions we, we were asking and are they actually setting up prototypes to actually be successful or are they just doing them to produce work? And if you're just doing. To produce work, please start over.

Yeah. And listen again to this podcast and.

Go and go through to really know what you're trying to accomplish by using prototypes. Because the worst thing is to spend money on things that are worthless. When you can be spending on money and time on things that are very useful. We want to make sure prototyping is.

Very useful because it is, it is, it's very powerful. And to be honest, the better you get at it, the more you can work on things, everything gets better. When you know how to prototype, it's like, it's, it's a, it's a, it's a superpower.

As always, thank you for listening and hope you found this. Hope you found this helpful and hope to see you in the next podcast.

Thanks for listening to the circuit Breaker podcast. If you haven't already, please subscribe so you won't miss an episode. If you know somebody who's stuck on the Innovation Treadmill, please share it. If you'd like to learn more information, Visit us@therewiregroup.com to find out how we work, how we can help some resources, some books, some software. Join us next time as we trip the circuit breaker to help you recharge, reopening, energize and refocus your new product development.