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.

Apple R&D and Steve Jobs Methodology: User Centric Design

I have been fascinated with Apple’s R&D successes (Platform-based approach, Portfolio Management, etc.). I have always suspected that Steve Jobs is a significant contributor to the R&D success at Apple. So I was thrilled to find a treasure trove of information on the Steve Jobs Methodology at the website Cult of Mac (In the transcript of an interview with ex-Apple CEO John Sculley On Steve Jobs). I think we can all learn a lot from the this article:

User experience centric design: See below
A long-term platform-centric vision to support said user experience (and perseverance to take risks to achieve the vision)
Leadership thoroughly engaged in R&D (e.g. Facebook, Google, Microsoft with Bill Gates, etc.)
Small product development teams with real respect across the organization
Understanding and focus on a niche (or align the entire company strategy around that niche)
Align hiring with product platforms / niche strategy (For Apple, hire the best)
The CEO defines and drives company culture!

I plan to write a post about each of the following aspects over the next few weeks. Let us get started with user experience.
We have discussed research papers and empirical evidence that collaborations with customers do not always pay off. This is especially important when the customer is not familiar with potential solutions to the problems they may be facing. My favorite example is about Windows: If Microsoft did a customer survey back in the 80s about what products should they be developing, would many customers have suggested Windows? Probably not. Steve Jobs seems to have known this early on:

Steve from the moment I met him always loved beautiful products, especially hardware. He came to my house and he was fascinated because I had special hinges and locks designed for doors. …

Steve in particular felt that you had to begin design from the vantage point of the experience of the user. He always looked at things from the perspective of what was the user’s experience going to be? But unlike a lot of people in product marketing in those days, who would go out and do consumer testing, asking people, “What did they want?” Steve didn’t believe in that. He said, “How can I possibly ask somebody what a graphics-based computer ought to be when they have no idea what a graphic based computer is? No one has ever seen one before.” He believed that showing someone a calculator, for example, would not give them any indication as to where the computer was going to go because it was just too big a leap.

One more lesson is that this user centric design has to be based on a long-term vision – not just the next step. This is important because a small step in user centric design is not going to build a long-term differentiator:

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.

Even user centric design is not enough though, one has to fine tune this idea and make a precise niche:

What makes Steve’s methodology different from everyone else’s is that he always believed the most important decisions you make are not the things you do – but the things that you decide not to do. He’s a minimalist.

I can not over emphasize the importance of User Centric Design. It drives long-term competitive advantages. But more important, it is the foundation of new software-driven digital world. So the culture of user centric design along with the digital revolution helped Apple succeed in the consumer electronics space (iPod, iPhone, etc). As opposed to Japanese businesses such as Sony, whose culture revolved around analog components:

The Japanese always started with the market share of components first. So one would dominate, let’s say sensors and someone else would dominate memory and someone else hard drive and things of that sort. They would then build up their market strengths with components and then they would work towards the final product. That was fine with analog electronics where you are trying to focus on cost reduction — and whoever controlled the key component costs was at an advantage. It didn’t work at all for digital electronics because digital electronics you’re starting at the wrong end of the value chain. You are not starting with the components. You are starting with the user experience.

I have been learning about how difficult it is to change cultures. The analog-centric culture still remains strong in Japanese consumer electronics companies. For example, they are ceding the entire user experience design to Google Android in the smart phone segment and accepting the fact that they can not compete!

And you can see today the tremendous problem Sony has had for at least the last 15 years as the digital consumer electronics industry has emerged. They have been totally stove-piped in their organization. The software people don’t talk to the hardware people, who don’t talk to the component people, who don’t talk to the design people. They argue between their organizations and they are big and bureaucratic.

In summary, what does and R&D manager need to remember:

There is no substitute for true product planning / development. We can not just ask the customer what to do (at least not all the time). We have to actually define what the user experience is going to be and then develop a product around it.
R&D managers have to link future technologies to customer experiences and develop a product development plan. This requires bridging technologists with marketing / product management and is rather hard to do. If one had resources like Intel, we could just hire stand-ins!
R&D strategy and vision has to be broad (platforms) and long (far in to the future)
User Centric Design has to be imbued into the company culture. Or else it will not work…

Others? Or continue on to the next component of the Steve Jobs Methodology: Long-term Vision.

Potential R&D savings from the Defense budget

New York Times Op-Chart The Pentagon’s Biggest Boondoggles has thoughts on cutting defense R&D costs (and quite a bit of historical data). It also mentions the GAO study that we had discussed in an earlier post:

Listed below is just a sampling of what systems could be ended without endangering America; indeed, abandoning some of them might actually enhance national security. These cuts would generate only small savings initially — perhaps just several billion this fiscal year, as contracts would have to be wound down. But savings would swiftly rise to more than $50 billion annually thereafter.