I had known beforehand that there would be immediate resistance, as many GE execs would instinctively doubt Eric’s methods could work outside of software. So I had asked Eric to run an in-depth lean start-up session on one GE product after his presentation, a proof point to make “lean” real.
With agreement from then Transportation CEO Lorenzo Simonelli, Power CEO Steve Bolze, and Mark Little, the CTO and head of our Global Research Center, we picked the Series X. The X was a diesel engine project (an Imagination Breakthrough) that was frustrating us because our competition was ahead, and our teams declared they couldn’t get a new product out into the market for five more years. The lack of speed was killing us.
We took over a meeting room at Crotonville and filled it with a cross section of engineers, and sales and marketing people from the rail and energy businesses. And with the presence of both their business unit chiefs and a few corporate people, they were nervous.
Eric kicked off the workshop with the first step of his lean process—the leap of faith assumptions.
“What do we actually know versus what have we guessed?” he asked. “What do we know about how this product will work? Who are the customers, and how do we know they will want it? What aspects of the timeline are determined by the laws of physics versus our internal processes?”
The Series X team leaders almost licked their lips as they loaded in the PowerPoint deck. And they presented the approved business case for the Series X, including a revenue forecast showing the engine would make billions a year for GE stretching twenty to thirty years into the future. Like many GE business plans, it represented a hockey-stick graph of revenue growth that climbs to the moon in five years. It’s easy to forecast exponential growth.
“Raise your hand if you believe this forecast,” said Eric.
Everybody raised their hands.
Eric smiled.
“Seriously, who really believes that in the year 2030, you’re going to make exactly $16 billion from this engine?”
This time no one raised their hands.
“So, what do we actually know?”
One of the presenters cleared his throat and began to speak, more timid this time. There of course was some uncertainty, he said, because the plan was to build a Series X that was 20 to 30 percent more energy efficient and then use that superiority to convince customers to switch.
“Anything else we should know? Anything else unknown?”
Well, our biggest competitor had a network of franchises that had served as a very successful support system, generating loyal customer relationships.
“Ah,” Eric said. “So what’s your plan for distribution?”
“Well, we’re going to build our own distribution network.”
“Do you know how to do that? Have you done it before? And when are you going to do it?”
“After the product is done,” the rail presenter said, the absurdity of that claim hitting him as he spoke.
“So, you’ll spend five years building a product, and then more time setting up a distribution network, all for a product that by then might have been designed nearly a decade earlier,” Eric prodded.
The team didn’t have many assumptions by the end of Eric’s questioning. But Eric helped break things down by asking the kinds of questions he did, by going after the crazy projections without insulting those who gave them. I could see the team having their aha moment: they’d spent all their time focused on technical risks (i.e., “Can this product be built?”) and zero on commercial risks (i.e., “Should this product be built?”).
At this point, Eric made a radical suggestion. “The team has been trying to design for multiple contexts and no single target customer, which creates incredible complexity, and thus gets caught up in budgeting and political constraints,” he said. “Right?”
Murmured assents came from around the room.
“So, let’s pivot to something else,” he said. “Let’s target one user and radically simplify the engineering problem. Let’s do a minimally viable product, an MVP diesel engine.”
The room went wild. “That can’t be done!” said one. “You mean, an engine that would crash and burn?” said another. “We’re not talking model trains here.” Then one made a joke: “Not literally impossible. I could do it by going to our competitor, buying one of their engines, and painting ‘GE’ over their logo.”
Laughter at the silly software boy.
Eric laughed, too. I could tell he was used to this. Not once did he get angry at the mockery and resistance. This is one of the values of a good spark. They can say things that people inside the company couldn’t or wouldn’t.
“Just listen to me. Let’s scrap the multiple contexts and concurrent problems. What part of energy saving is the simplest to solve technically?”
A junior engineer in the corner spoke up when the silence began to elongate. “The power generation. I mean, not the moving parts to the wheels and so forth. Just the power generation.”
“Good. And if we were to just concentrate on that,” Eric asked, “how much time would we shave off?”
“My guess is we could drop from five years to two,” the engineer said.
“That’s pretty good. But let’s keep going. How long to build the first engine?”
Irritated grumbling rose from the group. “This guy doesn’t know the economics of mass production,” a production VP said. It was Ben Kaufman and the oven hinges all over again.
“I’m not asking about building a line of engines. I want to know how long to build a single unit.”
“A year,” the production VP said. “But what’s the point?”
“Anyone know a customer who’d buy such a unit, if we solved that technical problem?”
The grumbling about Eric’s ignorance of the manufacturing process boiled stronger now, but Eric’s new thinking was giving confidence to those who were willing to think in new ways, and a VP spoke up.
“Actually, I’ve got someone coming into my office every month asking for that, a guy in the marine sector. I’m pretty sure they’d buy it and let us test it with them.”
With that, the energy shifted in the room. Now we’re going from five years to one year for putting a real product into the hands of a real customer. Momentum started to push the team inexorably forward.
“You know, if you just want to sell one engine, to that one specific customer,” said one engineer, “we don’t even need to build anything new. We could modify one of our existing products.”
Jaws dropped. Everyone stared in disbelief.
It turned out that GE had an engine called the 616 that, with a few adjustments, would meet the specs for power generation called for by the original project. Instantly, this new MVP was an order-of-magnitude faster than the original plan: from five years to six months. In the course of four hours—by asking just a few deceptively simple questions—we had cut a project’s cycle time and found a way for the team to learn quickly.
As the workshop began to wind down, a manager who had remained mostly silent decided to speak up: “What is the point,” he asked, “of selling just one engine to one customer? We had a project worth billions, and now this tech boy talks for a few hours and we’ve got a project worth nothing.”
Instead of irritation or anger, Eric’s face displayed a weird kind of joy, that of a teacher who has gotten his student to understand one side of the coin—perhaps the wrong side, but at least one of them.
“You’re right,” Eric said. “If we don’t need to learn anything, if you believe in this plan and the attendant forecast that we looked at earlier, then what I’m describing is a waste of time. Testing is a distraction from the real work of executing to plan.”
The exec looked satisfied. But suddenly others at the meeting spoke up, the executive’s peers. “We all agreed we weren’t certain about our plan or forecast,” they sa
id. They began to discuss all the critical but unanswered questions that could kill the project: What if the customer wants something different than we assumed? What if service and support needs are more difficult to establish? What if…?
“Well, wouldn’t it be better to know sooner than later? To test, verify, and iterate?” Eric said.
As we shifted from the hard questioning to insider chatter, the most senior technical leader in the entire company and the most admired among the engineers, research chief Mark Little, spoke up with a comment that startled the entire room.
“I get it now. I am the problem.”
He was right. It was not that he was literally the one man impeding GE’s progress. But rather, he courageously realized from Eric’s questions and the recalcitrant replies they inspired, that he along with every other GE leader would need to acknowledge and embrace their own process of unlearning and renewal if the company was to move faster, learn quicker, and get closer to its customers.
From that day forward, the lesson we used from that session was this: It wasn’t that we didn’t have the technology or the budget. It was that we had too many internal obstacles that were slowing us down. Some obstacles were just approvals and the need to get many people engaged in the process. And some were mental ones that made people feel they had to do things a certain way. As Mark Little told me as we were walking out of the room that day, what was really important was that it changed the attitude of the team from one of being really scared about making a mistake to being engaged and thoughtful and willing to take a risk, shifting our mental model from fear of creating failures to thinking through how to test our assumptions.
It was emergent management at its best. Once we got Eric into the room and the team of engineers had the right framework for rethinking assumptions, neither Eric nor I really intervened. We were invisible. The team had to own it and work through it, and they did. One step at a time. Let’s get something out there, learn, pivot. It’s not going to be a straight line. There is going to be failure. Have faith that together we’ll get there.
Maybe the most profound genius of “lean” was that the assumptions people once used as excuses for inertia—i.e., it’s not profitable enough—could quickly be dismissed by focusing on a much smaller step. “Let’s just test this part of it first.” The Big Company mind-set meant GE teams only dreamed in scale. They couldn’t imagine that something small could eventually get them to big. But now we were taking the first step toward getting them to dream in a new way by breaking things down into smaller activities, to build, test, and learn as we went forward.
A week later, when we shared this example in our monthly growth review with Jeff, he got excited and we agreed to move those sessions company-wide in an initiative we named FastWorks. We created a cross-functional team of executives to oversee the expansion of the program across disciplines, from engineering to IT, but we especially focused on having marketing and HR lead it, realizing this was about culture change.
“We can do something here,” Jeff said, almost giddy. “Can we go beyond product scope? Can we use this to go after bureaucracy?” He had been increasingly frustrated at how long it took to get things launched.
Taking Up Residence
As our workplaces become more adaptable, increasingly we will hire practitioners based on finite missions, projects—in other words, for specific “gigs” or what I think of as “residencies” as more of a practitioner than a consultant. The range of expertise, skills, knowledge, and capabilities you can capture is vast. Think in terms of entrepreneurs in residence as well as designers, storytellers, coaches, scientists, activists, and so on.
Give your resident experts wide access. Make them a working part of your team and organization. Set expectations, metrics, intellectual property, and term limits in advance. Be realistic about what the residents can accomplish; give them time to discover and incubate ideas. Encourage your residents to share stories about their experiences inside and outside of the company.
We used the diesel engine project as a rallying cry. That it had so many engineers and multiple business leaders extolling the virtues of “lean” gave us confidence we could get the attention of GE’s leaders, and soon the business unit heads agreed to tee up other projects. In GE’s annual employee survey, a disappointing number of people said we were not responsive to customers, that we had become too inwardly focused, that we reverted to old processes and layered on other processes. We had developed even less appetite for risk and had created “checkers to check checkers.”
I tapped Steve Liguori and Viv Goldstein, who had been leading the innovation accelerator, to start training with “lean,” one team at a time. Each project was chosen intentionally. We wanted as many early successes as possible and with a range of use-cases, or examples, from IT deployment to new products to legal contracts. It was a new rallying cry for the customer, a huge effort across GE to show that the FastWorks methodology could work company-wide, in any degree of complexity, across any business, and all geographies.
After three months of working with the first group of eight teams, they returned to HQ for an update. It was a disparate group of brave souls, who were doing things that no one in their respective divisions knew about. Their one goal was to see if they could fail fast, fail small, learn, and iterate. And they did.
One of the first eight teams was led by Terri Bresenham in GE Healthcare, who had struggled for years to bring low-cost, high-tech health diagnostics into markets like India, because product decisions were made in Wisconsin. By moving product development from the lab to visits with the mothers of newborns and looking to learn quickly at low cost, Terri switched her unit’s focus from “Here’s our sophisticated baby warmer and we need to take the cost down,” to, “How do we take the typical baby-warmer product into places with no resources—a lightbulb aimed at the baby’s skin—and design up from there?” Soon enough, the baby-warmer project scaled and the World Health Organization was coming to Terri for advice.
FastWorks
Building on Lean Startup was what we called FastWorks, a jumping-off point for adaptation across teams, function, and industries. Our goal was to get more innovation faster, but also to get rid of bureaucracy and increase critical thinking across a wider part of the organization. You can tell if a culture is changing by the words people use and the actions they demand. Anytime something became slow or overburdened someone would declare, “Why are you working the old way? We believe in FastWorks here!” Here are the key steps of Lean Startup methodology:
Name the “leap of faith” assumptions that must be true if a planned product is going to succeed—like, say, that people will accept coffee in a capsule, or a car without a driver. This is a make-or-break question: What must be true for us to continue? What are our riskiest assumptions moving forward? Casting an issue as a HYPOTHESIS gives people a sense of relief from having to have all the answers. Can you challenge yourself to use this standard question often: What is your hypothesis?
Among the variations of leap-of-faith assumptions are the value hypothesis (Does this deliver value?) and the growth hypothesis (Will new customers discover it and buy it?).
Create minimum viable product (MVP) experiments to test those assumptions. In other words, create a rough and ready prototype that you try out on, and develop with, customers. After every one of the hundreds of training sessions we conducted, we gave teams a challenge: What are you going to test and learn when you go to work next Monday? You have to pick ONE project or activity that you think needs a different approach—maybe it’s a presentation, product feature, staff meeting. Pick something and experiment a new way.
Iterate. That means going through repeated build/test-and-learn cycles with MVPs, asking yourself what’s working and what’s not. After you validate your learning, use that information and start the loo
p again. That iterative cycle is called build-measure-learn.
Pivot or persevere. You continually use the feedback from the build-measure-learn cycle to assess if your efforts are working. On a regular schedule—every fifteen, thirty, or ninety days—decide whether to pivot from or persevere with the project. It’s about adapting the vision to reflect reality. But it also means that if it didn’t work, you need to pivot to something else. What can you do that does work? We added digital tools like Survey Monkey for getting feedback, Slack for ongoing team and customer conversations, and consumer 3-D printing for sharing early designs.
Beware vanity metrics. These are the numbers teams track that make us feel good and look good, but they don’t really indicate sound business traction. Think clicks on a digital ad or positive focus group feedback that doesn’t lead to engagement or sales.
Embrace innovation accounting. This concept pushes you to think about measuring what matters most for each stage of development. We had learned this in launching the Imagination Breakthroughs, when managers expected profits and market share before the idea had even been tested by customers. The goal we strived for: learning achieved divided by money spent and resources committed. It can be broken down into a few indicators:
Number of products/projects reviewed and in what stage
Number of project learnings versus gaps identified
Percent of projects with clearly articulated customer value
Imagine It Forward Page 29
