S3 E15 | Red Line Green Line Development

Creating requires a lot of knowledge and learning along the way. You're not there to actually verify what you know. You're there to actually discover what you don't know. And so to me, Green Line is really about this notion of people observing. It seem like you're failing all the time, but when you're in it, it feels like you're learning all the time. And so make sure that you feel comfortable learning and describing the things you don't know as opposed to trying to articulate what you know and figure out a way to verify what you know.

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. And recharge your brain to build better products.

Hey, Bob.

Hey, Greg. What's up, man?

So today we're gonna talk about something that I don't think we've talked about on the podcast for sure, but we haven't really talked about to our customers in a long time either.

Yeah.

Which is Redline greenlight. Oh, and redline greenlight is a story, a philosophy, a theory that you tell about how the Americans develop product and how the Japanese develop product. When you were learning from Taguchi.

Yeah, Taguchi and Debbie and everybody.

So why do you think Redline Green light is an important topic to talk about?

Because I think it represents kind of the mindset differences between two totally different approaches to product development and developing products. So it's. It was really, I would say us versus Japan, but it was. It started as this notion of why was Japan actually making big grounds on us in terms of the automotive market? And that their development time was literally half of ours. So for every one car we would develop, they could develop two. And so it just became this notion of understanding kind of what are the method differences? What are they doing differently? How are they thinking differently? And so it became this story around kind of the underlying philosophy of how to approach product development.

Yeah, I think it's kind of like, how do you approach problems?

Exactly.

And the difference in the way people approach problems. And I think it still holds true today. There are some companies that approach problems. Problems completely different than others. Apple versus somebody else. So why don't you tell the story as quickly as possible, which is always a tough thing.

Thank you.

About what Redline Green Line is.

So I was basically part of a team at ford in the mid-90s or mid-80s that basically. And I was literally started as an intern. But they went over and studied from Japan how they were developing products. So in the early 80s it was all about production, product quality and bringing in Deming and process control. But in the mid to late 80s it got to how do they develop products differently than we do? And so first of all we went over and just kind of benchmarked and one of the things is we benchmark the number of design changes or changes to the product and or process. Right. As you develop it and launch it. And one of the things we found when we compared like the Escort to the Corona was that the number of design changes they were making early in the process of developing the product was almost like 10 times more prototypes than we would have. Right. And the other thing we realized is that they were learning about how it worked and how it failed, where we would actually run tests to verify that it worked. And so it was just these very different kinds of approaches to going after that and seeing that. And so what we found were things like Taguchi methods and we found things like quality function deployment and we found like these different tools and methods. But we also realized that there was a mindset difference as well. And so I think the best way to articulate it is that when we heard the word process in the US or at Ford, process meant that we would define the steps in the process. And the process was sacred, meaning don't change it. It's like we're trying to actually figure out how to make scale and just repeat it over and over and over again. Where in Japan, the process was actually kind of the boundaries by which they could make improvements all the time. And so where we're trying to lock everything in, they're constantly making it, tweaking it and making it better. And so it's that foundation of continuous improvement. But now into a development realm.

And we're going to put a visual in the show notes and it's going to have a red line, green line, it's going to kind of show the difference from a pictorial sense. And what you actually see is in the more traditional process driven approach, you see the line kind of, there's activity, then it kind of everybody's waiting for things, waiting for things, waiting for things. And then we Launch and then, oh, we have to fix everything and then all that kind of stuff. And then in the other approach, in the Greenland approach, it's a lot of activity at the beginning.

Yep.

And then the activity starts slowing down towards launch and then launch happens and there's really no need to go with a lot more activity again because you've talked about the problems or different things.

Well, and you've made trade offs of what to accept and what not to accept and how to move past it. And what we would end up doing it, Ford, is we'd end up spending, we'd launch the product after seven years and then we'd actually spend the next two years cost reducing it or fixing bugs or fixing problems or bugs or whatever. But the notion is just make it work and then we'll figure out how to save money. The design changes late in the process are anywhere from 100 to 1,000 to $10,000 more X in terms of if it was $10, it's now $100,000 to make that same change at different points in the process. And the Japanese seem to know that and they realize that at some point it's more important to explore and to not wait for things, but to make things happen as opposed to what we would do is if as long as it worked in the lab and it was fine, then when it didn't work, it was everybody else's fault.

