Why Failure Breeds Winners

Business Week article Intelligent Growth: Why Failure Breeds Winners has two important lessons for R&D managers consider growth or innovation investments (and R&D planning in general):

(1) Define what failure looks like for growth investments—specify when and why disinvestment should occur. Then stick to the plan.

This is quite intuitive, but I have been consistently surprised at the lack of clearly defined goals/objectives for R&D projects. This lack of discipline always results in goal creep, waste of resources and reduction in R&D team morale.
So, the take home message is to develop a clear plan on how the growth bet (or innovation bet) is going to get delivered in products and tie investments to that plan. Also decides what signals a clear departure from the plan and have the discipline to cancel projects if they do. This plan would help combat the valley of death that frequently leads to innovation project failure. Furthermore, this plan would also help to

(2) Upgrade your growth investment process by shifting analytical resources away from up-front screening toward life-cycle analysis. Create a ‘learning loop’ for management by dedicating staff to mid-cycle and post-completion project evaluations.

There is significant evidence that consistent evaluation of innovation projects can have tremendous benefits to the organization in terms of management learning and market understanding. However, this is difficult to do:

Cycle discipline is intuitive but difficult to recreate in a large, complex corporation. Less than 10% of the companies we examined exhibited this kind of financial savvy for more than a few consecutive years at a time.

But well worth trying because the results are impressive:

Companies that are able to consistently grow sales and improve margin across multiple business cycles realize a 4.4% compound total shareholder return (TSR) advantage relative to industry returns over pure growth leaders, and a 5.4% compound TSR advantage over pure margin leaders.

Apple R&D and Steve Jobs Methodology: Focus on your Niche

We have discussed four components of the Steve Jobs methodology (at least what I have gleaned of it).

User centric design: The entire R&D process revolves around delivering an experience to the users
Long-term vision: User centric design is supported by deep understanding of technology roadmaps
Engaged leader: R&D managers have to be personally engaged in R&D to make the vision of a user centric design practical.
Small focused R&D Team: High visibility and a lot of respect for key designers.

Let us now focus on next attribute of successful R&D management: Razor sharp focus on a strategic niche. As we have seen:

This goes back to Steve’s philosophy that the most important decisions are the things you decide NOT to do, not what you decide to do.

Again, I will be gleaning information from several sources to see if we can build a better picture. Let us start off with the information from the transcript of an interview with ex-Apple CEO John Sculley and see what we can learn…
Just to recap, the strategic niche for Apple was the absolute best user interface (or at least what Jobs would consider the best) and an industrial design to go with it:

Here’s someone who starts with the user experience, who believes that industrial design shouldn’t be compared to what other people were doing with technology products but it should be compared to people were doing with jewelry… Go back to my lock example, and hinges and a door with beautiful brass, finely machined, mechanical devices. And I think that reflects everything that I have ever seen that Steve has touched.

This strategic choice forces many decisions along the way. Some of them might not be popular, but Jobs clearly made them to stay true to the strategic niche:

Steve believed that if you opened the system up people would start to make little changes and those changes would be compromises in the experience and he would not be able to deliver the kind of experience that he wanted.

The strategic niche is a thread that tied EVERY aspect of Apple’s business together:

Absolutely. The user experience has to go through the whole end-to-end system, whether it’s desktop publishing or iTunes. It is all part of the end-to-end system. It is also the manufacturing. The supply chain. The marketing. The stores. I remember I was brought in because I had a design background and because I was a marketer. I had product marketing experience. Not because I knew anything about computers.

As we all know, Apple has a unique way to do its marketing that is tied in with the overall user interface focused strategic niche:

Steve loved those ideas. A lot of the stuff we were doing and our marketing was focused on when we bring the Mac to market. It has to be done at such a high level of perception of expectation that he will sort of tease people to want to find out what the product is capable of.

The same goes for advertising:

Most big companies delegate it way down in the organization. The CEO rarely knows anything about the advertising except when it’s presented, when it’s all done. That’s not how we did it at Pepsi, not how we did it at Apple, and I’m sure it’s not how Steve does it now. He always adamantly involved in the advertising, the design and everything.

It may not be possible for every leader to be as involved in every decision as Jobs was, but the next best would be to hire the right people to make those decisions and guide them appropriately. An example is the Apple stores (wildly more successful than any competitor)

