From Classroom to Boardroom: Applying Innovation Principles | Jon Cagan and Peter Boatwright | 584

Today I return to the question of taking research out into the world, and I speak with two professors who have collaborated together in many ways— teaching, researching, consulting, and book writing. John Kagan is the Coulter Head of Mechanical Engineering and lab professor at Carnegie Mellon University. And Peter Boatwright is professor at the Tepper School of Business and the director of the Integrated Innovation Institute, also at Carnegie Mellon University. Their most recent book, Managing the Unmanageable: 13 Tips for Building and Leading a Successful Innovation Team, came out in April of 2024, and it was written for a general business audience interested in how to manage innovation. Today we explore their collaborative work around innovation, specifically managing innovation. We talk about crossing the academic-practitioner divide, and we explore how they've worked to make their research results applicable and useful to leaders out in the business world. I'm Bill Sherman, and you're listening to Leveraging Thought Leadership. Ready? Let's begin. Welcome to the show, Peter and John.

Thank you.

Good. Great to hear.

So both of you have spent the better part of a career studying the work of innovation as process, as well as how to lead it. And the reason that I'm excited to have the two of you on this podcast is many people who practice thought leadership often do it in an expansive, exploratory way. They get excited about the next big idea and don't know when to pause that exploration. They're always interested in the next article they're writing, the next book, the next piece of research they're doing, rather than taking it to scale. And so I want to ask you around your book, Managing the unmanageable, which is around the innovation process within organizations. What does it mean to manage the unmanageable? Peter?

Sure. Well, the unmanageable that we're talking about is product and service innovation. And we recognize that, you know, there's lots of tools and methods, etc., but it's a chaotic realm, lots of exploration, but you need to at some point bring that together to make forward progress and make decisions. So that, you know, what we've looked at and researched is how to allow for and benefit from the chaotic nature, but also move forward productively towards bringing out products and services. So that's the unmanageable in particular that we're talking about.

And the structure of the book, and I want to give a little bit of an introduction to this, John, is really written and framed to someone who's tasked with leading an innovation team rather than a textbook.

That's, that's correct. And it's, it is really written for people who are practicing the management of innovation and innovators. It's very different than how you look at a process for innovation. What steps do you follow to create the product or the service? We're looking at how do you manage those people that are on teams that are actually going through that process.

And so, John, I want to ask you, do you start with a story tied to your research? And it involves peanuts and shelling, for example. Could you share that story with our audience and the research in terms of what the difference of managing that process looks like?

Sure, I'd be happy to, Bill. And so I did a study at Carnegie Mellon with a couple of colleagues, Josh Ghiori and Ken Kotovsky. And in particular, really, we were trying to understand what is the impact of managing a process versus going into and actually doing the design itself. And so we had a process of problem setup. We had 5 different designers. They were engineers, they were mechanical engineers who were all working on real time, trying to design a device that would shell peanuts by crushing the peanuts and removing the nut itself unarmed and then separating that out. But it was for a rural area where there's no electricity and there's no fuel. So we gave them an hour to work on this problem. And then we had another set of conditions where we actually removed someone from that team or a similar group of teams. So now there's only 4 people working on the problem instead of 5, and we replaced them with a manager. And that manager was the manager of the process. They didn't go in and meddle with the design itself. What they looked at is how are people communicating? How are they interacting? Are they staying on task? Are they solving the problem? And if not, they would intervene and nudge the team just on the process itself. And at the end of this, we took the sets of designs from both sets of teams and we had them evaluated. And if we look at excellent designs, which really are the ones that we want if we're going to be doing innovation, there was a fivefold increase in the excellent designs from the managed teams versus the unmanaged teams. So what we showed really was that management makes a huge difference, but it's management of the process. You want to let the innovator be innovative, but you want to manage them and not try to meddle with the design of the solution itself.

And if I sort of step back from that, one of the things that I recall is that the manager or the observer was limited not only in how they could communicate with the team, but the types of suggestions they could— I think they had note cards, is that correct, that they could hold up?

Right. They had a limited library of interventions that were deemed appropriate ahead of time, and they could only use those note cards. They weren't having a conversation. They would just put the note card down. It was up for the team to look at it, to recognize what the manager was saying, and then to, if they chose to, to act on that.

And I love that because by limiting the vocabulary, you wind up having a richness that you didn't have, right? Whereas if you freed someone up to say, hey, I could say anything, let me give them feedback on how the— I think the idea is, all of a sudden it's easy to get sucked in.

Well, it's that, and it also gives us rigorous data.

Absolutely.

