S2 E6 | Causal Structures

When I start on the right with inputs, 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 what are the outputs I have to generate to get to those outcomes? There's then a very. It's 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 than 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 Besta 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, 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, kind of, what? What is causal structure? Why is it so important? And how do we use it to help us build things? And so we ramble around a little bit, but at the same time, there's some gold in there, so enjoy.

Hey, Bob.

Hey, Greg.

So 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.

All right?

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.

Okay.

Because we're going to do causal structures.

So funny. Yeah.

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 bedrock five skills that an innovator should have?

Yep. So when reflecting on kind of like the people I've 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 cause and effect was in play. They had some mental model of how something worked, and they continually hone and refined it. Right. But the, the aspect here is that there is 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 wanted 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 sub skills I want to talk about or inside this thoughts that I want to talk about. And the first one is, is correlation versus causation.

Yes.

What is correlation?

Correlation to me is the aspect of 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. But it assumes causation most of the time.

Okay, so do you have an example? I know it's tough to come up with an example off the top of your head, but what would be correlate like.

So what I was told by Dr. Taguchi is a story that for hundreds of years that in Japan they believe that the trees caused the wind. And so because when the wind was there, it moved. And so they assumed that the trees caused the wind. And so they wouldn't cut trees down until they understood 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?

Causation is, is. It's about sequence in 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 a solid to a liquid. It temperature causes it to change faces.

So if, 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 ultimately is that in colder temperatures, gases constrict as opposed to expand. And so it would basically say the same area. So PV equals nrt, Right. Pressure, volume, temperature equals PV pressure and volume equals temperature times the gas constant. And the gas, what do you call it? R. The R is the Key. Yeah, sorry, we can cut that part out. 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 when it gets cold, tires lose air. 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 to take in 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. 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 and 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 has 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 Ishikawa diagram or a Fishbone diagram, which is like, there's a lot of things that contribute to some output. And so ultimately, it's understanding 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. What is a cause? What is an effect? And typically, the way I would always spot it is what comes before what, Right? And so 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. You know, building things is about Assembling, you know, sets of things together to actually get some effect. And, and, and, and we, we tend to build on what I would say from, from thinking, I think 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, they're always related.

That's what I said. Don't go too far off. But what I hear, what I hear from you though is, is in this one is by taking the break things down into am I really getting to, to causation and not correlating my data.

That's right. Right.

I really want to get that. And then once I get to that, I want to say, okay, which one's cause and which ones affect?

Yes.

Because as I start developing, as I start trying to build product, we don't want to build off of aspiration.

Correct.

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, which ones causes and which ones affect?

Because in the end I usually cannot control effects, but I can control causes, Causes have this, this element to it is as a designer, I'm supposed to put these things in to cause this effect.

Well, and let's, let's pretend we were making, I don't know, let's say we're making a cake. No, let's do, let's do soap.

Soap. Got it.

Right. And I put different ingredients into soap. And each one is supposed to give me an effect.

Yeah, each one is there for a primary purpose. Yes, each ingredient.

But if I, if I really am truly doing this structure this causal structures and thinking about the system, I actually have to think how those different things interact with each other.

That's correct.

And how does it change? How do those things change the effect?

That's correct. So for example, some people put like a fragrance in to a, to a dish soap, but depending on the type of fragrance, it could be oil based. And so all of a sudden the surfactant 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. I'm 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.

And most people want to start with the. They want to start on the left because it's how we read. Right. And that's the most comfortable. And they want to start with what do they have now? What are they doing all this 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, yeah. So ultimately, I think part of it is realizing that when, at least for me, 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 what are the outputs I have to generate to get to those outcomes? There's then a very. It's 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 than 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?

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?

Well, that's how we're taught. That's how, 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 it's just.

And that gets the difference between Are we innovating? Are we doing iteration?

Are we inventing?

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 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 into new things. If you start from the supply side or you start from the left, 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 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 left, we are always making the customer make the trade offs and that's never good.

That's right. And ultimately they don't know how to make the trade offs in as we're experimenting per se. And so part of this is.

Well, they do. It's bad decisions.

It's usually bad decisions. Right.

And that's the problem. Right. And that's what we always talk about is if you, if you use the five skills, if you, you talk to customers and you do these things, you're going to actually make them better consumers.

Yep.

And that's the ultimate goal of a really good innovator.

Yep.

Is to make better consumers, not to be a better supply.

That's. That's right. And ultimately progress is achieved by consumer like again, most people think that our product causes people to make progress, but they make progress. And 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, 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 is that other secret sauce you have?

There's two other parts One is there's. 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, I'll say, 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. What I usually talk about is trust. And I'll say, like, 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 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, measurements, and outcomes. Right. The other aspect here is Dr. Taguchi's influence on this whole aspect of robustness, in that most people, 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, is 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, this is a tough concept to do homework with, but 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 on 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?

Do you have the right views of it? Do you have the right data? Do you have the right. Do you. Can you actually prove out at some level that this is why it's happening?

Yep.

And you can do that with your product. You can do that with decisions Amongst your, your life. I mean, there's a bunch of ways.

You can do that.

Cause and effect 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?

Yeah.

And which ones are they? Or do you have things in there that are actually effects that your practice actually doing? Effects.

Yep.

And you're at. 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 is the effect I'm trying to get to and what pieces actually cause that effect? And what you're going to find out is you're going to have three or four different effects you want and you're going to have to probably have different pieces in there to do that and then make sure they actually interact correctly, that it doesn't actually blow it up.

That's right. That's right. 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 all of a sudden 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 what are 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 you're preaching, not giving homework.

I'm sorry, so 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 of people on building a course around the book.

Yep.

So look for that in the next six months.

Ish. Three, four. Yeah, three, four months. Okay. That's what we're working to do. We're shooting for, you know, little 2023 sometime. Let's put it that way. That's the.

This is going to launch in 2023, so I don't know if that really helps people. But first, first, second quarter, I think we're going to.

That's the goal.

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@the RewiredGroup.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, re energize and refocus your new product development.