He brought one of the top retailers in the world on his board to learn about retail ( Mickey Drexler from The Gap, who advised Jobs to build a prototype store before launch). Not only did he learn about retail, I’ve never been in a better store than an Apple store. It has the highest revenue per square foot of any store in the world but it’s not just the revenue, it’s the experience.
Apple stores are packed. You can go to the Sony center — go in the San Francisco center at the Moscone. There’s nobody there. You can go into the Nokia store, they have one in New York on 57th St. There’s nobody there.

It is also critical to emphasize the strategic niche in every aspect of the company’s business:

Once you realize that Apple leads through design, than you can start to see, that’s what makes it different. Look at the stores, at the stairs in the stores. They are made of some special glass that had to be fabricated.

Or here is an example from tying the user centric design strategic niche to manufacturing:

He was fascinated by the Sony factories. We went through them. They would have different people in different colored uniforms. Some would have red uniforms, some green, some blue, depending on what their functions were. It was all carefully thought out and the factories were spotless. Those things made a huge impression on him.
The Mac factory was exactly like that. They didn’t have colored uniforms, but it was every bit as elegant as the early Sony factories that we saw. Steve’s point of reference was Sony at the time. He really wanted to be Sony. He didn’t want to be IBM. He didn’t want to be Microsoft. He wanted to be Sony.

However, this may not be easy at all times. For example, Sony was an analog component focused company while Apple was focused on user experience. Jobs had to modify the Sony manufacturing processes to better suit Apple’s culture. The wired article The Untold Story: How the iPhone Blew Up the Wireless Industry shows us how following a strategic niche can be very expensive, but it can pay off if followed wisely:

The conversation about which operating system to use was at least one that all of Apple’s top executives were familiar with. They were less prepared to discuss the intricacies of the mobile phone world: things like antenna design, radio-frequency radiation, and network simulations. To ensure the iPhone’s tiny antenna could do its job effectively, Apple spent millions buying and assembling special robot-equipped testing rooms. To make sure the iPhone didn’t generate too much radiation, Apple built models of human heads — complete with goo to simulate brain density — and measured the effects. To predict the iPhone’s performance on a network, Apple engineers bought nearly a dozen server-sized radio-frequency simulators for millions of dollars apiece. Even Apple’s experience designing screens for iPods didn’t help the company design the iPhone screen, as Jobs discovered while toting a prototype in his pocket: To minimize scratching, the touchscreen needed to be made of glass, not hard plastic like on the iPod. One insider estimates that Apple spent roughly $150 million building the iPhone.

The question is what should an R&D manager do when different elements within the strategic niche conflict with each other. For example, Jobs was focused on BOTH user experience and industrial design:

Because Steve’s design methodology was so correct even 25 years ago he was able to make a design methodology – his first principles — of user experience, focus on just a few things, look at the system, never compromise, compare yourself not to other electronic products but compare yourself to the finest pieces of jewelry — all those criteria — no one else was thinking about that.

What would happen when strategic choices pitted user experience vs. industrial design? Apple selected user experience. Here is an example. This is what the Japanese engineers had to say about the original MacBook Air: No Waste Outside, Nothing but Waste Inside’

Can we say that the MacBook Air has a perfect, sophisticated external appearance, but its insides are full of waste?’ asked Mayuko Uno, a squad member, as if speaking for the engineers that had finished the teardown process.

Here is what the same publication had to say about the New MacBook Air:

“We were impressed by Apple’s commitment to good design while seeing the LED lamp that is located on the decorative laminate around the display and is lit when the camera is in use.”

So, if push came to shove, Apple was willing to compromise on everything but the user experience. Jobs was also willing to spend resources and make unpopular decisions to maintain the strategic niche around user experience. This is a pretty important lesson for all of us to learn. That is the level at which we need to define a strategic niche to develop successful products.

Enhanced R&D Risk Management

An interesting article from Sloan about How to Manage Risk (After Risk Management Has Failed). The article is talking about risk management in financial companies, but probably applies even more to R&D.

Yet at these companies, and at others with comparable “cultures,” risk management apparently performed quite dismally. How could this be? We contend that the answer lies in the concepts and practices of traditional risk management, which tend to look for risk in all the wrong places. That is, failure did not stem from merely paying lip service to risk management or from applying it poorly, as some have suggested. Instead, collapse resulted from taking on overly large risks under the seeming security of a risk-management approach that was in fact flawed.
emphasis added

Overall message from the article is pretty straight forward:

The traditional “frequentist” approach is based entirely on the historical record.
The alternative “Bayesian” approach incorporates judgments to complement historical data.
The Bayesian perspective provides more powerful and accurate results.