Distant from our experiment to be able to truly be able to isolate and identify, in this case, the manager in terms of what we're trying to understand about the manager.

So Peter Winick, when you think about someone who's responsible and is managing a creative team, an innovative team, you and John distill down a list of 13 recommendations. There's a lot of literature out there, let alone the research that you've done. How do you take what could be an endless list of recommendations and similar to the experiment that John just described, give yourself a limited vocabulary of what are you going to communicate? On Process. So how did you come up with the recommendations?

So I think this partly comes from our experience in managing teams. It partly comes from conversations with others who were involved in innovation. And these were— I mean, a lot of material is known or pretty logical. Uh, we don't need to write about things that would— that managers would anticipate. So these tips were ones that struck us as interesting. And interesting is partly that there's some aha there. There's something that we weren't really sure if you took the hypothesis up front, should the manager behave in, you know, way A or method B, or should we structure teams in one way or another way? It's not necessarily obvious ahead of time. But then we explored and found out answers. So it's that kind of way that we decide on what tips to write about, or the ones that we found intriguing.

So a combination of perhaps sometimes counterintuitive, or things that need to be underlined because they're hard sometimes and get forgotten.

Definitely, and helpful. So there might be something that's interesting, but it doesn't really matter very much. We're looking— we tried to identify tips that were meaningful and making a difference on the team, as well as something the managers wouldn't already know naturally.

And as part of the work on innovation, both process and management, the two of you have collaborated as researchers, as colleagues. I think you've taught together. As well as consulted together. But how did you come together on working on this and sort of what complementary strengths did you bring? Because that's one of the things that you point out is that that complementarity. So Peter, I want to start with you of how did this come to be and let's explore the collaboration for a bit.

So John was working in innovation before I was, so he can talk about that at some point. I had, you know, the right time and the right place is as often as a— is an origin story is, is you happen to be in the right place at the right time. And, and for me, there was a course that needed an instructor. I was bringing a business background, and this is a product innovation, a very applied product innovation class that brought together the disciplines of design, business, and engineering. So I joined a team with John Kagan and Craig Vogel who had, you know, written a book, had been practicing in this area. And not only did I get to join in teaching, but they invited me to join in writing a book at the time. And so I was ramping up doubly quickly teaching with them and also iterating and working together to understand, to bring out a coauthored book, not the one we're talking about today, of course, This was a number of years ago.

And if I recall correctly, your expertise within business is around marketing. Is that correct?

That's correct. So my PhD is really in more of a statistics world. So numbers. But then, you know, we all see how much data is out there and how relevant it is for business decisions. And that's really what I studied was business decisions in the marketing field. Got it.

And so, John, collaboration from your perspective and the story, what would— Peter mentioned the course, but this led to consulting together, researching together. Take that story a little bit forward.

Sure. I'd like to take it back for a moment because I think—

Absolutely.

Of us coming together was very natural at a place like Carnegie Mellon University, where collaboration is part of its DNA. And so the idea of having even a course that has engineering and design and business— this course actually predated me and in some forms. So it was probably one of the first, if not the first in the world, that did that. So I took it over and from the engineering point of view, and then of course Craig Vogel, Peter mentioned, who was a designer, and then Peter came on board and we were, you know, we really were a great team together. But Peter and I really saw a wonderful sort of matching of spirit and interest and capabilities in that Peter really brought this marketing, business, pricing, statistics, viewpoint, and I brought the engineering, but also the design. And actually, my PhD was looking at AI and design back in the 1980s. So the computation together. And so between the two of us, we really were able to look differently at how people were solving innovation problems and helping them do it. So we worked extensively with different companies from different industries and helping them with their product development process. Sometimes walking them through developing a product, sometimes advising the process. That was partially the work that we did. Then we did research alone and together, coupled with all of those insights that led us to really— and especially in this context of a class that could become a laboratory, because this class works with actually industry sponsors for true innovations. There's been commercial products that have emerged out of this class.

And if I remember right, award-winning commercial products, right?

Award-winning, exactly. So that gave us the ability to not only study innovation process, but look at how we manage these very bright students who are quite accomplished as they were going through the process that led toward our really insights on management of the process. Again, that experience coupled with our research.

So In some ways, the class serves as a laboratory for if you wanted to set up a research hypothesis of the, hey, let's give them a design challenge and set up some conditions. You've got real-world challenges coming in as well from corporate entities saying, hey, how would we solve this? There's a natural intersection in the course between the academic and the applied, isn't there?

