Wisdom From Steve Jobs: The Importance of Killing Good Ideas

Huggy Rao, Perry Klebahn, Kerry O'Connor, an army of people from the Stanford d.school, and I are making preparations for Customer-Focused Innovation, an executive program that we teach.  This is our third year and I was thinking back to past years (see here and here for posts).  And I remembered something interesting that I heard from an executive (I won’t name his company, as they were trouble then and still are in trouble), who described a talk that Steve Jobs had given to the senior team.

The thing I remember best was that Jobs advised them that killing bad ideas isn’t that hard -- lots of companies, even bad companies, are good at that.  Jobs' argument went something like this:  What is really hard – and a hallmark of great companies – is that they kill at lot of good ideas.  Sure, this is tough on people who have come-up with the good ideas as they love them and don’t want to see them die.  But that for any single good idea to succeed, it needs a lot of resources, time, and attention, and so only a few ideas can be developed fully.  Successful companies are tough enough to kill a lot of good ideas so those few that survive have a chance of reaching their full potential and being implemented properly.   I would also add that this approach also applies to good product and experience design.  If every good idea is thrown into a product, then the result is a terrible and confusing experience. (This seems to be the problem with the latest version of Microsoft word, it does everything, so therefore is very annoying and confusing to use.)

If you take this argument to its logical conclusion, it means that innovative companies might keep track of these two metrics:

1. How many good ideas are killed?  (If this number isn’t high enough, that is a bad sign.)

2. Are people complaining – even leaving – because too many of their good ideas are killed? (The idea here is that if no one is complaining about this problem, then there aren’t enough being killed.  The complaining, and even people leaving, is bad. But if no one is complaining, it is a worse sign.  Creating this kind of frustration is an unfortunate byproduct of an effective innovation process and if your people don't have enough pride and confidence to get upset when their innovative ideas are killed, then something is wrong with them -- or your culture.)   

These weird metrics may or may not work, but they make sense given Jobs’ argument (which I find quite compelling).   His argument also resonates with our experience teaching in the d.school  -- the groups that often do the worst work have too many pet ideas and can’t bring themselves to kill enough of them, so they don't do a decent job on any of them. Groups that can’t kill enough ideas also often suffer from bad group dynamics, either because multiple members won’t allow the group to kill their pet ideas, or because the group avoids difficult conversations about which ideas (and therefore whose ideas) to kill, and instead, tries to develop too many ideas (None of which are developed well -- which results in collective failure.)   As Perry tells our students, there comes a point in the process where you have to kill the ideas you have nurtured and come to love, even though it hurts.

P.S. A big thanks to Wally Bock over at Three Star Leadership for selecting this post as one of the top five posts of the week from business blogs.

 

Comments

[Nicole Tedesco]

There is nothing wrong with applying a little Darwinian reduction to the innovation process, but this can be done without alienating people (pissing them off).

[Kevin]

The practical problem, if a company were to implement this solution, seems more one of project selection.

This probably works for Steve Jobs, but the problem is you have to have a Steve Jobs at the top to make it work. Without a maven to lead this process, most companies would either default to a scoring process for new ideas (which would likely favor updates over innovation, especially for capital intense businesses), or play 'lunch box roulette,' where the largest lunch box would select whose (not which) projects get funded.

Just because you kill ideas, and just because people are complaining, doesn't mean your project selection is effective.

[Sandy Piderit]

In academe, the same principle applies -- the best scholars have many ideas for research and writing projects, and their ability to select among those ideas wisely, and cull others that would have less impact on others matters.

I like Pete's comment about creating opportunities for big ideas to incubate. I often write a page or two about a new writing idea, and then stick it in a file so I can reflect on which new project to develop once I have put current projects to bed. I also try out new ideas in class or with clients, to get a sense of the potential value of an idea that I could develop more fully.

[Wally Bock]

Congratulations! This post was selected as one of the five best business blog posts of the week in my Three Star Leadership Midweek Review of the Business Blogs.

http://blog.threestarleadership.com/2008/10/29/102908-a-midweek-look-at-the-business-blogs.aspx

I commented: I'm not a big fan of Steve Jobs as either a CEO or a human being, but I think he's the best CEO I've ever seen on product development. This post is about a provocative Steve Jobs insight about product development and companies.

Wally Bock

[Kevin Rutkowski]

In software development, I often run into project sponsors who insist that every good idea needs to be included in a product before it goes live. This often results in a project never getting completed or getting completed late.

I have found that when we can convince the project sponsor to reduce the number of features before we go live, it usually turns out that those features were not ones that the customers wanted anyhow. We then are able to use our resources to create new features based on customer input.

I also like the big rock/little rock approach that Pete mentioned. I have used that with success on software projects although I didn't think of it in those terms. I have found that it's effective to have most of a software development team focus on the big new features while having some part of the team solely focused on quick improvements to the software.

When we don't divide up the team, either the quick improvements have to wait a long time or they interrupt the development of the big new features. Either way, the project and user experience suffers.

[Greg]

Similar to editing a book. Take a good 500 page manuscript, edit down to 150 pages, then you have a very solid, meaty book.

[Bangladesh Corporate Blog]

Great article Bob. In many companies in Bangladesh however, the very few good ideas that get approval from management for implementation go without the due acknowledgment and some 'back-patting' of the source of the idea(s). So sometimes leaving the innovative employees clueless and without motivation.

[Andrew Meyer]

Bob,

I agree with a lot of what you said. When I read what you wrote about Steve Jobs killing good ideas, I think I draw a slightly different interpretation.

A company, like Apple or Pixar, must kill certain ideas because they are not aligned with the company structure. They may be excellent ideas and the execs might love to see them come into being, but companies have structures and every idea doesn't fit in every structure.

Sometimes, for an idea to take shape, it has to go out on it's own. It has to find its own field and go through it's own refinement process. For some ideas, that can happen within the structure of an existing company and for some ideas, they need to find their own environments, create different cost structures and discover their own business models.

Isn't that part of the essence of creative destructionism? Or maybe it can be better phrased as entrepreneurial rebirth.

Love your blog,

Andy

[Pete Abilla]

Bob,

In principle, I agree with your argument. One thing to consider, however, is the Toyota approach to innovation.

At Toyota -- where I spent some time and I continue to be a student of to this day -- the approach to innovation is both on the big rocks and on the little rocks.

The little rocks are in the form of hundreds of thousands of employee-generated innovations that are implemented every year. These are small, but the emphasis is on total involvement of the associate. Also, the cumulative effect of those small rocks is not trivial.

But, the more important effect of the small rocks is that it provides an environment for the big rocks to incubate and then develop and then flourish: a culture of small-rock innovation is the fertile soil required for big rock -- breakthrough -- innovation.

This approach overcomes the dichotomy that Steve Jobs seems to preach and that you support. It's a false dichotomy; not an either/or. True, prioritization is still important to do and a firm must be prudent in what is commits to doing, but the dichotomy can be reconciled in Toyota's approach to innovation.