It is surprising that even many advanced R&D organizations delegate risk management to the quality control organization. Many quality engineers are removed from detailed R&D activities and identify risks mainly based on past history of similar products. So, as the article points out, R&D risks are identified based on historical failures (frequentist approach). However, new products often bring new failure modes that are not anticipated from older products. For example, electronic accelerators in Toyota resulted in uncontrolled acceleration. Quality engineers had failure modes and effects only for legacy mechanical accelerators. Hence, traditional risk management would not be able to identify these new failure modes.

A better way to address this situation is the integrate risk assessment into the R&D process directly. Engineers can then identify failure modes that they are concerned about and estimate risks based on their judgement (expert opinion). Results from testing can then be used to validate and enhance risk judgments using Bayesian statistics. This concurrent risk assessment is much better than increasing on quality control after the design is complete. Hence, this approach (unlike Toyota’s Devil’s Advocate Process) will improve quality AND reduce costs.

Apple R&D and Steve Jobs Methodology: Small Focused Design Teams

We discussed user centric design as the fundamental tenet of new product development under Jobs. We talked about how a long-term vision, bounded by user centric design and supported by deep understanding of technology roadmaps is critical to long-term success. We also talked about how a leader has to be engaged in R&D to make the vision of a user centric design practical.

Let us now focus on next attribute of a successful R&D manager: Building strong and driven team. Having a vision and ability to engage in the detailed R&D goes a long way towards motivating teams. However, Steve Jobs seems to have some more characteristics that helped him become successful. Again, I will be gleaning information from several sources to see if we can build a better picture. Let us start off with the information from the transcript of an interview with ex-Apple CEO John Sculley and see what we can learn…

When I first saw the Macintosh — it was in the process of being created — it was basically just a series of components over what is called a bread board. It wasn’t anything, but Steve had this ability to reach out to find the absolute best, smartest people he felt were out there. He was extremely charismatic and extremely compelling in getting people to join up with him and he got people to believe in his visions even before the products existed. When I met the Mac team, which eventually got to 100 people but the time I met him it was much smaller, the average age was 22.

So, the user centric design, a vision for the future and an ability to engage in R&D (along with a charismatic personality) helped Steve Jobs attract talent. More importantly, he kept his design team small:

The Mac team they were all in one building and they eventually got to one hundred people. Steve had a rule that there could never be more than one hundred people on the Mac team. So if you wanted to add someone you had to take someone out. And the thinking was a typical Steve Jobs observation: “I can’t remember more than a hundred first names so I only want to be around people that I know personally. So if it gets bigger than a hundred people, it will force us to go to a different organization structure where I can’t work that way. The way I like to work is where I touch everything.” Through the whole time I knew him at Apple that’s exactly how he ran his division.

So, the team size is a corollary of the level of engagement.

The other thing about Steve was that he did not respect large organizations. He felt that they were bureaucratic and ineffective. He would basically call them “bozos.” That was his term for organizations that he didn’t respect

Many people have asked me about how this level of engagement and this size of team is possible in their industry (where teams are thousand engineers strong). Here is one answer: keep product development focused:

The organization can become bigger but not the Mac team. The Macintosh was set up as a product development division — and so Apple had a central sales organization, a central back office for all the administration, legal. It had a centralized manufacturing of that sort but the actual team that was building the product, and this is true for high tech products, it doesn’t take a lot of people to build a great product. Normally you will only see a handful of software engineers who are building an operating system. People think that it must be hundreds and hundreds working on an operating system. It really isn’t. It’s really just a small team of people.

Clearly, in larger development projects, it may not be difficult to limit the team to one hundred people. As we will discuss below, the team developing iPhone had several hundred engineers. Furthermore, segregating product development from manufacturing and marketing (as suggested above) may also have significant disadvantages. But, the idea probably remains valid: One should have a core team of designers driving the process and the rest can follow.

Engineers are far more important than managers at Apple — and designers are at the top of the hierarchy. Even when you look at software, the best designers like Bill Atkinson, Andy Hertzfeld, Steve Capps, were called software designers, not software engineers because they were designing in software. It wasn’t just that their code worked. It had to be beautiful code. People would go in and admire it. It’s like a writer. People would look at someone’s style. They would look at their code writing style and they were considered just beautiful geniuses at the way they wrote code or the way they designed hardware.

The other important point is the respect for designers. As you saw above, designers are more important at Apple compared all other disciplines. Here is some more evidence:

An anecdotal story, a friend of mine was at meetings at Apple and Microsoft on the same day and this was in the last year, so this was recently. He went into the Apple meeting (he’s a vendor for Apple) and when he went into the meeting at Apple as soon as the designers walked in the room, everyone stopped talking because the designers are the most respected people in the organization. Everyone knows the designers speak for Steve because they have direct reporting to him. It is only at Apple where design reports directly to the CEO.

Later in the day he was at Microsoft. When he went into the Microsoft meeting, everybody was talking and then the meeting starts and no designers ever walk into the room. All the technical people are sitting there trying to add their ideas of what ought to be in the design. That’s a recipe for disaster.

I am definitely not suggesting that everyone make designers the top people just like Apple. Apple is a design focused company, not everyone needs to be like them. However, R&D leaders should decide on their strategy and build the necessary culture around it. This is easy to say and hard to do.

Microsoft hires some of the smartest people in the world. They are known for their incredibly challenging test they put people through to get hired. It’s not an issue of people being smart and talented. It’s that design at Apple is at the highest level of the organization, led by Steve personally. Design at other companies is not there. It is buried down in the bureaucracy somewhere… In bureaucracies many people have the authority to say no, not the authority to say yes. So you end up with products with compromises. This goes back to Steve’s philosophy that the most important decisions are the things you decide NOT to do, not what you decide to do. It’s the minimalist thinking again.

Clearly, respecting engineers does NOT mean accepting whatever they do:

Largely because Steve would shift between being highly charismatic and motivating and getting them excited to feel like they are part of something insanely great. And on the other hand he would be almost merciless in terms of rejecting their work until he felt it had reached the level of perfection that was good enough to go into – in this case, the Macintosh.

Of course, not all Steve Jobs did was perfect. Wired article The Untold Story: How the iPhone Blew Up the Wireless Industry gives us some more information that we can learn from:

It was a late morning in the fall of 2006. Almost a year earlier, Steve Jobs had tasked about 200 of Apple’s top engineers with creating the iPhone. Yet here, in Apple’s boardroom, it was clear that the prototype was still a disaster. It wasn’t just buggy, it flat-out didn’t work. The phone dropped calls constantly, the battery stopped charging before it was full, data and applications routinely became corrupted and unusable. The list of problems seemed endless. At the end of the demo, Jobs fixed the dozen or so people in the room with a level stare and said, “We don’t have a product yet.”

The effect was even more terrifying than one of Jobs’ trademark tantrums. When the Apple chief screamed at his staff, it was scary but familiar. This time, his relative calm was unnerving. “It was one of the few times at Apple when I got a chill,” says someone who was in the meeting.

Or this:

For those working on the iPhone, the next three months would be the most stressful of their careers. Screaming matches broke out routinely in the hallways. Engineers, frazzled from all-night coding sessions, quit, only to rejoin days later after catching up on their sleep. A product manager slammed the door to her office so hard that the handle bent and locked her in; it took colleagues more than an hour and some well-placed whacks with an aluminum bat to free her.

The stress was so high that people actually quit, but they came back! May be that is the proof of the respect they faced. However, respecting designers does not mean that Jobs shared all the information with them. The desire to control actually won out:

Through it all, Jobs maintained the highest level of secrecy. Internally, the project was known as P2, short for Purple 2 (the abandoned iPod phone was called Purple 1). Teams were split up and scattered across Apple’s Cupertino, California, campus. Whenever Apple executives traveled to Cingular, they registered as employees of Infineon, the company Apple was using to make the phone’s transmitter. Even the iPhone’s hardware and software teams were kept apart: Hardware engineers worked on circuitry that was loaded with fake software, while software engineers worked off circuit boards sitting in wooden boxes. By January 2007, when Jobs announced the iPhone at Macworld, only 30 or so of the most senior people on the project had seen it.

I guess the take home message is this: If the R&D staff are respected and they are motivated (with a vision and engagement), they will put with a lot and keep delivering!

How to Succeed in Distributed Product Development

As the pace of R&D increases around the world. there is in an increased emphasis on distributed product development across multiple organizations and multiple cultures. In fact, as we have discussed, the trend is to co-design subsystems and components across multiple organizations to improve time to market. Many observers have identified R&D management to be a significant challenge in this distributed development multi-cultural environment.

Putting It Together: How to Succeed in Distributed Product Development from the Sloan School of business has a good list of considerations (bold text below with my thoughts following) :