There is, because we're, we're trying to— I mean, a course is about teaching students. We're training them to be the next innovators that are going to be making a difference in our futures. Well, there's, you know, I'm going to use the word theory, but it's robust. Principles that guide the students appropriately that they can use repeatedly. However, it's theoretical until somebody really knows how to use it. And when you're— the only way I would say to learn, truly learn innovation, is to tackle a problem that nobody knows the answer to, but it's relevant to today, it matters today, and nobody knows the answer. And so that's where the corporate projects come in, is the companies bring kind of a context or a question and they know their domains. And so they're able to, you know, put their nose to something that say, this is an area of interest. But we're not reading some case study from 5 or 10 or 20 years ago where we all kind of know what happened. So that's the context where we're bringing repeatable, rigorous frameworks, but it's fleshed out and learned by application.

Well, and we were talking previously, and I'll tap to you in a second, John, around design thinking and design thinking being almost a common language that many people share. And there's often a nod of heads when people go, oh, design thinking, right? But that language had to first be invented, established, and communicated before it became part of the language of innovation. Sorry, John, I think I stepped on you in that conversation.

No, no, no, that's totally, that's totally fine. And I, I think, I think that that's right, though. But, you know, the idea of design thinking really has gone back quite a few years. It's become very prevalent of recent years, and some people think it's phenomenal and some people think it doesn't serve their purpose. And I guess that gets back to how do you use the tool? And that's where management needs to come in, because design thinking, just like total quality management before it, all have value if used in the right way and the process is managed. If they're used as the, the ultimate solution in and of themselves, then it could, it could fail, fail miserably. You know, so I think that this course that we've talked, been talking about certainly is about design thinking. But it's also about using a rigorous process. And I also want to add that the fodder for this book is not just that, that course. But as you mentioned, we've done a lot of work with industry, but also the rigorous experiments where through these different projects we have hypotheses that we can study in the lab through rigorous ways, and then we're able to gain deeper insight in terms of why certain phenomena take place like the ones we've talked about already.

If you're enjoying this episode of Leveraging Thought Leadership, please make sure to subscribe. If you'd like to help spread the word about our podcast, please leave a 5-star review at ratethispodcast.com/LTL and share it with your friends. We're available on Apple Podcasts, and on all major listening apps, as well as thoughtleadershipleverage.com/podcast. So let's go back to the example of the peanut sheller, um, and you wanted to push that research a little bit forward. What was the hypothesis there, and then what did you test?

Right. So, uh, you know, what's interesting is that we think about teams as collaborative people that get together and throw ideas off of each other. So here's an idea, what do you think? What do you think about this? Well, if we did this— and that's the whole idea of collaboration in people's minds. Well, one of the questions we really had is that make— well, that makes sense if, for example, we're going to design an iPhone or a car where we need a mechanical engineer, an electrical engineer, and a and a communication designer and a marketer, et cetera, et cetera. But what would happen if you had a problem like, for example, the peanut sheller, or you could do the same thing even designing a bridge, we've done both, where you have people who could solve that problem. And the question is, will it help them to be on teams when they can feed off ideas off one another? And so what we did is studied that problem by Taking 5 people, as we have done in the past, that are trying to, let's say, design this peanut sheller, and we put them in teams where they could collaborate with each other and work with each other free— freely. But we also took that same number of people and had them solve the problem alone and took the best result. We call that a nominal team. So they have the same number of people, but they're working alone. They're not part of a collaborative team. And so what we found was really striking in that the nominal team actually had sixfold better excellent designs than the collaborative team for designing that peanut sheller. And that was pretty interesting and surprising because it's very counter to how we think about teams. But again, in this particular case, we're seeing that that communication overhead Maybe there's other cognitive, cognitive methods or instruments that get in the way of people having the right way to solve the problem. And some people get lazy. So what we find is that actually that nominal team works better. So the point being, redundancy does not benefit you. Having different skills working together does work for you in your favor. But redundancy can be hurtful.

Thank you, John. So, Peter, you're fluent in— as you said, your PhD was in business statistics. That can be an incredibly rich, complicated language where you're speaking to a very narrow population that may understand what you're talking about. How do you balance the questions that excite you from a research perspective and the datasets perhaps that you want to collect that excite you and say, well, what's the aha and who would care? So talk me through that sort of research spark on your own as well as then the so what test.

Right. Humans are complex and I'm one of the one of the tribe. There are esoteric math kinds of things that are beautiful and might excite me that would be hard to translate, we'll say. But this domain of innovation is something that ubiquitously interests people. And so here's an area that makes a difference in lives. And so as we develop hypotheses and improve methods or find a solution, it's easier to translate. It's also personally intriguing. So one that we've come across with teams frequently, another kind of hypothesis and aha is kind of what's the utility of continuing to explore? Because innovation, you're discovering, uncovering, researching. It's fascinating and there's always more to learn.

