When I start on the right with inputs, I then look at all the things I can possibly do. And so it actually becomes very divergent in terms of all possibilities. But if I start with the actual end in mind, I start with the outcome I'm looking for, and then one of the outputs I have to generate to get to those outcomes, there's then a very focused and it actually helps me develop much quicker.
And so my experience says that if I think about what can I build given these inputs, it will take me twice as long to build something that if I start the other way, which is what is the outcome I'm really trying to get to and how do I design to get to it. 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 ReWire Group and I'm one of your co-hosts and we're joined by Greg Engle, who is my co-founder and the 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, welcome to The Circuit Breaker.
I'm Bob Mesta, where today Greg and I dive into the Causal Structure chapter of learning to build and Greg slows me down and talks about and unpacks, if you will, what is Causal Structure, why is it so important and how do we use it to help us build things. We ramble around a little bit but at the same time there's some gold in there, so enjoy. Hey Bob. Hey Greg. Today, I want to do a deep dive into one of the chapters of the book Learning to Build. Okay. Which one?
I'm not going to tell you yet, but I'm going to give you some ground rules. Try not to go into tangents. I know you get excited. I know you want to dispute everything out at one time, but we're going to try to take this systematically because we're going to do causal structures. So the first thing I want you to just kind of talk about is why was this put in one of the five skills? Why is Causal Structures, one of the bad word five skills that an innovator should have?
Yep. So when reflecting on kind of like the people I worked with over the years and being able to kind of understand how they innovate, all of them had some form of a causal structure meaning something where a cause and effect was in play. They had some mental model of how something worked and they continually hone and refined it. But the aspect here is that there's not, they're not looking at things as static or kind of just like an attribute but more through space and time.
Okay. So I want to, and the reason why I said I want to do this kind of systematically is because there's three, there's more than three, but there's three big subskills I want to talk about. Yes, inside the thoughts. Yes. And the first one is correlation versus causation. Yes. What is correlation?
Correlation to me is, is the aspect of that, that two variables they are related in some way and they can be positively correlated, meaning when one goes up, the other goes up or negatively correlated when one goes up, the other one goes down. And so ultimately that, but it assumes causation most of the time. Okay. So do you have an example? I know it's tough to call it the example off top of your head, but like what would be correlated?
Yeah. So, so what I was told by Dr. Tukutuchi is a story that for, you know, hundreds of years that in Japan, they believe that the trees cause the wind. And so because when the wind was there, it moved and so they, they assumed that the trees caused the wind and so they wouldn't cut trees down until they understood that, that actually the wind was caused from something else and that the trees happened to move from it.
And so by understanding the true causation behind it, they were able to kind of then use trees for something else. And then what is your, what is your definition of causation? Cossation is, is it's about sequence and time and it's about when one thing changes, it affects something else. It causes something else to change. And so for example, as the temperature goes up, water turns from ice to, from solid to a liquid, it causes, temperature causes it to change faces.
So if we were talking about let's just say tires, because as it gets cold here in Michigan, all of a sudden all of our warning lights come on and say, hey, your tire pressure's low. Yes. What causes that? What causes that is that it ultimately is that in colder temperatures, gases can strict as opposed to expand. It would basically say the same area, so PV equals NRT, right?
Pressure, volume, temperature equals PV, pressure and volume equals temperature times gas constant and the gas, what do you call it? R, the R is the K. Sorry, we can cut that part out. Yeah, well, well. I was just thinking through it. But the reality is that there's a relationship between these things and that they cause each other to happen. And so ultimately as the temperature goes down, the pressure goes down.
But as a designer, I could have said, hey, correlation is, and when it gets cold, tires lose air. Yeah. But as a designer of a tire, I need to understand what's actually causing it because I have to be robust to the heat cold as the, as you start driving it's heating up the rubber, which is heating up everything else. And so am I really low? Am I really not low? I have taken all that.
If I actually look at causation, other than just throwing my hands up and saying, oh, when it gets cold, tires lose air. That's right. And ultimately to build a system or to build something to compensate if you will or to overcome some of those things, you have to build in prototype. And so you have to have some notion of how things work. And so ultimately, causal structures is about the curiosity of being able to understand how things work and building a mental model of how things work.
And then that brings us to our next one, which is a subset of this, which is cause and effect. Yes. Right. And you talk about that in the book. So tell us a little bit more about cause and effect. Cause and effect is kind of like the foundation. I think one of the things that I think is evolved over time was I always thought of like almost very linear cause and effect like this causes that. But then I learned about an Ishaqa diagram or a fish boat diagram, which is like there's
a lot of things that contribute to some output. And so ultimately it's it's understanding what what are the causes that create an effect. And so in a lot of cases, even when we're doing like jobs to be done interviews, I'm listening for is this an input? Is this a cause? Is this an output? What are they talking about when they're talking about things and being able to understand what is a cause? What is an effect? And typically the way I would always spot it is what comes before what? Right.
Typically time and space are the things that help us lead to what is really causing something to happen. Why is it important as a entrepreneur, as a developer, as somebody that's responsible for a product? Why is it important to actually think about the cause and effect? Why should I map that out? Why should I pay attention to it? Because ultimately that's how we build things.
Building things is about assembling sets of things together to actually get some effect and we tend to build on what I would say from thinking about it from the left hand side to the right hand side. But when we design, we have to think about things from the right hand side. Okay, we're going to get to that one. Okay. We're going to get to that one. Well, that's always the related. That's what I said. Don't go too far off.
But what I hear from you though is in this one is by taking its time to actually break things down into am I really getting to causation and not correlating my data. That's right. I get that. And then once I get to that, I want to say, okay, which ones cause and which ones affect? Because as I start developing, as I start trying to build product, we don't want to build off of aspiration.
So we have to understand what's from a customer perspective, what is causing someone to want to get an effect out. Correct. So we have to understand that. From a technical standpoint, why is it important to understand which ones causes and which ones affect? Because in the end, I usually cannot control effects, but I can control causes. Causes have this element to it as a designer. I'm supposed to put these things in to cause this effect.
Well, and let's pretend we were making, I don't know, let's say we were making a cake. No, let's do soap. Soap. Got it. Right. And I put different ingredients into soap. Yep. And each one is supposed to give me an effect. Each one is there for a primary purpose. Yes. So that's the reason why I put the ingredients. But if I really am truly doing this cause structures and thinking about the system, I actually have to think how those different things interact with each other. That's correct.
How do those things change the effect? That's correct. So for example, some people put a fragrance into a dish soap, but depending on the type of fragrance, it could be oil-based. So all of a sudden, this effect actually is used to actually attack the fragrance. And so you start to realize that there's interdependence between these systems. And so ultimately, what we want to be able to do is design systems to be as independent as possible.
But that interdependence then becomes, if you will, a noise factor, something we have to know about, but we also have to then figure out how to design around. But if I don't know what my inputs are causing what outputs and what they affect and all those different things, I can't actually think about that. Yep. I think doing one factor at a time if I do that. That's right. The other thing is that we end up confusing inputs and outputs.
And so we end up kind of making things work, but then we don't know when they don't work. So we don't know how to push things far enough to actually know when they don't work. Right? And I always say form follows function. So if we understand how things work, then we know how to put them together. Okay. And then the last one, you kind of hinted to it is right to left thinking. Yes. Most people want to start with the, they want to start on the left because it's how we read, right?
That's the most comfortable. They want to start with what, what do they have now? What are they doing? All the stuff. But we want to actually start from the right. Why do we want to start from the right? Why do we want to start with that output? And everybody says, keep the end in mind and all that stuff. But right to left thinking is a little bit different than that.
Yeah. So ultimately, I think part of it is, is realizing that when, at least for me, when I start on the, on the right with, with inputs, right? I then look at all the things I can possibly do. Right? And so it actually becomes very divergent in terms of all possibilities. But if I start with the actual end in mind, I start with the outcome I'm looking for. And then one of the outputs I have to generate to get to those outcomes. Right?
There's then a very, it's very focused and it actually helps me develop much quicker. And so, you know, my, you know, my experience says that, that if I, if I think about what can I build given these inputs, it will take me twice as long to build something. Then if I start the other way, which is what are the outcome I'm really trying to get to and how do I design to get to it?
And I think when you start in the, the loft, what you start, you're actually starting on these, the supply side, the supply side. It almost causes you to start on the supply side, right? Because that's how we're taught. That's how I was taught to innovate. It's like, what do you got? Okay, what can you build? And then who's going to buy it? Right. And that's the difference between, are we innovating? Are we doing iteration? And there's times for iteration.
There's absolutely time for line extensions, iteration on things we do, technology changes, and we can do things a little bit different. I mean, there's absolutely a time for that. And no one's saying there's, there's not a time for that. But when we really are trying to figure out new ways for ourselves, as a company or new ways for a customer or getting in a new things, if you start from the supply side, or you start from the loft, you can only see the world through what you can do today.
Yes. If you start with the outcomes, you start with what people are going to be able to do. Yes, that they can't do today. It allows you, it allows that world to open up 10, 20 times. And then you start making the trade-offs. That's right. Of what does it mean for you as the business? That's right. Because if we start from the loft, we're always making the customer make the trade-offs. That's never good. That's right.
And ultimately, they don't know how to make the trade-offs as we're experimenting per say. And so part of this is. That's the bad decisions. It's usually bad decisions, right? That's the problem, right? And that's what we always talk about is, if you use the five skills, if you talk to customers and you do these things, you're going to actually make them better consumers. And that's the ultimate goal of a really good innovator. Yes. Is to make better consumers not to be a better supply?
That's right. And ultimately, progress is achieved by consumers. Again, most people think that our product causes people to make progress. But they make progress, the question is, how do they use our input to help them get to their outcome? Well, that sounds like correlation. We think our product makes people better. That's right. But it doesn't. They make themselves better through our product.
And that's really about being able to, again, understand what's the role our product plays in helping them make that progress. It's not just that they buy the product. It's the using of the product that actually enables progress. So this has been kind of a quick one. Is there other aspects of the causal structures piece that you want people to take away? If they take away those three big things that we just talked about, they get a pretty good start.
But what it said, other like, so the secret sauce you have, that's one of them. So there's two other parts. One is there's like, you can go deep into systems and systems thinking, right? And there's a very big kind of body of work around that. And what's interesting is that it comes from both a mathematical perspective as well as from an engineering perspective. The way I was taught it was more, it's almost like a perspective to look at anything.
And so even when we're having conversations, it's trying to understand, as we're talking, you know, what I usually talk about is trust. And I'll say, okay, is trust an input or is trust an output? Do we need trust coming in or do we have to cause trust in the process of how we're doing something? And you start to realize, depending on what, when you use the word and where it sits in terms of the system, it then has impact on what we have to do.
And so part of it is really being able to understand and see both inputs, actions, outputs, out measurements and outcomes, right? The other aspect here is Dr. Taguchi's influence on this whole aspect of robustness. And that most people, and again, the way I was taught out of school was to find the root cause of something and eliminate it.
And what Taguchi has talked about is that there's ways in which to kind of design your system to be robust to, or at least sensitive to, those noise factors you can't control. And so that to me as the other part of this is defining my sphere of influence and determining what is really control for me and what is noise. And by having those two aspects to it, it really helps kind of then decide what I'm going to build or how I'm going to build.
So I think the homework we want people to do today, it's just a tough concept to homework with. I think there's a couple different things people can do. And it depends on where you're at in your career, it depends on where you're at in your product, those types of things.
But the first one is just for correlation versus causation, I want you to take a situation and just understand, just kind of unpack it and say, am I making the decision off of correlation or am I making the decision off of actually causation? And the difference there is, do you have the right data? Do you have the right views of it? Do you have the right data? Do you have the right data? Do you actually prove out at some level that this is why it's happening?
And you can do that with your product, you can do that with decisions amongst your life. I mean, there's a bunch of ways you can do that. Causing a fact is going to be related to right to left thinking, which is if you have a product, I want you to look at what you're designing, what are those outcomes that the customer will get. And are you actually, do you have things in there that will cause that effect? And which ones are they?
Or do you have things in there that are actually effects that your product is actually doing effects? Yep. And you're asking the customer to cause, which is almost impossible, right? So it's just really unpacking your product that you have and saying, okay, what does the effect I'm trying to get to? And what piece is actually cause that effect? And what you're going to find out is you're going to have three or four different pieces, effects you want.
And you're going to have to probably have different pieces in there to do that. Yep. And then make sure they actually interact correctly to get it doesn't actually blow it up. And what are the trade-offs? Because I can make it faster or I can make it lighter, but to make it both is hard. And so, obviously, where's the trade-off that I have to make?
And so by studying and being able to understand the outcomes you're trying to get to and one of those metrics that represent the outputs you're trying to get to, ultimately that's going to actually, that makes the rest of it easy. And most of the time we start with very, I'll say loose outputs, but very concrete inputs and then- Okay, you're preaching not giving homework. Sorry. That's my problem. That's why you're here.
So just kind of take that homework, do the best you can with it, but then also as a little tease, I know you are working with a couple people on building a course around the book. Yep. So look for that in the next six months. Yeah. Three, four, yeah. Three, four months. Okay. And so we're working to do a shooting for, you know, little 20, 23 sometime. Let's put it that way. Okay. So this is going to launch in 2023, so I don't know if that really helps people.
Okay. First, first second quarter, I think we're going to do that. That's cool. Perfect. Thanks. Talk to you next. See you. Bye. 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 at TheRewireGroup.com to find out how we work, how we can help some resources, some books, some software.
Even as next time, as we trip to Circuit Breaker to help you recharge, re-energize, and refocus your new product development.