And I think you also. So you mentioned. I want to unpack a word. You mentioned earlier when you were doing the benchmarking and you went to Japan and you did those things, you were doing prototypes.

Yeah, yeah, yeah.

So we talked about prototypes in a past session. I don't even know when it was, but it was a while ago. And we talked about the different types of prototypes.

Yep.

So what kind of prototypes were they running?

So they were, in most cases they're prototyping to learn. So one of the things that Taguchi taught me very early was something called design of experiments. And it was very interesting because the way that we use it in the west was using design experiments to prove our hypotheses. Right. Where in Japan we're running the test because we don't know what's going to happen. And you start to realize like you pick very different factors, you pick very different levels, you pick like it's very, very different set of processes. And ultimately the methods around it were all about learning and finding the limits and pushing ourselves to get there as opposed to just make it work.

Yeah. So when people are listening to this Podcast and they're thinking about it, they're in product development, whether it's software, hard goods, whatever it might be. What we want them to kind of feel is if you're on the red line, you hear a lot of, well, I have to wait for X to do something before I can do it, or if they only did it this way, I can make it better. You hear a lot of those types of things when you. When you're on the green line and you're managing a team on the green line, or you're on a team on the green line, what you hear is, what are you working on? And then what can I go learn about whatever you're doing?

What are the unknowns that you have? How do I go?

What are the variables you're working on? So I know the variables. So if I'm a UX designer, I don't have to wait for all the stuff to be done.

Right.

I could be working on some UX part of it.

Yes.

Before I know everything is lined. As long as I know enough of what you're doing.

So one of the things, one of the things we learned along the way was like, we wouldn't actually start developing the transmission until the engine was done. Right. And so it was all in series. Right. And what we realized is we could actually develop the transmission in parallel with the engine and make sure that actually then we had to build some prototypes and integration prototypes. But ultimately the fact is, when we would develop the engine and then develop the transmission, and then the engine would make a change, then that would have a ripple effect to the transmission and all the other things. And so you started to realize, like, at some point in time, we have to think about it differently. And one of the key things that Taguchi would talk about is robustness and the aspect of being able to actually think about your system as what you have control over. And there's things that happen to it that you can't control. And how do you make the system robust to those things you can't control? And so, for example, I can't control all the details of the engine, but the transmission be able to work despite the fact that there's variation in the engine.

Right. And so I think when you think about green line, you're thinking about, you know, people working, informing each other what they're doing.

Yes.

But working in parallel.

Yep.

Learning not only for that project.

Yep.

But learning overall for themselves as well.

Yep.

So as they go to the next project, they're not starting over from zero.

Yes.

They're starting over from some point of, hey, I've solved a problem similar to this before.

Right.

I could take that knowledge over to the next project now.

And so they. But the thing is, is that they actually had a separation between, like, what I learned in the last one is not absolute truth, but more. I know. I know enough about it. And I have a method to figure out how to figure out the best way for this transmission versus the other one. And so it would be this notion of, like, everyone is different, but I need to learn to figure out how to do it. And it was more about learning than about verifying.

I'm not going to get this wrong, but with Taguchi, you've told me before, it's like, if you were to tell him he was the expert, he'd be like, no, I'm not the expert. The data or the system will tell me what the expert is. He'd always, yeah, I'm just here to be the voice of that.

He would always say, like, like, let's let the engine tell us what the best engine is. As opposed to, like, find the expert who's the. Who knows about engines. And what you realized is the empirical data and realizing, like, there's way more unknown than there is known and that the empirical data is way more important than the theoretical data in terms of building product.

And continual learning is something that we preach all the time, right?

Yep.

You're like, we're still learning jobs we've done.

Yes. That's one of our challenges is as. As every time we go like, okay, here it is. It's like, no, no, no, we got to tweak way. And so we're always making it right.