Is it— there's another mountain to climb. Yeah.

Yes, exactly. And so there's tension in many teams because some team members want to push forward because there's so much that, you know, could be better. And there's others that, you know, where they feel constrained by whatever reason, it's time to kind of make some decisions. And so in one of John's research projects, we found out that continued exploration is often negative. That if you put your time, your effort towards things you've already found and optimizing and rising to the peak potential of an existing idea, you're far better off than continuing to hope for something better. So that was fascinating because often the argument, you know, on the team, they're saying, but we know so little, which is true relative to all that could be known. And so they, you know, here to have evidence that go ahead, move forward with what you have, that's helpful.

So if I can jump in real quick, Bill, because I want to give Peter some, some credit that I was thinking about as he was talking and where he brings the statistics in, uh, in a new way. So, you know, user research is something that's very prevalent. You really want to uncover what people's needs, wants, and desires are, and it's always a challenge early on of how many people should you ask. Right? You, you know, should you ask 100, 1,000? Do you keep going? How do you know whether you got every single great idea out there, every insight? Now, I don't even remember if we put this in the book or not, but nonetheless, just some of the many things we've been looking at. But it turns out that using data, you can do analysis of your interviews and find out that actually very quickly you plateau. And it may be 10 or 15 or even fewer subjects that you're talking with, potential customers, that you don't gain that many more pieces of new information. And once again, do you keep going forever or do you say, look, we have good information, we don't have to know everything to be able to move forward? And that's another example where the statistical background can really help inform early stage research.

I love that as an example because in fact I'm doing a primary research study now and we put the study through, you know, beta testers and we had the discussion on how many beta testers do we need for the study and we landed on 8. And now I'm hearing that that was closer to an informed and wise decision rather than Hey, go collect everybody you can for beta testing. So let's talk about the book a little bit. There could be many different goals for this book. What I want to ask each of you, and then just flow into a conversation, is if this book is successful the way you want it to What changes? What impact does it have? And Peter, I want to start with you.

Sure. The—

what would thrill me is for organizations, companies, etc., who have, you know, invested in innovation methods but haven't achieved their original vision or whatever reason, that they would see that it's, you know, a tool is great as long as you use it well, that if by— that they actually can achieve their hopes by really considering and tweaking how well they use, they use innovation. So many, many companies have invested in skills and invested in people, and yet surveys have indicated that they intended to achieve more than they have. My hopes is that now they will be— their interest will be reignited and they will invest and achieve the outcomes they originally were hoping for.

And John?

So I'll just build on that rather than give you a separate answer. And that is that I hope people who are in these positions of management recognize that managing the process versus trying to meddle with the solution is a profoundly different way to think about how to have your team succeed. If you have team members that are effective and skilled and you support them, you need to trust that they will have the ability to come up with a solution. You can make them more efficient and more effective by just focusing on how they're interacting in their process. And how you can create a team that is well-structured and well-positioned to be able to succeed in the innovation process.

So building on your build, John, one of the takeaways that I had from the book, which is going to resonate with me and thinking in a new way, is around an example of when the team sort of herds around a decision. Maybe they've decided something should be blue and you as the manager or leader going, I really think it should be red, right? And you've got this voice inside of your head. And I'm quoting from the book here. The natural instinct is to let that sort of excitement bubble and say, well, what do you think about red? Or have you considered red? Right? Because you want to contribute. But the takeaway that I had supported from that entire chapter was, well, what evidence or data do you have that supports blue? Which becomes a process question rather than a collaboration question. And just that reframing and having that ability inside my own head to go, am I asking about process or am I trying to get my hands involved? That's a level of self-awareness that I'm going to carry away and I'm going to hear your voices inside my head going, Are you really asking for them to make it red, or did— or do you trust them, right?

Well, Bill, I don't think I could have said that better, so I have no— nothing to respond. So I think that's a great summary.

So writing a book is almost an exercise in time travel, right? This book and this manuscript, and that I have in my hand for Managing the Unmanageable, you've written, it's now come out, but it's almost a manifestation of where you were 12, 18 months ago. And so you're having the split conversation, the book in book launch where you're talking about, hey, these are the new ideas that we're putting out into the world. Whereas from the research and the hypothesis side, you're living in a future which is unpublished. Not only in book but in peer-reviewed form. So I want to peek into the future of John and Peter. What questions are you exploring now? What interests and excites you, if you're willing to talk about it? Peter?