The flippant answer — “very carefully” — is also the right one: Please see this post on how to manage virtual teams.
Communication must be perfectly clear, especially if the project involves people from different cultures: See this post about spurring cross-functional integration in multi-cultural teams. Or this one about building focused R&D communities. See this one about keeping the team loose.
Incentives must be carefully aligned: See this post for information about what drives satisfaction in multi-cultural teams. Or this post for boosting performance of virtual teams.
Despite upfront planning, you still should be ready to adapt and realign as the inevitable snags occur.

Apple R&D and Steve Jobs Methodology: Engaged Leader

Let us continue our discussion on the Steve Jobs methodology. We discussed user centric design as the fundamental tenet of new product development under Jobs. We also talked about how a long-term vision, bounded by user centric design and supported by deep understanding of technology roadmaps is critical to long-term success. However, it is not enough to just have that understanding. A good R&D manager is able to roll up her or his sleeves and get engaged. A leader has to take part in the product development – that is probably the only way one can really understand technology challenges and translate desired user experience into real delivered products.

In fact, when we look around, all great innovative companies seem to have leaders that are completely engaged in their R&D. Bill Gates was driving product development personally in Microsoft’s hay day. As we have all seen, Zukerberg has personally driven R&D at Facebook. Google had to bring back their founders to actually get back to innovating. It is important for the leaders to be engaged because only they can have the cross organizational perspective. Steve Jobs also seems to personify this engaged leader. However, there may be many ways in which the leaders can be engaged. Let us start off with the information from the transcript of an interview with ex-Apple CEO John Sculley and see what we can learn…
Steve Jobs was engaged completely from the perspective of industrial design and user experience:

Whether it’s designing the look and feel of the user experience, or the industrial design, or the system design and even things like how the boards were laid out. The boards had to be beautiful in Steve’s eyes when you looked at them, even though when he created the Macintosh he made it impossible for a consumer to get in the box because he didn’t want people tampering with anything.

Furthermore, this interest was not just high level.

On one level he is working at the “change the world,” the big concept. At the other level he is working down at the details of what it takes to actually build a product and design the software, the hardware, the systems design and eventually the applications, the peripheral products that connect to it.

He actually worked to understand how better industrial design can be achieved:

The one that Steve admired was Sony. We used to go visit Akio Morita and he had really the same kind of high-end standards that Steve did and respect for beautiful products. I remember Akio Morita gave Steve and me each one of the first Sony Walkmans. None of us had ever seen anything like that before because there had never been a product like that. This is 25 years ago and Steve was fascinated by it. The first thing he did with his was take it apart and he looked at every single part. How the fit and finish was done, how it was built.

Many people can take apart products and learn from them. A great R&D leader actually builds a culture around the user experience. Jobs learned about manufacturing from Sony and built it into the Apple manufacturing:

He was fascinated by the Sony factories. We went through them. They would have different people in different colored uniforms. Some would have red uniforms, some green, some blue, depending on what their functions were. It was all carefully thought out and the factories were spotless. Those things made a huge impression on him.

And the results were impressive:

That went all the way through to the systems when he built the Macintosh factory. It was supposed to be the first automated factory but what it really was a final assembly and test factory with a pick-to-pack robotic automation. It is not as novel today as it was 25 years ago, but I can remember when the CEO of General Motors along with Ross Perot came out just to look at the Macintosh factory. All we were doing was final assembly and test but it was done so beautifully. It was as well thought through in design as a factory, a lights out factory requiring many people as the products were.

The same thinking is also visible in Pixar’s building architecture. Jobs personally got involved in the design of the building to drive an interactive culture:

Our building, which is Steve Jobs’s brainchild, is another way we try to get people from different departments to interact. Most buildings are designed for some functional purpose, but ours is structured to maximize inadvertent encounters.

The same trend is also visible in the design of the iPod supply-chain:

If you look at the state of the iPod, the supply chain going all the way over to iPod city in China – it is as sophisticated as the design of the product itself. The same standards of perfection are just as challenging for the supply chain as they are for the user design. It is an entirely different way of looking at things.

So, the take home message is this: R&D managers have to be system level thinkers that can drop down into detailed development when needed to help translate the system vision for their employees.

It was always an end-to-end system with Steve. He was not a designer but a great systems thinker. That is something you don’t see with other companies. They tend to focus on their piece and outsource everything else.

Not to say that there are no problems with an engaged leader. In case of Jobs:

His tradeoff was he believed that he had to control the entire system. He made every decision. The boxes were locked.

This desire to control can also lead to (arguably) poor decisions:

Before they could start designing the iPhone, Jobs and his top executives had to decide how to solve this problem. Engineers looked carefully at Linux, which had already been rewritten for use on mobile phones, but Jobs refused to use someone else’s software. They built a prototype of a phone, embedded on an iPod, that used the clickwheel as a dialer, but it could only select and dial numbers — not surf the Net. So, in early 2006, just as Apple engineers were finishing their yearlong effort to revise OS X to work with Intel chips, Apple began the process of rewriting OS X again for the iPhone.

However, as they say, the proof is in the pudding. Apple’s market value has surpassed that of Microsoft! An example from the Wired article The Untold Story: How the iPhone Blew Up the Wireless Industry:

After a year and a half of secret meetings, Jobs had finally negotiated terms with the wireless division of the telecom giant (Cingular at the time) to be the iPhone’s carrier. In return for five years of exclusivity, roughly 10 percent of iPhone sales in AT&T stores, and a thin slice of Apple’s iTunes revenue, AT&T had granted Jobs unprecedented power. He had cajoled AT&T into spending millions of dollars and thousands of man-hours to create a new feature, so-called visual voicemail, and to reinvent the time-consuming in-store sign-up process. He’d also wrangled a unique revenue-sharing arrangement, garnering roughly $10 a month from every iPhone customer’s AT&T bill. On top of all that, Apple retained complete control over the design, manufacturing, and marketing of the iPhone.

In summary, it is my opinion that great leaders get engaged in product development for their companies. They participate in the development and get to know their development teams (more about this in the next Apple post). They have a vision for where the company wants to go and they communicate it through actions, not just words. They have to realize that only they can tie together all the different disciplines involved in getting a product to the market and help achieve that. What do you say?

For more, please continue to the next component of the Steve Jobs Methodology: Small Focused R&D Team.

Why Project Networks Beat Project Teams

MIT Sloan Management Review has a great article on a new concept for R&D execution organization in Why Project Networks Beat Project Teams. The focus is on R&D of complex systems and driving collaboration and knowledge sharing. As frequent readers may recall, this is an area of great interest for me. We have often discussed how increase in complexity of systems under development has been the driving challenge in R&D management. We have also talked about knowledge workers in virtual teams and what drives collaboration and knowledge sharing in large multi-disciplinary teams.

The overall message of the article is straight forward: R&D managers should encourage at least some of the team members to bring information/knowledge from experts in their personal networks into the R&D activity. Involvement of these non-core members (experts) was shown to increase R&D success. Detailed learnings from the article are below:

To research the factors that affect the success of teams working on knowledge-intensive projects, we studied an established companywide recognition program for project teams at a large multinational food company. As part of that study, we surveyed 1,304 members of project teams in the company to identify key characteristics that promote success in knowledge-intensive work. We then compared responses from the project teams regarding how they went about their work with the company’s assessment — through the judging of the team recognition program — on the significance of the projects’ outcome.”

The idea they have come up with is that of Project Networks:

Typically, project networks consist of a core set of team members who bring in noncore contributors (such as other company employees, suppliers, consultants or customers) from their personal networks who can provide knowledge, information and feedback regarding the team’s task. The project network thus takes advantage of both the project team as a whole and the personal networks of the members.

The researchers studied 177 teams with 1,304 members in ONE food company (I have never worked with food companies, but I am sure their development can be quite complex). They found that team success – as measured by the same recognition measures across all teams – improved with the involvement of non-core members. Here is why they think the addition of non-core members is beneficial:

Project networks take advantage of the benefits noted by team-focused researchers — such as the commitment and dedication of members — but can overcome the risks associated with a small group’s limited perspective by crossing team boundaries for project feedback.
Project networks can also take advantage of the benefits associated with members who cross organizational boundaries for new ideas and broadened access to knowledge, yet the team structure provides accountability that can be lacking in informal personal networks.
…
Managers are often not given the luxury of hand-picking exactly the members they would like on a project team; they may have to go with who is available at the time. Encouraging project networks allows managers to look beyond the core project team and to take advantage of what noncore contributors outside of the project team have to offer.
emphasis added

According to the authors, project networks are beneficial in all kinds of situations (innovation, customer service or operational improvement). They only had two innovation teams – one with non-core members and one without. The team with non-core members was able to come up with a fundamentally new product, while the one without just had incremental improvements. The team involved non-core members by:

The Innovation Project A team involved a number of functions — sales, marketing, R&D and process development — and was located across six U.S. states in nine different facilities. Through its project network, the Innovation Project A team acquired relevant food formulation knowledge that customers had about their specific applications for this type of ingredient. In addition, the core members of the project team augmented their own knowledge by accessing food production expertise both from other colleagues in the company and outside vendors. While not core members of the team, these contacts were all part of the project network.

