“Make sure you're comfortable learning and describing the things you don't know rather than trying to articulate what you do know and finding a way to verify only what you do know. There is no such thing as a completely red line or a completely green line.”
In today's Circuit Breaker episode, Bob and Greg delve into the "green line" vs. the "red line." This reflects contrasting approaches to product development. Bob will recount his research on this topic in Japan when he was a member of the Ford team. You'll understand the mindset difference in product development between the US and Japan.
They'll talk about one of Taguchi's methods, Design of Experiments. You'll discover the "green line" and the "red line" main takeaways. This includes, among other things, determining the cause of a product failure rather than bearing personal responsibility and not settling for the unknowns. You'll also learn why redline projects have more going on as they get closer to launch than greenline projects, which have more going on at the beginning.
Join Bob and Greg for this thought-provoking discussion on "green line" and "red line" development.
Enjoy!
What You'll Learn in this Show:
- What are the "red line" and "green line," and why is it important?
- How to discover the unknown.
- The importance of continuous learning.
- How do you know if you're on the "green line" or the "red line?"
- How do you get from the red line to the green line?
- And so much more...
Resources:
[00:00:00] Creating requires a lot of knowledge and learning along the way.
[00:00:04] You're not there to actually verify what you know, you're there to actually discover what
[00:00:09] you don't know.
[00:00:10] And so to me, Green Line is really about this notion of people observing it look like you're
[00:00:14] seem like you're failing all the time, but when you're in it, it feels like you're
[00:00:17] learning all the time.
[00:00:19] And so make sure that you feel comfortable learning and describing the things you
[00:00:23] don't know as opposed to trying to articulate what you know and figure out a way to
[00:00:27] verify what you know only.
[00:00:30] Welcome to the Circuit Breaker podcast where we challenge the status quo of innovation and
[00:00:37] new product development.
[00:00:38] We'll talk about tools and skills and methodologies used to build better products and make you
[00:00:44] a better consumer.
[00:00:45] I'm Bob Mesta, and I'm the co-founder of the Rewire Group, and I'm one of your co-hosts
[00:00:49] and we're joined by Greg Engle who is my co-founder and Chief Bob interpreter.
[00:00:54] Join us now as we trip the circuit and give you time to reset, reorganize and
[00:00:59] recharge your brain to build better products.
[00:01:05] Hey, Bob.
[00:01:06] Hey, Greg. What's up, man?
[00:01:07] So today we're going to talk about something that I don't think we've talked about on the
[00:01:10] podcast for sure, but we haven't really talked about to our customers in a long time either.
[00:01:14] Yeah.
[00:01:15] Which is Red Line Green Line.
[00:01:16] Oh, yes.
[00:01:17] And Red Line Green Line is a story, a philosophy, a theory that you tell about how the
[00:01:25] Americans develop product and how the Japanese develop product when you were learning
[00:01:28] from Teguchi.
[00:01:29] Yeah, Teguchi and Deming and everybody.
[00:01:31] So why do you think Red Line Green Line is an important topic to talk about?
[00:01:34] Because I think it represents kind of the mindset differences between two totally different
[00:01:40] approaches to product development and developing products.
[00:01:42] So it was really, I would say, US versus Japan, but it started as this notion of
[00:01:48] why was Japan actually making big grounds on us in terms of the automotive market
[00:01:53] and that their development time was literally half of ours.
[00:01:56] So for every one car we would develop, they could develop too.
[00:02:00] And so it just became this notion of understanding kind of what's the, what are
[00:02:03] the method differences?
[00:02:05] What are they doing differently?
[00:02:06] How are they thinking differently?
[00:02:08] And so it became this story around kind of the underlying philosophy of like how
[00:02:12] to approach product development.
[00:02:14] Yeah, I think it's kind of like how do you approach problems and the
[00:02:17] difference in the way people approach problems.
[00:02:20] Yep.
[00:02:20] And I think it still holds true today.
[00:02:21] There are some companies that approach problems completely different than others.
[00:02:25] Apple versus somebody else.
[00:02:28] So why don't you tell the story as quickly as possible, which is always a tough thing
[00:02:34] about what Red Line Green Line is?
[00:02:36] So I was basically part of a team at Ford in the mid 90s or mid 80s that
[00:02:42] basically and I was literally started as an intern, but they went over and
[00:02:48] studied from Japan how they were developing products.
[00:02:51] So in the early 80s, it was all about product quality and bringing in
[00:02:54] Deming and process control.
[00:02:56] But in the mid to late 80s, it got to how do they develop products differently than we do?
[00:03:00] And so first of all, we went over and just kind of benchmarked.
[00:03:04] And one of the things is we benchmark the number of design changes or changes
[00:03:09] to the product and or process, right?
[00:03:11] As you develop it and launch it.
[00:03:14] And one of the things we found when we compared like the escort to
[00:03:17] the Corona was that the number of design changes they were making early in
[00:03:22] the process of developing the product was almost like 10 times more
[00:03:26] prototypes than we would have.
[00:03:28] Right.
[00:03:29] And the other thing we realized is that they were learning about how it
[00:03:32] worked and how it failed, where we would actually run tests to verify
[00:03:36] that it worked.
[00:03:37] And so it was just these very different kinds of approaches to going
[00:03:41] after that and seeing that.
[00:03:43] Right.
[00:03:43] And so what we found were things like Taguchi methods and we found
[00:03:46] things like quality function deployment and we found like these different
[00:03:49] tools and methods, but we also realized that there was a mindset difference as well.
[00:03:54] And so, you know, I think the best way to articulate it is, is that when,
[00:03:58] when we heard the word process in the U.S. or at Ford, process meant
[00:04:02] that we would define the steps in the process and the process was sacred.
[00:04:07] Meaning don't change it.
[00:04:08] It's like we're trying to actually figure out how to make scale and just
[00:04:11] repeat it over and over and over again.
[00:04:13] Where in Japan, the process was actually kind of the boundaries by which
[00:04:17] they could make improvements all the time.
[00:04:19] And so where we're trying to lock everything in, they're constantly
[00:04:22] making it, tweaking it and making it better.
[00:04:25] And so it's that foundation of continuous improvement, but now into a development realm.
[00:04:30] And we're going to put a visual in the show notes and it's going to have
[00:04:35] a red line green line.
[00:04:36] It's going to kind of show the difference from a pictorial sense.
[00:04:39] And what you actually see is in the more traditional process driven approach,
[00:04:46] you see the line kind of there's activity that I kind of, everybody's
[00:04:51] waiting for things, waiting for things, waiting for things and then launch.
[00:04:54] And then, oh, we have to fix everything.
[00:04:55] And then all that kind of stuff.
[00:04:56] And then in the other approach and the green line approach, it's
[00:05:00] a lot of activity at the beginning.
[00:05:02] And then the activity starts slowing down towards launch.
[00:05:06] And then launch happens.
[00:05:08] And there's really no need to go with a lot of more activity again,
[00:05:12] because you've talked about the problems or different things.
[00:05:15] Well, and you've made tradeoffs of what to accept and what not to accept
[00:05:18] and how to move past it.
[00:05:19] And what we would end up doing it for it is we'd end up spending,
[00:05:22] we'd launch the product after seven years, and then we'd actually spend
[00:05:25] the next two years cost reducing it.
[00:05:27] Or fixing bugs.
[00:05:28] Or fixing problems or bugs or whatever.
[00:05:29] But the notion is, is like just make it work.
[00:05:32] And then we'll figure out how to save money.
[00:05:34] And the design changes late in the process are anywhere from 100 to
[00:05:40] a thousand to $10,000 more X in terms of like if it was $10, it's now $100,000
[00:05:46] to make that same change at different points in the process.
[00:05:49] And the Japanese seem to know that and they realize that at some point
[00:05:53] it's very more important for us to explore and to not wait for things
[00:05:57] but to make things happen as opposed to what we would do is if as long
[00:06:01] as it worked in the lab and it was fine, then when it didn't work,
[00:06:04] it was everybody else's fault.
[00:06:06] And I think you also, so you mentioned, I want to unpack a word you mentioned
[00:06:09] earlier is in when you were doing the benchmarking and you went to Japan
[00:06:13] and you do those things, you were doing prototypes.
[00:06:15] Yeah.
[00:06:15] So we talked about prototypes in a past session.
[00:06:18] I don't even know when it was, but it was a while ago.
[00:06:21] And we talked about the different types of prototypes.
[00:06:24] Yep.
[00:06:25] So what kind of prototypes were they running?
[00:06:28] So they were in most cases, they're prototyping to learn.
[00:06:31] So one of the things that Taguchi taught me very early was something
[00:06:34] called design of experiments.
[00:06:36] And it was very interesting because the way that we use it in the West
[00:06:40] was using design experiments to prove our hypotheses, right?
[00:06:43] Where in Japan we're running the test because we don't know what's
[00:06:46] going to happen and you start to realize like you pick very different factors.
[00:06:50] You pick very different levels.
[00:06:51] You pick like a very different set of processes.
[00:06:54] And ultimately the methods around it were all about learning
[00:06:58] and finding the limits and pushing ourselves to get there as opposed to just make it work.
[00:07:04] Yeah.
[00:07:04] So when people are listening to this podcast and they're thinking about it,
[00:07:06] they're in product development, whether it's software, hard goods, whatever it might be.
[00:07:11] Though what we want them to kind of feel is if you're on the red line,
[00:07:15] you hear a lot of, well, I have to wait for acts to do something before I can do it.
[00:07:20] Yep.
[00:07:21] Or if they only did it this way, I can make it better.
[00:07:25] You hear a lot of those types of things.
[00:07:26] Yep.
[00:07:27] When you're on the green line and you're managing a team on the green line
[00:07:30] or you're on a team in the green line, what you hear is,
[00:07:32] what are you working on?
[00:07:34] And then what can I go learn about whatever you're doing?
[00:07:36] What are the unknowns that you have?
[00:07:37] How do I go through those?
[00:07:38] What are the variables you're working on?
[00:07:39] So I know the variables.
[00:07:40] So if I'm a UX designer, I don't have to wait for all the stuff to be done.
[00:07:44] Right.
[00:07:44] I can be working on some of the UX part of it before I know everything
[00:07:48] as long as I know enough of what you're doing.
[00:07:50] So one of the things we learned along the way was like
[00:07:53] we wouldn't actually start developing the transmission until the engine was done.
[00:07:57] Right.
[00:07:57] And so it was all in series, right?
[00:07:59] And what we realized is we could actually develop the transmission
[00:08:02] in parallel with the engine and make sure that actually then we had to build
[00:08:06] some prototypes and integration prototypes.
[00:08:08] But ultimately the fact is when we would develop the engine
[00:08:12] and then develop the transmission and then the engine would make a change,
[00:08:14] then that would have a ripple effect to the transmission and all the other things.
[00:08:17] And so you started to realize like at some point in time,
[00:08:20] we have to think about it differently.
[00:08:21] And one of the key things that Taguchi would talk about is robustness
[00:08:25] and the aspect of being able to actually think about your system as what you have control over.
[00:08:31] And there's things that happen to it that you can't control
[00:08:33] and how do you make the system robust to those things you can't control?
[00:08:38] And so for example, I can't control all the details of the engine,
[00:08:41] but the transmission should be able to work despite the fact that
[00:08:43] there's variation in the engine.
[00:08:45] Right.
[00:08:45] And so I think when you think about Greenline,
[00:08:48] you're thinking about people working informing each other what they're doing.
[00:08:53] Yes.
[00:08:54] But working in parallel.
[00:08:56] Yep.
[00:08:57] Learning not only for that project, but learning overall for themselves as well.
[00:09:01] Yep.
[00:09:02] So as they go to the next project, they're not starting over from zero.
[00:09:05] Yes.
[00:09:05] They're starting over from some point of,
[00:09:07] hey, I've solved a problem similar to this before.
[00:09:10] Right.
[00:09:10] I could take that knowledge over to the next project now.
[00:09:12] And so they, but the thing is that they actually had a separation between
[00:09:16] like what I learned in the last one is not absolute truth,
[00:09:19] but more I know enough about it and I have a method
[00:09:22] to figure out how to figure out the best way for this transmission versus the other one.
[00:09:26] And so it would be this notion of like,
[00:09:28] everyone is different, but I need to learn to figure out how to do it.
[00:09:31] And it was more about learning than about verifying.
[00:09:34] I'm not going to get this wrong, but with Teguchi, you've told me before,
[00:09:37] it's like if you were to tell him he was the expert,
[00:09:39] he'd be like, no, I'm not the expert.
[00:09:41] Right.
[00:09:41] The data or the system will tell me what the expert is.
[00:09:44] He always, yeah.
[00:09:45] I'm just here to be the voice of that.
[00:09:46] He would always say like, let's let the engine tell us what the best engine is
[00:09:50] as opposed to like find the expert who knows about engines.
[00:09:54] And what you realized is the empirical data and realizing like there's way more unknown
[00:09:59] than there is known and that the empirical data is way more important than the theoretical data
[00:10:03] in terms of building product.
[00:10:05] And continual learning is something that we preach all the time, right?
[00:10:08] Yep.
[00:10:09] You're like, we're still learning jobs you've done.
[00:10:11] Yes.
[00:10:12] Right.
[00:10:12] We're still-
[00:10:12] This is one of our challenges is as every time we go like, okay, here it is.
[00:10:15] It's like, no, no, no.
[00:10:16] We're going to tweak it this way and that way.
[00:10:18] And so we're always making it-
[00:10:19] Right.
[00:10:19] It's not that we're changing the underlying philosophy.
[00:10:21] Nope.
[00:10:22] We're changing the way we deliver it to somebody or did they get it this way?
[00:10:26] So do we do it this way?
[00:10:27] We're always trying to prototype those things to make it more attainable to people,
[00:10:32] make it more real, make it more beneficial, those types of things.
[00:10:35] But we're also learning every time you do an interview,
[00:10:38] you learn a little bit more about interviewing.
[00:10:39] That's right.
[00:10:40] So it's the same mentality.
[00:10:42] The Greenland mentality is that mentality of I'm going to learn something new.
[00:10:46] Yep.
[00:10:47] Every time I touch something,
[00:10:48] even though I did gum 50,000 times, I'm going to learn something new.
[00:10:52] That's exactly right.
[00:10:52] And what I learned before might or might not be relevant.
[00:10:56] And so it's that assumption that it's not right.
[00:10:58] Like I don't really know,
[00:10:59] so I have to actually kind of figure out what to learn about.
[00:11:02] And so that's-
[00:11:03] And how is it different?
[00:11:04] And it allows you to actually have a very different mentality of instead of being wrong or right,
[00:11:10] it's the aspect of learning and constantly getting better.
[00:11:13] So what do you want-
[00:11:15] People hear this conversation.
[00:11:17] What do you want them to take away from Red Line Greenlight?
[00:11:20] What's that moment that you're like,
[00:11:22] okay, I want you to take away this because it's really important.
[00:11:24] I think the biggest thing is it relates back to imposter syndrome, right?
[00:11:29] Which is this aspect of like,
[00:11:30] company hires us because we're supposed to know how to do something.
[00:11:34] But the reality is when we're building something new,
[00:11:36] we really don't know.
[00:11:37] We have a foundation, but we don't have that.
[00:11:39] And so to me, the takeaway should be is part of our role as a developer or as an engineer
[00:11:44] or as head of product is to actually create.
[00:11:46] And that, to be honest, creating requires a lot of knowledge and learning along the way.
[00:11:52] And that you're not there to actually verify what you know.
[00:11:56] You're there to actually discover what you don't know.
[00:11:59] And so to me, Green Line is really about this notion of being,
[00:12:02] again, people observing it look like you seem like you're failing all the time,
[00:12:06] but when you're in it, it feels like you're learning all the time.
[00:12:10] And so make sure that you feel comfortable learning and describing the things you don't know
[00:12:14] as opposed to trying to articulate what you know and figure out a way to verify what you know only.
[00:12:20] So that's a very interesting thing and probably going to get too deep here.
[00:12:24] But you talk, we talk about unknowns all the time.
[00:12:29] Yes.
[00:12:29] But nobody knows what an unknown is.
[00:12:31] Yes.
[00:12:32] So when you say discover the unknowns, how do you discover,
[00:12:38] how do you discover an unknown?
[00:12:39] So part of it is you build something and you make it break.
[00:12:44] And you figure out the thresholds of where it breaks.
[00:12:46] And most people are like, they don't want to make it break.
[00:12:48] And my thing is, my job is to make it break.
[00:12:50] So we did a prototype where we, your next thing.
[00:12:54] And as we did it, we said, this next one we're going to do in two weeks.
[00:12:57] We knew it was going to be too fast, but we wanted to see how it would break.
[00:13:01] And so we're learning about those kinds of things.
[00:13:03] And instead of trying to figure out the optimal length, it's like I need to know
[00:13:07] where is it too short and when is it too long.
[00:13:09] So that's going to give me the thing of what's the right pace at which to get people
[00:13:14] to do this process.
[00:13:15] And that's one of the things that people have to get comfortable with is because
[00:13:18] from a societal, from a hierarchical situation, nobody wants to ever be wrong.
[00:13:24] That's right.
[00:13:25] And if you're doing things in innovation, you're doing things in green line fashion,
[00:13:31] you're going to be wrong.
[00:13:32] Or you're not wrong, you're trying to figure out where those boundaries are,
[00:13:37] right?
[00:13:37] Exactly.
[00:13:37] But you're going to build something that's a failure.
[00:13:39] Right.
[00:13:39] Or it breaks or doesn't work or whatever.
[00:13:41] Right.
[00:13:42] We used to do experiments teaching RDE with windmills and there was times where
[00:13:46] it wouldn't even move because we chose the wrong variables.
[00:13:48] But we need to know that.
[00:13:50] Where's the limit?
[00:13:51] Because maybe we could have made it work and maybe it would be better if there was less.
[00:13:55] Right.
[00:13:55] So you have to think about it.
[00:13:57] You have to change your mindset of people think people look at you
[00:14:00] when you build something that doesn't work as a failure and it's a personal thing and all these
[00:14:05] types of things and stuff.
[00:14:06] But if you listen to the quote you used with Taguchi, he wasn't taking personal responsibility.
[00:14:11] No.
[00:14:12] In fact, he was giving the system the personal responsibility.
[00:14:15] Right.
[00:14:16] He's just the person.
[00:14:16] He was empowering the system that tell us what's best for it.
[00:14:19] He's the person putting it in different situations to tell him what to do.
[00:14:26] Like how it works?
[00:14:27] What's the causation?
[00:14:28] Ultimately, it was about the causation.
[00:14:29] And this is the difference between Deming used to debate George Box who was a statistician and
[00:14:34] Taguchi would always say, this is not about statistics.
[00:14:37] I only can make so many prototypes.
[00:14:40] And I know there's a statistical way to look at all that, but the reality is like
[00:14:44] I have to be able to extract as much information as I can as quickly as I can.
[00:14:48] That's an engineer's job.
[00:14:50] Well, and that gets in a whole philosophical thing, right?
[00:14:53] Is okay, I could have stagial significance.
[00:14:56] Yes.
[00:14:58] But it doesn't always work.
[00:14:59] It's not important.
[00:15:00] It doesn't always, when it gets out in the public, doesn't always work.
[00:15:02] Yeah.
[00:15:02] That way it's a context.
[00:15:03] That's right.
[00:15:04] And what you're trying to do in prototypes, you're trying to put different systems in
[00:15:09] different contexts and different variables to see all the different ways things can work
[00:15:14] and what doesn't work because what works for one person in one context doesn't always work
[00:15:17] for somebody in the other context.
[00:15:19] Exactly.
[00:15:19] So you're always trying to do that.
[00:15:21] And I also think with Red Line Green Line,
[00:15:23] what we're trying to get people to understand is be comfortable with the uncomfortable,
[00:15:26] which is also another ism that we use all the time.
[00:15:28] It doesn't really mean a whole lot, but it does.
[00:15:32] It's like uncomfortableness is failure.
[00:15:35] Uncomfortableness is admitting you don't know.
[00:15:38] Uncomfortable is not knowing what this thing's going to do.
[00:15:42] There's a lot of people we've watched that some are successful,
[00:15:44] some aren't, that they won't build something unless they know what's going to happen.
[00:15:48] Right.
[00:15:48] That's right.
[00:15:49] Well, you need to be uncomfortable.
[00:15:50] You need to make yourself uncomfortable enough to build something that you don't
[00:15:53] know what's going to happen.
[00:15:54] And you need to be, I always describe you as the, well, now it's probably even younger,
[00:15:58] but I always described you as a 12-year-old on Christmas that came down in the
[00:16:02] wonderment of all the presents and all the things going on.
[00:16:05] What's in the boxes.
[00:16:06] Exactly.
[00:16:07] It's the same thing when you're doing an experiment.
[00:16:09] The same thing when you're doing a prototype.
[00:16:11] You're trying to unpack that to see, oh, what worked, what didn't work.
[00:16:14] And it's not just the fail, not fail.
[00:16:17] That's not what you're looking at.
[00:16:18] You're looking at why did it fail?
[00:16:20] Why did it work?
[00:16:21] Those types of things are what you're really trying to get to.
[00:16:23] New theories only come from anomalies of things you couldn't explain.
[00:16:28] And so part of it is to realize, I'm actually trying to cause anomalies
[00:16:33] early in the development process.
[00:16:34] So I know one where it breaks and understand why it breaks because at some
[00:16:37] point I'm going to be way smarter.
[00:16:39] So when we get to launch and we have a problem, I know exactly what to do to solve it.
[00:16:43] And the other thing you want to talk about a little bit is,
[00:16:46] people are listening and they're like, okay, great, red line, green line, whatever.
[00:16:50] But it's like, as you look at your teams or as you're on a team,
[00:16:53] how do you know you're on which one?
[00:16:56] And I talked about a little bit in the beginning, but when you're on the red line,
[00:16:59] you're waiting.
[00:17:00] A lot of times you're waiting.
[00:17:02] On the red line, you actually are very organized.
[00:17:04] Like if I'm the manager looking at you, you look very organized.
[00:17:06] Everything's done.
[00:17:07] It's all checked up.
[00:17:08] We're just waiting for people to get done.
[00:17:09] You're just doing the next process.
[00:17:10] Or I know the next steps and here's what we're doing and here's the plan.
[00:17:13] Right.
[00:17:13] And you're giving updates and everything's moving on par
[00:17:17] and you're just going through the process.
[00:17:19] And it's almost like the process is dictating the product.
[00:17:22] That's right.
[00:17:22] That's what it feels like or looks like.
[00:17:24] Well, and there becomes a level of confidence to say,
[00:17:28] we can get this done.
[00:17:30] And ultimately the fact is I keep going, okay, we haven't hit a roadblock in a while.
[00:17:36] We're either not pushing ourselves far enough or the fact is we're missing something
[00:17:40] and it's going to come out of nowhere.
[00:17:41] Like it's that paranoia kind of part that you have to go like,
[00:17:44] I need to test it in the real world before I put it to the real world.
[00:17:49] So how do I actually simulate the real world for it?
[00:17:51] So I understand it's going to really work there because most of the stuff is built in,
[00:17:56] what I would say is laboratories or workshops where you're coding and it's like,
[00:18:02] there's no testing to it.
[00:18:03] And it's like all of a sudden it's like, is it really going to work?
[00:18:06] You don't know.
[00:18:07] So and then the other thing you see in a lot of Red Line projects is
[00:18:12] as you get closer to launch, things get busier.
[00:18:15] Yeah, because you're integrating.
[00:18:17] You're putting multiple things together.
[00:18:19] Well, to your point of always, now the timeline, now the time wall is real.
[00:18:23] The time down.
[00:18:24] I gotta launch it.
[00:18:24] That's right.
[00:18:25] I gotta deliver this piece of software.
[00:18:26] I gotta do whatever.
[00:18:27] But here's the other part of the mentality of Red Line is that when it doesn't work,
[00:18:32] what you're trying to do is find the special cause, the one thing that...
[00:18:35] Well, that's after launch though.
[00:18:36] Yeah, but even...
[00:18:37] I see a little bit of activity right before launch because everybody's scramble like,
[00:18:40] oh my God, doesn't work.
[00:18:41] But then it launches.
[00:18:43] Then you're like, oh, who?
[00:18:44] Yeah, we gotta fix this.
[00:18:46] We gotta fix that.
[00:18:46] It didn't work or it worked, but we missed these five things and now I'm getting error
[00:18:52] messages or whatever it might be.
[00:18:53] Right?
[00:18:54] You see more activity.
[00:18:55] When you're on the Green Line at the very beginning, you feel like everything's a mess.
[00:19:00] You actually feel uncomfortable.
[00:19:02] Yeah.
[00:19:02] And you embrace it uncomfortable because you don't know and you're
[00:19:06] willing to say we don't know.
[00:19:08] Right.
[00:19:09] And you're going to have some arguments up front between different people and different
[00:19:12] factions if we take CPG for an example, people doing the formulation of people doing packaging.
[00:19:17] They might argue because they need to understand what each one's doing because
[00:19:22] there are certain things that a package needs to do if you have certain things in it or
[00:19:26] certain things can't go into certain things.
[00:19:28] So you're going to hear those debates.
[00:19:30] You're going to hear those types of things.
[00:19:31] And it's not people trying to be a jerk.
[00:19:33] Right.
[00:19:34] It's understanding so then I can go build my experiments because if you tell me
[00:19:37] there's going to be acid in something and I'm the package you're going to engineer,
[00:19:40] I need to know that.
[00:19:41] Right.
[00:19:42] And then I can go do a bunch of different things and I can tell you, well,
[00:19:44] I can actually do something if as long as you stay below this amount.
[00:19:47] Right.
[00:19:47] So I mean one of the better examples is dishwashing soap, right?
[00:19:51] Somebody's like, okay, here's the temperature of the water that actually helps clean
[00:19:55] with this soap the best.
[00:19:58] You can't control it.
[00:19:59] Yeah.
[00:19:59] Some people use cold water to wash their dishes.
[00:20:02] Some people use really hot water.
[00:20:04] And the reality is I need to make sure it works in both.
[00:20:06] So instead of specifying, it should be 120 degrees Fahrenheit to basically wash dishes
[00:20:12] or above, blah, blah, blah, blah, or 180 or whatever it is.
[00:20:15] It's like, no, I needed the soap to actually work under all water temperatures.
[00:20:20] Right.
[00:20:20] And that becomes one of those things where it's like, well, that's not my job.
[00:20:23] It's like, it is your job.
[00:20:25] So on the green line you're going to see some activity.
[00:20:27] You're going to see some argument.
[00:20:28] You're going to see a lot of, you should see a lot of prototypes.
[00:20:30] You should see a lot of different people with different ideas, competing ideas.
[00:20:36] There should be some debate.
[00:20:38] Should not be hostile.
[00:20:39] No.
[00:20:40] Should be actually educational.
[00:20:41] Curious.
[00:20:42] Curious.
[00:20:42] Like curious.
[00:20:43] You're going to see at some point the work, the chaos kind of stop.
[00:20:48] And the chaos is a bad word for that.
[00:20:49] But the knowledge starts to solidify that enables you to kind of have
[00:20:54] actually more and more rational trade-off decisions.
[00:20:56] It's usually before you would see a team on the red line kind of come to that.
[00:21:00] You're going to see the green line people, okay, I've learned enough.
[00:21:04] Now we're integrating.
[00:21:04] Now we're doing all those things and I'm not rushed to get to the end.
[00:21:08] I'm actually letting the end tell me how far I can go instead of saying the end I have to be done.
[00:21:13] It's fixed time and variable scope.
[00:21:15] Like I'm going to adjust the scope to fit into the time that I have.
[00:21:18] And then you should, I mean every product has bugs and stuff.
[00:21:21] I mean, even if you're on the green line, it's not going to be perfect, right?
[00:21:24] But there shouldn't be as much.
[00:21:25] And one of the things we always talk about is it's cheaper to spend money early in the process
[00:21:31] than it is late in the process.
[00:21:33] Because we start making stupid trade-offs.
[00:21:34] But it's hard to actually understand the unknowns of what you should do up front.
[00:21:39] So a lot of cases people just wait.
[00:21:41] Right, but on green line you don't wait.
[00:21:43] No, you don't.
[00:21:44] When you see the graphic that we're going to use, you're going to see,
[00:21:47] hey, it costs a lot less here in the green line if we do all the work here
[00:21:52] because we have time.
[00:21:53] Yep.
[00:21:54] Right, we don't have to get an experiment done in a day.
[00:21:57] Yep.
[00:21:57] We have two days, three days, five days, a week, three weeks, whatever.
[00:22:01] When you start getting up against that timeline, things start costing more
[00:22:04] because you're under time pressure, you're under different things
[00:22:07] or you have to make it bigger or smaller or whatever.
[00:22:10] So those are the types of things we want you to take away from this.
[00:22:13] The other thing we want to take away from this is as always with what we talk about is
[00:22:18] be uncomfortable with the unknowns.
[00:22:20] Yep.
[00:22:21] Try to discover unknowns.
[00:22:22] Yep.
[00:22:23] But then also just try to always be seeking learning.
[00:22:27] Yep, that's right.
[00:22:28] And that's really what green line to me really means.
[00:22:30] Yep.
[00:22:31] And the quicker we can do that.
[00:22:32] The other thing I want to talk about a little bit before we go,
[00:22:34] and I know we're kind of longer than we normally are, is...
[00:22:38] We knew it was a big topic.
[00:22:39] There are no such things as a completely red line or a completely green line.
[00:22:43] No, that's right.
[00:22:44] I was going to say that because at some point what we've been doing
[00:22:46] like with some of the teams we work with, we ask them like,
[00:22:49] okay, where are you on the red line green line?
[00:22:51] Kind of continue them from zero to 10.
[00:22:55] Zero being red line and 10 being green line.
[00:22:57] And then ultimately what are two or three things you can do
[00:23:00] to make you more green line?
[00:23:02] And so it's this migration from red line to green line because it's just not possible to
[00:23:09] change the entire organization's behavior at once.
[00:23:11] And so it's about actually finding the three or four things you can do
[00:23:15] on this project to make yourself more green line and how to budget and to build the skills
[00:23:20] and the methods to help you be more green line, which are very different sets of tools.
[00:23:24] Well, sometimes context makes me have to follow a process
[00:23:27] Yes.
[00:23:28] Because of where we're at or what's going on.
[00:23:29] Right, so just keep that in mind.
[00:23:31] And then just as the homework we normally give, I think a couple things this time is
[00:23:37] first off just I want people to think back on a project they did and
[00:23:42] have you know, where do they think they were?
[00:23:44] Right.
[00:23:44] Where they red line, green line, why?
[00:23:46] Right.
[00:23:47] And the other thing is how do you actually help yourself or a team member
[00:23:52] get comfortable with that uncomfortableness?
[00:23:54] Yeah.
[00:23:54] How do you create that environment that makes it okay?
[00:23:57] To ask the questions.
[00:23:58] To ask the tough questions.
[00:23:59] Right.
[00:24:00] That's right.
[00:24:01] What I find is the teams that can ask the hardest questions to themselves are typically
[00:24:05] the team that's going to make the progress fastest.
[00:24:07] So I think that's really the homework for this one.
[00:24:10] So as always, thank you for listening and we hope to see you on the next one.
[00:24:13] Thanks, Craig.
[00:24:14] See you.