I'm going to let John start because I'm deciding what to say.

Not fair. No, that's fine. So, you know, it is interesting that we tried to write the book with insights that wouldn't be quickly become sort of old, no longer relevant. We think this is very, very relevant even though it was, as you said, it started to be written, you know, 18 months or so ago. Now, in terms of where we're going, so I've become very, very interested in the role of artificial intelligence in human teams. So my PhD back in the mid-1980s was looking at AI and design. So bringing design computation AI together. I've been working on that ever since. But in particular, when we think about, for example, that manager that we've been talking about with that peanut sheller problem, and if you put a manager in that team and they focus on the process, does the team perform better? We showed that it certainly does. Well, now what we've been looking at is can we automate that, that human manager? Because why do you want to have a person sitting there all day listening to conversation? And it turns out we can create AI agents that in real time can listen in on human conversations as a team and nudge that team, make suggestions when they start to go afield, when they're no longer aligned in what they're talking about, when one person is dominating the conversation., and it has actually the same or potentially marginally better outcomes as a human manager of the process. And so I'm doing a lot of work studying how to create AI managers, or AI coaches, I should say, more than AI managers, I guess it's a, a better term for this, that can help the team perform better in real time. So that's one direction that I've been looking at.

Well, and that becomes an interesting subset of what intervention, when, which are most effective. I can see almost a cascading tree that comes from that question of if you, because the AI, you can isolate a lot more off and replicate a lot more without having to have the manager. Peter Winick, what's intriguing you?

What's on my mind right now is application of, of what we put out. So how are, how are people digesting, using, implementing principles that are there in front of them? And then in working with them, there's often that discovery and exploration of what else, what else are, what are the existing questions? So I'd say that I'm in an exploration and application simultaneously phase instead of telling you, hey, I've already found my next vision. I'm excited about application for now and some more discovery.

Very clear. Thank you. And as we begin to wrap up, I want to ask each of you a last question. That is, you've been in the world of practicing research, thought leadership, and taking ideas to scale. What advice would you give someone who is practicing thought leadership, trying to get an idea out into the world? They may have a team, but it may be just themselves with an idea. What advice? John?

I'm going to let Peter answer this one first.

So because, you know, we often say do what I say, not do what I do. I did a lot of work myself and I know we've talked about collaboration with John, but also in the research world, it's been heavily individual for much of the work. I would advise that you find a way to involve others. And so the richness of the problems, the, the bigness of the impact, the large impact, but also you learn so much by working with somebody else and then you grow your number of people that you tap into here and there. So I, I say one of the advice I'm giving increasingly to students in our programs is even if you can solve a problem yourself, get somebody to work with. You'll have a better time, you'll do a better job, and you'll be better for it.

Fantastic. John.

So I'm struggling because I think there are the lone inventors out there, and invention is different than innovation. Now, could an individual be innovative? I think the answer is sure they can, but you can't be in isolation. So I agree with Peter, and that you really need to be looking at the world around you if you're going to be innovative. And even, you know, it's interesting, I'm just gonna ground this, you know, Steve Jobs was a visionary. Maybe Steve Jobs had a vision for the iPhone, but there were 1,000 people on his team that actually designed the iPhone, a paradigm-shifting true innovation that changed the world. And so the question starts to be, how do you create a team and empower them to be innovative, even if you have a vision yourself? So I'm not to say, it's not to say you can't have an individual use even many of the tools and methods in the book. As a matter of fact, every single chapter, we leave that chapter with some personal advice, how to apply yourself either in your work or in your life. So all of these methods apply to the individual that are trying to solve problems. And design innovation is problem solving. So therefore, a lot of this does apply. But again, if you're talking about something that's paradigm shifting in a large system, you probably have different needs and different disciplines that you need to bring together.

Wonderful. John Kagan, Peter Boatwright, thank you very much for joining us today. On leveraging thought leadership.

Thank you, Bill.

Okay, you've made it to the end of the episode, and that means you're probably someone deeply interested in thought leadership. Want to learn even more? Here are 3 recommendations. First, check out the back catalog of our podcast episodes. There are a lot of great conversations with people at the top of their game in thought leadership, as well as just starting out. Second, subscribe to our newsletter that talks about the business of thought leadership And finally, feel free to reach out to me. My day job is helping people with big insights take them to scale through the practice of thought leadership. Maybe you're looking for strategy, or maybe you want to polish up your ideas, or even create new products and offerings. I'd love to chat with you. Thanks for listening.