So, how and when should one involve non-core members? The figure from the article (replicated below) provides details. My suggestion is to do it carefully. Only involve non-core members when the project is complex. Even then, clearly define boundaries and ground rules. There is clearly a possibility of proprietary information leakage if the process is not managed carefully.

Seven steps to better brainstorming

McKinsey Quarterly has a list of Seven steps to better brainstorming. Clearly, Ideation is important and difficult to do well.

From R&D groups seeking pipelines of innovative new products to ops teams probing for time-saving process improvements to CEOs searching for that next growth opportunity—all senior managers want to generate better and more creative ideas consistently in the teams they form, participate in, and manage.

The article is a good read with great examples and explanations. Below is a quick summary of the steps:

Know your organization’s decision making criteria: Even though it is good to think outside-the-box, if the idea is going to be rejected by the culture anyway, it probably should not be pursued.
Ask the right questions: I can personally vouch for this one. It is better to be focused on a particular question rather than brainstorm on any broad topic. People come up with ideas that are far too diverse to follow through (Step 7 below)
Choose the right people
Divide and conquer: Divide into sub-teams
On your mark, set and go: Orient people before they divide into sub-teams (based on 2)
Wrap it up: Do not choose the top ideas during the brainstorming session. End the session on a high note. I will have to think about this one.
Follow up promptly: Many a brainstorming sessions have failed because of lack of follow through. I have been part of several of these. I think that the root cause of the lack of follow through may be step 1 and 2 above.

Apple R&D and Steve Jobs Methodology: Long-term vision

Let us continue our discussion on the Steve Jobs methodology. We discussed user centric design as the fundamental tenet of new product development under Jobs. Let us now focus on the long-term vision. I will be gleaning information from several sources to see if we can build a better picture. Let us start off with the information from the transcript of an interview with ex-Apple CEO John Sculley.

Steve had this perspective that always started with the user’s experience; and that industrial design was an incredibly important part of that user impression. And he recruited me to Apple because he believed that the computer was eventually going to become a consumer product. That was an outrageous idea back in the early 1980′s because people thought that personal computers were just smaller versions of bigger computers. That’s how IBM looked at it.
emphasis added

However, a long-term vision is not enough. One has to break it down into manageable steps. This is likely more art than science because many of the necessary technologies are not quite read at the time vision is generated. So the idea is to have a clear vision in mind while working through the steps over the long-term.

He was a person of huge vision. But he was also a person that believed in the precise detail of every step. He was methodical and careful about everything — a perfectionist to the end.

The key capability for an R&D manager, then, is to look at roadmaps of different technologies required to achieve the long-term vision and identify what to invest in when. Even when technologies do exist, they may not be implementable because of difficulty integrating into a user centric design. So, R&D managers need to be able to combine a vision with technology roadmaps AND integrate them into a user-centric design:

On one level he is working at the “change the world,” the big concept. At the other level he is working down at the details of what it takes to actually build a product and design the software, the hardware, the systems design and eventually the applications, the peripheral products that connect to it.

Let us now use the Wired article The Untold Story: How the iPhone Blew Up the Wireless Industry to dig a bit deeper in to this concept of long-term vision aligned with technology plans and user experience.

In 2002, shortly after the first iPod was released, Jobs started thinking about developing a phone. He saw millions of Americans lugging separate phones, BlackBerrys, and — now — MP3 players; naturally, consumers would prefer just one device. He also saw a future in which cell phones and mobile email devices would amass ever more features, eventually challenging the iPod’s dominance as a music player. To protect his new product line, Jobs knew he would eventually need to venture into the wireless world.
emphasis added

Many people were talking about convergence back then. But, vision is not enough. It needs to be aligned with technology roadmaps.

If the idea was obvious, so were the obstacles. Data networks were sluggish and not ready for a full-blown handheld Internet device. An iPhone would require Apple to create a completely new operating system; the iPod’s OS wasn’t sophisticated enough to manage complicated networking or graphics, and even a scaled-down version of OS X would be too much for a cell phone chip to handle. Apple would be facing strong competition, too: In 2003, consumers had flocked to the Palm Treo 600, which merged a phone, PDA, and BlackBerry into one slick package. That proved there was demand for a so-called convergence device, but it also raised the bar for Apple’s engineers.

One way to explore a vision as complex as a convergence device is to experiment. It is not enough to just trust the gut feeling about the vision, it is important to take small steps.