And it's not that we're changing the underlying philosophy, we're changing the way we deliver it to somebody or did they get it this way? So do we do it this way? We're always trying to prototype those things to make it more attainable to people, make it more real, make it more beneficial, those types of things. But we're also learning. Every time you do an interview, you learn a little bit more about interviewing.

That's right.

So it's the same mentality. The Greenland mentality is that mentality of, I'm going to learn something new.

Yep.

Every time I touch something, even though I did gum 50,000 times.

Yeah.

I'm going to learn something new.

That's exactly right. And what I learned before might, might or might not be relevant. And so it's that assumption that it's not like, I don't really know. So I have to actually kind of figure out what. What to learn about. And so that's. And how is it different? And it allows you to actually have a very different mentality of instead of being wrong or right, it's the aspect of learning and constantly getting better.

So what do you want people hear this conversation. What do you want them to take away from Red line, green light? What's that moment that you're like, okay, I want you to take away this because it's really important.

I think the biggest thing is it relates back to imposter syndrome, which is this aspect of company hires us because we're supposed to know how to do something. But the reality is when we're building something new, we really don't know. We have a foundation, but we don't have that. And so to me, the takeaway should be. Is part of our role as a developer or as an engineer or as head of product, is to actually create. And that to be honest, creating requires a lot of knowledge and learning along the way and that you're not there to actually verify what you know. You're there to actually discover what you don't know. And so to me, Green line is really about this notion of being. Again, people observing it look like you're seem like you're failing all the time, but when you're in it, it feels like you're learning all the time. And so make sure that you feel comfortable learning and describing the things you don't know as opposed to trying to articulate what you. And figure out a way to verify what you know only.

So that's a very interesting thing and probably going to get too deep here. But you talk. We talk about unknowns all the time.

Yes.

But nobody knows what an unknown is.

Yes.

So when you say discover the unknowns, how do you discover. I don't. How do you get. How do you discover an unknown?

So part of it is you build something and you make it break. Right. And you figure out the thresholds of where it breaks. And most people are like, they don't want to make it break. And my thing is my job is to make it break. So we did a prototype where we. On your next thing. And as we did it, we said, all right, this next one we're going to do in two weeks. We knew it was going to be too fast, but we wanted to see how did it break? And so we're learning about those kinds of things. And instead of trying to figure out the optimal length, it's like I need to know where is it too short and when is it too long? So that's going to give me the thing of what's the right pace at which to get people to do this, to do this process.

And that's one of the things that people have to get comfortable with, is because from a societal, from a hierarchical situation, everybody, nobody wants to ever be wrong.

That's right.

And if you're doing things in innovation, you're doing things in green line fashion, you're going to be wrong, or actually you're not wrong. You're trying to figure out where those boundaries are. Right.

Exactly.

But you're going to build something that's a failure or breaks or doesn't work or whatever. We used to do experiments teaching RDOE with windmills, and there was times where it wouldn't even move right because we chose the wrong variables. But we need to know that where's the limit? Because maybe we could have made it work and maybe it would be better if there was less. Right. So you have to think about it. You have to change your mindset of people, think people look at you when you build something that doesn't work as a failure and it's a personal thing and all these types of stuff. But if you listen to the quote you use with Taguchi, he wasn't taking personal responsibility.

No.

In fact, he was giving the system.

Right.

The personal responsibility.

Right. He's just empowering the system to tell us what's best for it.

He's the person putting it in different situations to tell him what to do.

Like how it works, what's the causation. Ultimately, it was about the causation. And this is the difference between, you know, Deming used to debate George Box, who was a statistician, and Taguchi would always say, this is not about statistics. I only can make so many prototypes. And I know there's a statistical way to look at all that, but the reality is, like, I have to be able to extract as much information as I can as quickly as I can. That's an engineer's job.

Well, and that gets in a whole philosophical thing. Right. Is okay. I can have stakehold significance.

Yes.

But it doesn't always work. It's not important when it gets out in the public. Doesn't always work that way because of context.

That's right.

And what you're trying to do in prototypes, you're trying to put different systems in different contexts in different variables, to see all the different ways things can work and what doesn't work because what works for one person in one context doesn't always work for somebody in the other context.

