5 Dec 2023 · 25m · Curt Nickisch, Iavor Bojinov · 24 quoted facts
Generative AI projects fail far more often than traditional IT projects, with some estimates around 80%, because AI is probabilistic rather than predictable. Iavor Bojinov argues that success depends on handling five stages deliberately: selecting the right project, developing it through well-designed experiments, evaluating it on real people, getting people to adopt it, and managing it over time with audits.
The central tension is between moving fast and being careful. Companies want rapid experimentation, yet ethics, brand and trust need attention from day one. Bojinov's examples, including his own unused LinkedIn tool, Etsy's infinite scroll and LinkedIn's connection recommendations, show that accuracy alone does not guarantee value. Real-world testing and ongoing audits reveal surprises, making the process cyclical rather than a straight line.</p>
Unlike traditional IT, the same input can produce different answers, so you cannot know how good a project will be before building it. This adds failure points such as low accuracy and bias on top of normal IT risks.
Bojinov's LinkedIn analysis tool cut work from weeks to a day or two, yet nobody used it after launch because people did not trust it. He says users must trust both the algorithm and the developers, so intended users should be involved early.
Etsy spent about six months building infinite scroll and saw no effect. Two cheap tests, showing 50 results instead of 20 and slowing load times, could have answered the underlying questions with almost no engineering.
Bojinov says most products have a neutral or negative effect on the metrics they were designed to improve. AI sits inside a wider ecosystem, so a recommender might raise engagement while pushing customers toward lower-value activities.
A study published in Science found LinkedIn's People You May Know algorithm affected job applications and job outcomes a year later, by suggesting more weak ties. LinkedIn then began tracking these longer-term effects internally.
Bojinov says AI is probabilistic, so the same input can give different answers and you do not know how good it will be until you build it. That adds extra failure points such as low accuracy, bias and users who do not trust it.
The show notes list selection, development, evaluation, adoption and management. Bojinov describes the process as cyclical, since audits and monitoring often lead to new improvements.
Bojinov suggests weighing impact first, meaning alignment with business strategy, and then feasibility, meaning data, infrastructure and ethics. He warns that data science teams may pick projects just to use the latest technology rather than to deliver business value.
Bojinov says most products have a neutral or negative effect on the very metrics they target. AI interacts with the rest of the business, so a recommender might raise engagement but shift customers toward less valuable activities.
The study, published in Science, found the algorithm influenced how many jobs people applied to and got a year later, which it was not designed to do. Bojinov explains this through the theory of weak ties, meaning arm's-length connections that are especially useful for finding jobs.
Stated by the speakers. Each quote matches the transcript, which shows what was said, not that it is true.
Some estimates cited by host Kurt Nickisch put the failure rate of AI projects at around 80%, double that of corporate IT projects a decade earlier.
“some estimates find that around 80% of AI projects fail, which is double the rate of corporate IT projects from a decade ago.”
Iavor Bojinov says traditional IT projects are deterministic, giving the same answer each time they are run, unlike AI.
“with an IT project, you know pretty much the end state, and you know that, you know, if you run it once, twice, it will always give you the same answer.”
Iavor Bojinov says ChatGPT can give different answers to two users who write the same prompt.
“So think something like ChatGPT, me and you can write the exact same prompt, and it would actually give us two different answers.”
Iavor Bojinov built an AI data analysis product at LinkedIn that in testing cut analysis time from weeks to about a day or two.
“when we tested it, it cut down analysis time that used to take weeks into maybe a day or two days.”
A week or two after the launch event for Bojinov's LinkedIn AI product, no one was using it, which he attributes to lack of trust.
“And a week or two after it, like, no one was using it.”
Iavor Bojinov says the failed adoption of his LinkedIn AI product helped motivate him to leave LinkedIn and join Harvard Business School.
“one of the things that motivated me to leave LinkedIn and join, uh, HBS was the fact that I'd build this”
Bojinov says data science teams typically pick which AI projects to work on, and may not understand the business strategy.
“typically, when it comes to AI projects, it's the data science team that's actually picking what to work on.”
Bojinov says AI projects require early consideration of privacy, fairness and transparency, which traditional IT projects do not.
“So there's this whole area of responsible AI and ethical AI, which, again, you don't really have with IT projects, right?”
Bojinov uses the Netflix ranking algorithm as an example of an external-facing AI project deployed to customers.
“You have external facing projects where the AI is going to be deployed to your customers. So think like the Netflix ranking algorithm, right?”
Bojinov defines internal-facing AI projects as those deployed to a company's employees, such as sales prioritization tools or support chatbots.
“Internal facing project, on the other hand, are deployed to the employees.”
Bojinov says internal-facing projects usually fall to data science teams, while external-facing ones usually fall to AI or machine learning teams.
“internal facing projects are called sort of data science, and they fall under the purview of a data science team, whereas external facing projects tend to fall under the purview of an AI or a machine learning team.”
Bojinov says a study he did with LinkedIn showed experimentation can improve the final product by about 20% on key business indicators.
“in one study that I did with LinkedIn, we basically showed that when you leverage experimentation, you can improve your final product by about 20% when it comes to key business indicators.”
Bojinov recommends letting users opt in as alpha or beta testers so companies can experiment safely without risking brand image.
“a lot of companies have ways of you signing up to be like a alpha tester or a beta tester, and then you sort of get the latest versions.”
Etsy staff came up with the idea of building an infinite scroll feature for its marketplace.
“folks at Etsy had this idea that maybe they should build this infinite scroll feature.”
Bojinov says Etsy's infinite scroll took roughly six months to build and showed no effect in the experiment.
“It cost them, you know, let's say six months to build this.”
One hypothesis behind Etsy's infinite scroll was that showing 50 products instead of 20 per page would increase purchases.
“maybe instead of showing you 20, I showed you 50, then you might be more likely to buy things.”
Etsy's follow-up experiments found that adding a small delay to page loads had little effect, which Bojinov attributes to its unique products from independent sellers.
“adding a small delay doesn't make a huge deal to Etsy, because Etsy is a bunch of independent producers of unique products.”
Bojinov says most products have a neutral or negative impact on the metrics they were designed to improve.
“most products, uh, have either a neutral or a negative impact on the very same metrics they were designed to improve.”
Bojinov says a recommendation system could raise engagement while moving customers toward lower-value activities.
“That recommendation system could move your customers away from, say, high value activities to low value activities for you, whilst increasing, say, engagement.”
People You May Know is one of LinkedIn's most important algorithms and recommends people users should connect with.
“one of the most important algorithms at LinkedIn is this people you may know algorithm, which basically recommends which people you should connect with.”
LinkedIn measured the success of People You May Know by the share of invitations that were accepted.
“the way you measure the success of this algorithm is by basically counting or looking at the ratio of the number of people that were people invited to connect and what percentage of those actually accepted.”
A study published in Science, co-authored by Bojinov, found LinkedIn's People You May Know algorithm affected the jobs people got a year later.
“in this study that was, uh, published in Science and I have a number of co-authors on it, is that a year down the line, this was actually impacting what jobs people were getting”
Bojinov explains the LinkedIn finding using Mark Granovetter's theory of weak ties, which says arm's-length connections are most useful for finding jobs.
“There's this whole theory, uh, of weak ties that comes from from, uh, th- th- this person called Granovetter”
LinkedIn allowed publication of the audit research and then changed its internal practices to track longer-term effects such as job applications.
“The LinkedIn sort of opened their door, they were transparent about this, they let us publish this research, and then they actually changed their internal practices.”
Explains how AI's probabilistic nature creates more failure points, from low accuracy to bias, than traditional IT work.
“AI projects are not deterministic like IT projects, right?”
A personal story shows that a time-saving product can fail if users do not trust it.
“if you build it, they will not come”
Describes how to choose projects, including aligning with strategy and considering ethics before building.
“I always encourage people to start with the impact first.”
Distinguishes products for employees from those for customers, which shapes how closely developers can involve users.
“there's basically two types of AI projects.”
Shows how to experiment quickly without risking the brand and how testing hypotheses can save months of work.
“whenever you're running these experiments and developing these AI products”
Argues that models need testing in the real ecosystem because most products fail to improve their target metrics.
“most products, uh, have either a neutral or a negative impact”
Uses the People You May Know study to show how audits uncover unintended long-term effects.
“this was actually impacting what jobs people were getting”
Summarizes that AI is harder than other projects but worth the payoff when each stage is supported with infrastructure.
“It's not all hopeless.”
Turn breakthrough ideas into real results at the virtual HBR Innovation Summit on November 12th, with top CEOs and master classes on AI and growth. HBR executive subscribers attend free with exclusive programming November 13th. Learn more at hbr.org slash innovation summit.
Welcome to the HBR IdeaCast from Harvard Business Review. I'm Kurt Nickisch. Generative AI has the potential to change the business landscape, everything from marketing to supply chain analytics to customer service to sales. The applications are so rich, you can begin just about anywhere. But even if you have started experimenting, or your organization has, there's a big chance that those projects might fizzle out. In fact, some estimates find that around 80% of AI projects fail, which is double the rate of corporate IT projects from a decade ago.
Our guest today has experience leading AI projects, and he has some best practices to share. Iavor Bojinov is an assistant professor at Harvard Business School. He's also a former data scientist at LinkedIn, and he wrote the HBR article, Keep your AI projects on track. Hi, Iavor.
Hi, Kurt, thank you for having me.
I want to start with that failure rate. You would think that with all the excitement around AI, there's so much motivation to succeed. Somehow, though, the failure rate is much higher than past IT projects. Why is that? What's different here?
I think it begins with the fundamental difference that AI projects are not deterministic like IT projects, right? With an IT project, you know pretty much the end state, and you know that, you know, if you run it once, twice, it will always give you the same answer. And that's not true with AI. So you have all of the challenges that you have with IT projects, but you have this random, this probabilistic nature, which makes things even harder.
With algorithms, the predictions, you may give it the same input. So think something like ChatGPT, me and you can write the exact same prompt, and it would actually give us two different answers. So this adds this layer of complexity and this uncertainty, and it also means that when you start a project, you don't actually know how good it's going to be. So when you look at that 80% failure rate, there's a number of reasons why these projects fail.
Maybe they fail in the beginning, where, you know, you just pick a project that is never gonna add any value, so it just fizzles out. But you could actually go ahead and you could build this. You could spend months, you know, getting the right data, building the algorithms, and then the accuracy could be extremely low. So, for example, if you're trying to pick, you know, which of your customers are going to leave you so you can contact them, maybe the algorithm you build is really not able to find people who are going to leave your product at a good enough rate.
So that's another reason why these projects could fail. Or, you know, for another algorithm, it could do a really good job, but then it could be unfair and it could have some sort of biases, right? So the number of failure points is just so much greater when it comes to AI compared to traditional IT projects.
And I suppose there's also that possibility where you have a very successful product, but if the users don't trust it, they just don't use it, and that defeats the whole purpose.
Yeah, exactly, and I mean, this is exactly, uh, well, actually, one of the things that motivated me to leave LinkedIn and join, uh, HBS was the fact that I'd build this, what I thought was a really nice AI product for doing some really complicated data analysis with, you know, essentially, when we tested it, it cut down analysis time that used to take weeks into maybe a day or two days. And then when we launched it, you know, we had this really nice launch event.
It was really exciting. There were all these announcements. And a week or two after it, like, no one was using it.
Even though it would save them a lot of time.
Massive amounts of time. And, you know, we tried to communicate that, and people still weren't using it, and it just came back to trust. People didn't trust the product we had built. So this is, you know, one of those things that's really interesting, which is if you build it, they will not come. And this is a story that I've heard not just at LinkedIn, in my own experience, but time and time again, and I've written several cases with large companies where, you know, one of the big challenges is they build this amazing AI, they show it's doing a really, really good job, and then no one uses it.
So it's not really transforming the organization. It's not really adding any value. If anything, it's just frustrating people that, you know, maybe there's this new tool that now they have to find a way to avoid using and and find reasons why they don't want to use it.
So through some of those painful experiences yourself in practice, through some of the consulting work you do, through the research you do. Now you have some ideas about how to get a project to succeed. The first step seems obvious, but is really important, it seems selecting the right thing, selecting the right project or use case. Where, where do people go wrong with that?
Okay, they go wrong in so many different places. It sounds like a really obvious no-brainer, right? Every manager, every leader is consistently prioritizing projects, they're consistently sequencing projects. But when it comes to AI, there's a couple of unique aspects that needs to be considered.
Yeah, in the article, you called them idiosyncrasies, which is not something business leaders like to hear.
Exactly, but I think as we sort of transition into this more AI-driven world, these will become the standard things that people consider. And what I do in the article is I break them down into feasibility and impact, and I always encourage people to start with the impact first. Everyone will say, you know, this is a no-brainer. It's really this piece of strategic alignment. And you might be thinking, okay, that's that's straightforward. I know what my company wants to do.
But typically, when it comes to AI projects, it's the data science team that's actually picking what to work on. And in my experience, data scientists don't always understand the business, they don't understand the strategy, and they just wanna use sort of the latest and best technology. So very often, there's this misalignment between the most impactful projects for the business and a project that the data scientist just wants to do because it lets them use the latest and best technology.
The reality is, with most AI projects, you don't need to be using the latest and the cutting edge. That's not necessarily where the value is for most organizations, especially for ones that are just starting their AI journey, right? The second portion of it is really the feasibility. And of course, you have things like, do we have the data? Do we have the infrastructure? But the one other piece that I wanna call out here is what are the ethical implications?
So there's this whole area of responsible AI and ethical AI, which, again, you don't really have with IT projects, right? Here, you have to think about privacy, you have to think about fairness, you have to think about transparency, and these are things you have to consider before you started the project. Because if you try to do it, you know, halfway through the build and try to do it as a bolt on, the reality is it will be really costly, and it could almost require you just restarting the whole thing.
And, you know, which greatly increases, uh, the costs and and sort of frustration of everyone involved.
So the easy way ahead is to tackle the hard stuff first. That gets back to the trust that's necessary, right?
Exactly. And and you should have thought about trust at the beginning and all the way through. Because in reality, there's several different layers to trust, right? You have trust in the algorithm itself, which is, you know, is it free from bias? Is it fair? Is it transparent? And that's really, really important. But in some sense, what's more important is, do I trust the developers? Right? The people who actually build the algorithm. If I'm an intended user, I wanna know that this algorithm was designed to work for me, to solve the problems that I care about.
And in some sense, that the people designing the algorithm actually listen to me. That's why it's really important when you're beginning, you need to know who is gonna be your intended user so you can bring them in the loop.
Who is the you in this situation? If you need to know who the, you know, users are? Is this the leader of the company? Is this the person leading the developer team? Where's the direction coming from here?
So there's basically two types of AI projects. You have external facing projects where the AI is going to be deployed to your customers. So think like the Netflix ranking algorithm, right? That's not really for the Netflix employees, it's for their customers, or Google's ranking algorithm or ChatGPT, right? These things are deployed to their customers, so those are external facing projects. Internal facing project, on the other hand, are deployed to the employees. So the intended users are the company's employees.
So, for example, this would be like a sales prioritization tool that basically tells you, okay, call this person instead of this person, or it could be an internal chatbot to help your customer support team, right? Those are all internal facing products. So the first step is to really just figure out who is the intended audience, who is gonna be the customer of this, is it gonna be the employees, or is it gonna be your actual customers?
So very often, for most organizations, internal facing projects are called sort of data science, and they fall under the purview of a data science team, whereas external facing projects tend to fall under the purview of an AI or a machine learning team. Once you sort of figure out this is gonna be internal or external, you know who's gonna be building this, and very often, you know the amount of interaction you can have with the intended customers.
Because if it's your internal employees, you know, you probably wanna bring those people in the room as much as possible, even at the beginning, even at the inception, to make sure you're solving the right problem. It's really designed to help them do their job, whereas with your customers, of course, you're gonna have focus groups to figure out if this really is the right uh thing, but you're probably gonna rely more on experimentation to tweak that and make sure your customers are really benefiting from this product.
One place where difficulty arises for big companies is this tension between speed and effectiveness, right? They want to experiment quickly, they wanna fail faster and get to successes sooner, but they also wanna be careful about ethics. They're very careful about their brand. They wanna be able to use the tech in the most helpful places for their business. What's your recommendation for companies that are kind of struggling between being nimble and being being most effective?
The reality is you need to keep trying different things so that you can improve the algorithm. So, in, for example, in one study that I did with LinkedIn, we basically showed that when you leverage experimentation, you can improve your final product by about 20% when it comes to key business indicators. So that notion of we tried something, we used that to learn, and we incorporated the learnings can have substantial boost on the final product that's actually delivered.
So really, for me, it's about figuring out, like, what is the infrastructure you need to be able to do that type of experimentation really, really rapidly, but also figuring out how can you do that in a really safe way? You know, one way of doing that in a safe way is basically having people sort of opt into these, uh, like, more experimental versions of whatever it is you're offering. So the a lot of companies have ways of you signing up to be like a alpha tester or a beta tester, and then you sort of get the latest versions.
But you realize that maybe it'll be a little bit buggy, it's not gonna be the best thing, but maybe you're a big fan and that doesn't really matter. You just wanna try the new thing. So that's one thing you can do is sort of create a pool of people who you can experiment on and you can try new things without really risking that brand image.
So once this experiment is up and running, how do you recognize, you know, when it's failing or when it's subpar, when you've learned things, when it's time to change course? With so many variables, it sounds like a lot of judgment calls as you're going along.
Yeah, the thing I always advocate here is to really think about the hypothesis you're testing in your study. There's a really nice example, uh, and this is from Etsy,
And Etsy is an online marketplace for a lot of independent or small creators.
exactly. So a few years back, folks at Etsy had this idea that maybe they should build this infinite scroll feature. Basically, think of your Instagram feed or Facebook feed where you can keep scrolling and it's just gonna load just new things, it's gonna keep loading things. You're never gonna have to click next page. And what they did was they spent, you know, a lot of time, because that actually required kinda rearchitecting the user interface, and, you know, it took them a few months to work this out.
So, you know, they built infinite scroll, then they started running the experiment, and they saw that there was no effect. And then the question was, well, what did they learn from this? It cost them, you know, let's say six months to build this. If you look at this, this is actually two hypothesis that are being tested at the same time. The first hypothesis is what if I showed more answers on the same page? If I sort of showed more products on the same page, and maybe instead of showing you 20, I showed you 50, then you might be more likely to buy things.
That's the first hypothesis. The second hypothesis that this is also testing is what if I was able to show you the results quicker, right? Because why do I not like multiple pages? Well, it's because I have to click next page, and it takes, you know, a few seconds for that second page to load. At a high level, those are sort of the two hypothesis. Now, there actually was a much easier way to test this hypothesis. They could have just displayed, instead of having, uh, you know, 20 results on one page, they could have had 50 results, and they could have done that in, I don't know, like a minute, because this is just a parameter, so that required no extra
engineering. Showing your results quicker hypothesis, that's a little bit trickier because it's hard to speed up a website, but you could do the reverse, which is you could just slow things down artificially, where you just make things load a little bit slower. So those are sort of two hypothesis that you could, uh, if you understood those two hypothesis, you would know whether or not you would need to do this infinite scroll and whether it was worth making that investment.
So what they did in the follow-up study is they basically ran those two experiments, and they basically showed that there was very little effect of showing, you know, 20 versus 50 results on the page. And then the other thing, which was actually counterintuitive to what most other companies have seen, but because of the description you gave, actually makes sense, is that adding a small delay doesn't make a huge deal to Etsy, because Etsy is a bunch of independent producers of unique products.
So it's not that surprising if you have to wait, you know, a second or two seconds to see the results. So sort of the high level thing is, whenever you're running these experiments and developing these AI products, you want to think about not just about sort of the minimum viable product, but really, like, what are the hypothesis that are underlying the success of this, and are you effectively testing those?
That gets us into evaluation. That's an example of where it didn't work, and you found out why. How do you know that it is working or working well enough?
Yeah, absolutely. I think it's worth answering first the question of why do evaluation in the first place, right? You've developed this algorithm, you've tested it, and you've sh- only has good predictive accuracy. Why do you still need to evaluate it on real people? Well, the answer is most products, uh, have either a neutral or a negative impact on the very same metrics they were designed to improve. And this is very consistent across many organizations, and there's a number of reason why this is true for AI products.
The first one is AI doesn't live in isolation, it lives usually in a whole ecosystem. So when you make a change or you deploy a new AI algorithm, it can interact with everything else that the company does. So, for example, it could, let's say, you have a new recommendation system. That recommendation system could move your customers away from, say, high value activities to low value activities for you, whilst increasing, say, engagement. And here, you basically realize that there are all these different trade-offs, so you don't really know what's gonna happen until you deploy this algorithm.
So after you've evaluated this, what do you need to pay attention to when, you know, this product or these, um, services are are adopted, whether they're externally facing or internal to the organization, what do you need to be paying attention to?
Once you've successfully shown in your evaluation that this product does add enough value for it to be widely deployed, and you've got people actually using the product, then you sort of move to that final management stage, which is all about monitoring and improving the algorithm. And in addition to monitoring and improving, that's where, you know, you, you need to actually audit these algorithms and check for unintended consequences.
Yeah, so what's what's an example of an audit? An audit can sound scary.
Yeah, audits can absolutely sound scary, and I think it firms are very scared of their audits, right? But they all have to do it, and you sort of need this independent body to come look at it. And that's essentially what we did with LinkedIn. So there is this one of the most important algorithms at LinkedIn is this people you may know algorithm, which basically recommends which people you should connect with. And what that algorithm is trying to do is it's trying to increase the probability or the likelihood that if I show you this person as a potential connection, you invite them to connect and they will accept that.
So that's all that algorithm is trying to do. Is so, so the metric, right? The way you measure the success of this algorithm is by basically counting or looking at the ratio of the number of people that were people invited to connect and what percentage of those actually accepted.
Some sort of conversion metric there.
Exactly, and you want that number to be as high as possible. Now, what we showed, which is really interesting and very surprising in this study that was, uh, published in Science and I have a number of co-authors on it, is that a year down the line, this was actually impacting what jobs people were getting, and in the short term, it was also impacting sort of how many jobs people were applying to. Which is really interesting because that's not what this algorithm was designed to do.
That's an unintended consequence. And if you sort of scratch at this, you can figure out why this is happening. There's this whole theory, uh, of weak ties that comes from from, uh, th- th- this person called Granovetter, and what this theory says is that the people who are most useful for getting new jobs are arm's length connections. So people who maybe are in the same industry as you, and maybe they're, you know, say, five, six years ahead of you in a different company.
So, you know, people you don't know very well, but you, you have something in common with them. So this is exactly what was happening is some of these algorithms, they were increasing the proportion of weak ties that a person was suggested that they should connect with. They were seeing more information, they were applying to more jobs, and they were getting more jobs.
Makes sense. Still kind of amazing.
Exactly, and it's, and this is what I mean by these ecosystems. It's like you're doing something to try to get people to connect to more people, but at the same time, you're having this long-term knock-on effect on how many jobs people are applying to and how many jobs people are getting. This is just one example in one company, right? If you scale this up and you just think about how we live in this really interconnected world, it's not like algorithms live in isolation.
They have these types of knock-on effects, and most people are not really studying them. They're not looking at these long-term effects. And I think it was, you know, a great example. The LinkedIn sort of opened their door, they were transparent about this, they let us publish this research, and then they actually changed their internal practices. Where in addition to looking at those sort of short-term metrics about who's connecting whom, how many people are accepting, they started to look at those more long-term effects on the whole sort of, you know, how many jobs people are applying to, et cetera.
And I think that's sort of testimony to how powerful these types of audits can be, because they just give you a better sense of how your organization works.
A lot of what you've outlined and and of course, the article is very detailed for each of these steps, but a lot of what you have outlined is just how, um, I don't know, cyclical almost this process is. It's almost like you get to the end and you're starting over again because you're reassessing and then potentially seeing new opportunities for new tweaks or new products. So to underscore all this, what's the what's the main takeaway then for for leaders?
I think the main takeaway is to realize that AI projects are much harder than pretty much any other project that the company does. But also the payoff and the value that this could add is tremendous. So it's worth investing the time to work on these projects. It's not all hopeless. And realizing that there's sort of multiple stages and putting in infrastructure around how to navigate each of those stages can really reduce the likelihood of, uh, failure and really make it, uh, so that whatever project you're working on turns into a product that gets adopted and actually adds tremendous value.
Iavor, thanks so much for coming on the show to talk about these insights.
Thank you so much for having me.
That's Iavor Bojinov, an assistant professor at Harvard Business School. He wrote the HBR article, Keep your AI projects on track. And we have more episodes and more podcasts to help you manage your team, your organization, and your career. Find them at hbr.org slash podcasts or search HBR on Apple Podcasts, Spotify, or wherever you listen. Thanks to our team, senior producer Mary do, associate producer Hannah Bates, audio product manager Ian Fox, and senior production specialist Rob Eckhardt.
Thanks for listening to the HBR IdeaCast. We'll be back with a new episode on Tuesday. I'm Kurt Nickisch.