So that summer, while he publicly denied he would build an Apple phone, Jobs was working on his entry into the mobile phone industry. In an effort to bypass the carriers, he approached Motorola. It seemed like an easy fix: The handset maker had released the wildly popular RAZR, and Jobs knew Ed Zander, Motorola’s CEO at the time, from Zander’s days as an executive at Sun Microsystems. A deal would allow Apple to concentrate on developing the music software, while Motorola and the carrier, Cingular, could hash out the complicated hardware details.

However, results on experiments may not be as successful as hoped.

Of course, Jobs’ plan assumed that Motorola would produce a successor worthy of the RAZR, but it soon became clear that wasn’t going to happen. The three companies dickered over pretty much everything — how songs would get into the phone, how much music could be stored there, even how each company’s name would be displayed. And when the first prototypes showed up at the end of 2004, there was another problem: The gadget itself was ugly.

R&D managers need to have the faith in their long-term vision to learn from failures and continue. As we have discussed, Nokia had a prototype touch-screen smart phone in 2004 as well, but chose not to pursue it any further. Here is what Jobs did:

Jobs delivered a three-part message to Cingular: Apple had the technology to build something truly revolutionary, “light-years ahead of anything else.” Apple was prepared to consider an exclusive arrangement to get that deal done. But Apple was also prepared to buy wireless minutes wholesale and become a de facto carrier itself.

But the faith in the vision should always be supported by robust technology plans (or R&D plans in general):

Jobs had reason to be confident. Apple’s hardware engineers had spent about a year working on touchscreen technology for a tablet PC and had convinced him that they could build a similar interface for a phone. Plus, thanks to the release of the ARM11 chip, cell phone processors were finally fast and efficient enough to power a device that combined the functionality of a phone, a computer, and an iPod. And wireless minutes had become cheap enough that Apple could resell them to customers; companies like Virgin were already doing so.

Even a robust technology plan is not enough. One has to bring it together into a user centric design. Finally, may be we could use a process like spiral development to support this endeavor.

They built a prototype of a phone, embedded on an iPod, that used the clickwheel as a dialer, but it could only select and dial numbers — not surf the Net. So, in early 2006, just as Apple engineers were finishing their yearlong effort to revise OS X to work with Intel chips, Apple began the process of rewriting OS X again for the iPhone.

For more, please continue on to the next component of Steve Jobs methodology: Engaged leader:

When to rely on gut feelings

We have discussed papers and empirical data that show that reliance on gut feelings often produces sub-optimal results. Now we have a great explanation on why we should be careful about depending on intuition from the behavioral economist Dan Ariely (in the McKinsey Quareterly interview Dan Ariely on irrationality in the workplace):

One way to think about it is the following: imagine you stand on a field and you have a soccer ball and you kick it. You close your eyes and you kick it and then you open your eyes and you try to predict, where did the ball fall? Imagine you do this a thousand times; after a while you know exactly the relationship between your kick and where the ball is. Those are the conditions in which intuitions are correct—when we have plenty of experience and we have unambiguous feedback.

That’s learning, right? And we’re very good at it. But imagine something else happened. Imagine you close your eyes, you kick the ball, and then somebody picked it up and moved it 50 feet to the right or to the left or any kind of other random component. Then ask yourself, how good will you be in predicting where it would land? And the answer is: terrible.

The moment I add a random component, performance goes away very quickly. And the world in which executives live in is a world with lots of random elements. Now I don’t mean random that somebody really moves the ball, but you have a random component here, which you don’t control—it’s controlled by your competitors, the weather; there’s lots of things that are outside of your consideration. And it turns out, in those worlds, people are really bad.

So what is the solution? We should experiment more and test our gut feelings before we go all out and implement a pervasive solution.

This actually, I think, brings us to the most important underutilized tools for management, which [are] experiments. You say, I can use my intuition, I can use data that tells me something about what might happen, but not for sure, or I can implement something and do an experiment. I am baffled by why companies don’t do more experiments.

I think the reason why many R&D executives I know do not experiment more is the lack of information – both about factors driving the decision and potential impacts of the decision. For example, executives are normally forced to rely on gut feelings to decide future R&D investments. It is difficult to experiment because R&D projects are interlinked. It is difficult to see the impact of changing one program on all the other linked programs. Funding decisions also need to satisfy a multitude of often conflicting requirements. There are no tools to quickly understand the impact of investments of staffing or on competitive position. Even when information is available, it is normally at the wrong level of detail to actually make a difference. We need tools to help executives experiment effectively in R&D management.