Exactly.

So you're always trying to do that. And I also think with Redline, Greenline, we're trying to get people to understand is be comfortable with the uncomfortable, which is also another ism that we use all the time. That doesn't really mean a whole lot, but it does. It's like uncomfortableness is failure. Uncomfortableness is admitting you don't know. Uncomfortable is the not knowing what this thing's going to do. There's a lot of people we've watched that some are successful, some aren't. That they won't build something unless they know what's going to happen.

Right? That's right.

Well, you need to be uncomfortable. You need to make yourself uncomfortable enough to build something that you don't know what's going to happen and you need to be. I always describe you as the. Well, now it's probably even younger, but I always described you as a 12 year old on Christmas. That came down in the wonderment of all the presents and all the things going on.

What's in the boxes? Exactly.

It's the same thing when you're doing experiments, the same thing when you're doing a prototype. You're trying to unpack that to see, oh, what worked, what didn't work. And it's not just the fail, not fail. That's not what you're looking at. You're looking at why did it fail, why did it work? Those types of things are what you're really trying to get to.

And new theories only come from anomalies of things you couldn't explain. And so part of it is to realize, like, I'm actually trying to cause anomalies early in the development process. So I know one where it breaks and understand why it breaks. Because at some point I'm going to be way smarter. So when we get to launch and we have a problem, I know exactly what to do to solve it.

And the other thing I want to talk about a little bit is like, so people are listening and they're like, okay, great, red line, green line, whatever. But it's like as you look at your teams or as you're on a team, how do you know you're on which one? And I talked about a little bit in the beginning, but when you're on the red line, you're waiting.

A lot of times you're waiting. Yep.

On the red line, you actually look very organized. Like if I'm the manager looking at you. You look very organized.

Everything's done. It's all checked up. We're just waiting for people to get in.

You're just doing the next process, or.

I know the next steps, and here's what we're doing, and here's the plan.

Right. And you're giving updates, and you. And everything's moving on par. And you're just. You're just going through the process, and it's almost like the process is dictating the product.

That's right.

That's what it feels like, or it looks like.

Well. And there becomes a level of confidence to say, like. Like, we can. We can get this done. Right. And ultimately, the fact is, I keep going like, okay, we haven't hit a roadblock in a while. We're either not pushing ourselves far enough or the fact this is like we're missing something and it's going to come out of nowhere. It's that paranoia kind of part that you have to go, like, I need to test it in the real world before I put it to the real world. So how do I actually simulate the real world for it? So I understand it's going to really work there because most of the stuff is built in what I would say is laboratories or workshops or coding. And it's like, there's no testing to it. And it's like all of a sudden, it's like, is it really going to work? You don't know.

And then the other thing you see in a lot of REDLINE projects is as you get closer to launch, things get busier.

Yeah. Because you're integrating. You're putting multiple things together to your point of always.

Now the time wall is real. The time I gotta launch it.

That's right.

I gotta deliver this piece of software. I gotta do whatever.

But here's the other part of the mentality of redline is that when. When it doesn't work, what you're trying to do is find the special. Cause the one thing that.

That's after launch, though.

Yeah.

But even I see a little bit of activity right before launch because everybody's scrambling. Oh, my God, does it work?

Yeah.

But then it launches.

Yeah.

Then you're like, oh, poop.

Yeah, we gotta. We gotta fix this. We gotta fix that.

It didn't work or it worked, but we missed these five things. And now I'm getting error messages or whatever it might be.

Right.

You see more activity when you're on the green line at the very beginning. You feel like everything's a mess. You actually feel Uncomfortable.

Yeah.

And you embrace it. Uncomfortable because you don't know and you're willing to say we don't know. And you're going to have some arguments up front between different people in different factions. If we take CPG for an example, people doing the formulation of people doing packaging, they might argue because they need to understand what people are, do what each one's doing. Because there are certain things that a package needs to do. If you have certain things in it or certain things, can't go into certain things. So you're going to hear those debates, you're going to hear those types of things. And it's not people trying to be a jerk, right? It's understanding. So then I can go build my experiments because if I, if you tell me there's going to be acid in something and I'm the packaging engineer, I need to know that, right? And then I can go do a bunch of different things. I can tell you, well, I can actually do something if. As long as you stay below this amount, right?

So I mean, one of the better examples is dishwashing soap, right? Somebody's like, okay, here's the temperature of the water that actually helps clean with this soap the best. You can't control it. Some people use cold water to wash their dishes, some people use really hot water. And the reality is I need to make sure it works in both. So instead of specifying it should be 120 degrees Fahrenheit to basically wash dishes that are above blah, blah, blah, blah blah, or 180 or whatever it is, it's like, no, I needed the soap to actually work under all water temperatures. And that becomes one of those things where it's like, well, that's not my job. It's like, it is your job.

And so on the green line you're going to see some activity, you're going to see some arguments, you're going to see a lot of. You should see a lot of prototypes, you should see a lot of different people with different ideas, competing ideas. There should be some debate. Should not be hostile.

No. Should be actually educational, curious.

You're going to see at some point the work, the chaos kind of stop. And the chaos is a bad word for that.

But the knowledge starts to this, the knowledge starts to solidify that enables you to kind of have actually more and more rational trade off decisions.

It's usually before you would see a team on the red line kind of come to that, you're going to see the green line people, okay, I've learned enough.

Yep.

Now we're integrating, now we're doing all those things. And I'm not rushed to get to the. To the end.

Yep.

I'm actually letting the end tell me how far I can go instead of saying the end. I have to be done.

It's fixed time and variable scope. Like I'm going to adjust the scope to fit into the time that I have.

And then you. I mean, every product has bugs and stuff. I mean, even if you're on the green line, it's not going to be perfect. Right. But there shouldn't be as much. And one of the things we always talk about is it's cheaper to spend money early in the process than it is late in the process because we start making stupid trade offs.

But it's. Yeah, but it's hard to actually understand the unknowns of what you should do up front. So a lot of cases, people just wait.

Right. But on Green Line you don't wait.

No, you don't.

When you see the graphic that we're going to use, you're going to see, hey, it costs a lot less here in the green line if we do all the work here because we have time. Right. We don't have to get an experiment done in a day. We have two days, three days, five days a week, three weeks, whatever. When you start getting up against that timeline, things start costing more because, you know, you're under time pressure, you're under different things or you have to make it bigger or smaller or whatever. So those are the types of things we want you to take away from this. The other thing we want to watch take away from this is, as always with what we talk about is be uncomfortable with the unknowns.

Yep.

Try to discover unknowns.

Yep.

But then also just try to always be seeking learning.

Yep.

Right. That's really what green line to me really means.

Yep.

And the quicker we can do that. The other thing I want to talk about a little bit before we go, and I know we're kind of a little longer than we normally are, is.

We knew it was a big topic.

There's no such thing as a completely red line or a completely green line.

No, that's right. I was going to say that because at some point what we've been doing with some of the teams we work with, we ask them like, okay, where are you on the red line, green line, kind of continuum from 0 to 10, 0 being red line and 10 being green line. And then ultimately what are two or three things you can do to make you more green line? And so it's this migration from redline to green line because it's just not possible to change the entire organization's behavior at once. And so it's about actually finding the three or four things you can do on this project to make yourself more green line and how to budget and to build the skills and the methods to help you be more greenlined, which.

Is a very different set of times. Sometimes context makes me have to follow a process.

Yes.

Because of where we're at. Right. So just keep that in mind. And then just as the homework we normally give, I think a couple things this time is first off, just I want people to think back on a project they did and have, you know, where do they think they were right. Were they red line, green line, why? And the other thing is, how do you actually help yourself or a team member get comfortable with that uncomfortableness?

Yeah.

How do you create that environment that makes it okay to ask the questions?

It's the tough questions, right? That's right. What I find is the teams that can ask the hardest questions to themselves is typically the team that's, that's going to make the progress fastest.

So I think that's really the homework for this one. So, as always, thank you for listening and we hope to see you on the next one.

Thanks, Craig. See ya.

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 trend, please share it. If you'd like to learn more information, visit us@the RewireGroup.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.