Product Launch

Is your glass full less than 20 percent of the time?

So far in 2012, I have been seeing humor in some concepts that seemed exemplary in 2011.

I wrote about the concept of '20-percent time' at Google in my "From mediocre concepts to very successful launches - Insights from Pixar on developing great products' article. The summary from Google states:

"We offer our engineers “20-percent time” so that they’re free to work on what they’re really passionate about. Google Suggest, AdSense for Content, and Orkut are among the many products of this perk."

Through Dan Pink's TEDx talk on motivation, I knew of the practice of FedEx Days at Atlassian. There is a FedEx Day approximately once per quarter.

"Atlassian's "FedEx Day" is time set aside for developers to work on whatever they want with a skew towards our products. We tend to run "FedEx" with a fairly open format where you can do whatever you want as long as you can somehow relate it to our products."

What happens on the other days?

What happens during the other days? At Google, what happens the other 80 percent of the time? At Atlassian, what happens the other 58.5 days of the quarter?

It is easy to recall the opposite of 'passionate' and 'do what you want.'

Certainly, representatives from Google and Atlassian didn't intend for someone to infer that employment at their companies was unappealing on the other days. Certainly, Dan Pink isn't suggesting that companies limit the pursuit of autonomy, mastery, and purpose to special days.

Goals for 2012

During the other days, Google, Atlassian, and your company will strive to do what they believe is best to accomplish their missions. Special days will be a part of the strategy to do that and remain a successful business.

My goals for 2012 include:

• Publish more on the causal principles of NPD success related to individual performance and interactions
• Reduce internecine warfare that arise from functional silos within development organizations. 
• Increase the coherence of new product development efforts
• Provide more compelling input to those in new product development leadership positions
• Improve my agility. Help others improve their agility.
• Create more virtuous circles to help others in development networks
• Minify time in boring meetings

The list is partial and it is long. It will take my best efforts and a lot more than 20 percent of my time.

An answer to 'Should web designers know code?'

Recently, I was asked "Should a web designer know how to code?' Before answering, I realized that it would be wise to clarify the context of the question.

Knowing the context informs the answer

It is critical to contrast a web context and a more general new product development (NPD) context.

In a web context, a 'designer' moniker implies that one is likely to use Adobe Photoshop as a primary tool. Typically, there is a professional pride in items such as font selection, kerning, and the parameters of drop shadows. A 'developer' role may be split between 'front-end' and 'back-end.' Typically, a 'front-end' role includes references to the code that is communicating with the browser. This means that a 'front-end developer' is likely to have a proficiency using HTML, CSS, and Javascript. A 'back-end' role is likely to emphasize code running on a server or the attributes of the database.

In product development, 'front-end' typically evokes a time dependent role. Someone that works in the 'front end' emphasizes their contribution early in the development effort. They may contribute to brain storming and ideation sessions.

If the question is in a web context, inquired about the production environment. If the production team is small (less than three or perhaps five people), many of the contributors may tend to generalize and have multiple roles. In larger production teams, specialization is more likely.

In some production environments, there is 'designer' versus 'developer' culture. In this type of workplace contributors are organized by functional specialty (in silos) and progress may be measured by transferring files between specialists (handoffs). In such environment, these may be sufficient cooperation but opportunities for more collaboration. 

The debate

Sometimes a question such as 'Should a web designer know how to code?' escalates into a debate.

One position is that an individual should specialize in order to master their craft. Advice to an aspiring new contributor may include an admonition to read the classics in an attempt to uncover the principles. Other advice may be to study the contemporary examples and learn about the new techniques from the acknowledged masters of the craft.

Another position may be to consider the effort from a holistic perspective. Questions such as 'What is the business objective?' or 'How can I structure my contributions so that they can be integrated into the final solution by others?' may guide one's approach. Some may emphasize opportunities for cross-training. Others may suggest that knowing a sufficient amount of the jargon (vocabulary associated with a specific discipline) is sufficient. Others may suggest an understanding of the end-to-end process to ensure that one's contributions align with the ultimate objectives of the project.

An aspiration for contributors that are producing content for a multi-device world

The question "Should a web designer know how to code?" was the topic for the 14 December 2011 meeting of Refresh Pittsburgh. This group is 'A community of web designers & developers working to refresh the web design industry in Pittsburgh.'

The meeting ended by quoting Ethan Marcotte an independent designer and developer. He posted:

"In this brave new multi-device world we’re all designing for, I’m convinced more than ever that designers and developers need to be working more closely together. I spent the majority of my year on a large responsive design project, where the traditional “design team” and “development team” divide didn’t exist. We realized that our respective tools—a design app on one hand, HTML/CSS on the other—can’t design beyond the desktop without help from the other. Starting with a mockup, testing ideas in prototypes, bringing elements back into Photoshop for further refinement—that kind of “back and forth” worked incredibly well for us, and I’ll be looking to bring that collaborative approach into my future work."

Is transformation possible? How soon?

In considering the question 'Should web designers know code?' one approach may be to start with the following passage and substitute 'designer' for 'artist' and 'website' for 'game.'

“For a cross-discipline team that is measured by value added to a working game, the role of an artist shifts to that of a ‘game developer’ who specializes in art. An artist doesn't simply create an asset for someone else to put in the game and make fun.  The artist participates in the creation of an experience, where art has an equal value. By having a voice in the discussion about what is being created, the artist elevates the value of what they create and minimizes the cost of creating it.” -  from the book "Agile Game Development with Scrum" by Clinton Keith (@ClintonKeith) page 227. Published in 2010.

Perhaps 'Should designers know code?' is not the best question.

If a team already has the services of a valuable contributor that is a designer that doesn't know code, sending them to 'code-camp' isn't going to help this project or the next one. The result will be the same as if you gave them a "Learn how to code in 3 days' or a 'Code for Dummies' book. Peter Norvig covered this in 2001 in his "Teach Yourself Programming in Ten Years" post.

Perhaps alternative questions are 'What can be done to maximize the value of the contributions of my non-coding designer to this project and the next?' and 'What can this non-coding designer do to improve the contributions of others (including the ones that are coding masters) on the team?'

Kobayashi Maru Thinking: How to Get to Great Faster

Kobayashi Maru Thinking provides an approach to solve intractable problems.

Requisitioning nine women

Perhaps you have heard the following riddle.

If it takes one woman nine months to produce a baby, can nine women produce a baby in one month?

Many people come to the conclusion that there is not a clever answer to this riddle. In addition, they find a bit of humor in the way the riddle is presented.

 

How long will it take to complete my project?

This riddle is based on a statement from the classic book The Mythical Man-Month: Essays on Software Engineering by Frederick P. Brooks, Jr. While at IBM, Brooks added more programmers to a project falling behind schedule. The rate of progress on his project didn't improve. He concluded:

“The bearing of a child takes nine months, no matter how many women are assigned.”

The statement is used to support advice commonly known as Brooks' Law

"Adding more people to a project that is already late will make it later."  - Brooks' Law 

Brooks' Law suggests that a no-win situation exists when a project is late. Possible options seem to be limited:

• Add resources
• Don't add resources

One argument for adding resources is that new specialists will enable other team members to focus on assigned tasks and the project tasks will be distributed so that everyone's workload will be more manageable.

Typical concerns about adding people include:

• The people added to the project will consume precious development time. 
• The new people will detract from the productivity of the existing team members while they are becoming familiar with the project. 
• Adding more people to the project will increase the communication overhead and keeping the project synchronized will be more difficult. 

Typical arguments for not adding resources include:

• An acceptable outcome can be achieved through persuasion. The proper incentives will increase productivity. 
• Maintain the budget. There is a perception about saving money in the short term. There are suggestions that shortcoming can be addressed later or by some other group.
• Changes will be disruptive. Making changes will have negative impacts on the current efforts. 

Problems that may result from not adding resources include:

• An overworked team will not be able to complete all the required tasks. 
• There will be other negative consequences. 
• Additional mistakes and will be made. 
• Individuals are more likely to suffer from fatigue.    

A problem with too many new product development projects

It is common for new product development projects to be late (or to fail) for many reasons, When choices are made to add resources, unsophisticated decision makers are likely to make sub-optimal choices that may produce some of the following results:

• Promised project completion dates must be re-evaluated
• Death march conditions for the development team
• User experiences degrade for users of the product. Disappointed users write negative product reviews.
• Extra work for the post-sales support team to fix problems that were not addressed during development
• Progress is hindered on the next new product development project

Sub-optimal choices are not likely to produce great products that position companies for maximum success in the future. This post reviews some common beliefs about troubled projects and then addresses one way to overcome what may be perceived to be no-win scenarios.

Note: "Sometimes, Brooks’ Law is cited inappropriately as an argument for not adding resources to an understaffed project. In addition, Brooks’ Law does not apply directly to contributors that perform tasks that can be easily partitioned and isolated—those tasks that do not have a significant learning curve and require minimal communication." [2]

How does one overcome what appears to be a no-win situation?

No-win scenarios

Question: Who is noted for saying "I don't believe in the no-win scenario."

Answer: Captain James T. Kirk in the movie "Star Trek II: The Wrath of Khan." Kirk was referencing his experiences with the Kobayashi Maru test. 

In the Star Trek culture, a Kobayashi Maru reference reminds fans of an apparent no-win scenario where a solution is possible by changing the starting conditions to redefine the problem.

Kirk overcame the apparent no-win scenario of the Kobayashi Maru test by changing the starting conditions. In contrast, he escaped the Genesis Cave by out-whiting Khan.

Changing the Starting Conditions

Let's review the original riddle and re-examine the goal. The desired goal was to produce a baby within one month. There were no requirements specified regarding the woman. There were no explicit requirements regarding the number of women. There were no other project constraints.

To achieve the goal, one solution involves altering the initial conditions by selecting a woman with an offspring already developing in her body. Note that it is the same woman as shown in the first image but this image reveals a fact that was not shown earlier.

By changing the appropriate starting conditions, one can achieve the desired result within the desired time.

Changing the starting condition for new product development projects

Kobayashi Maru thinking is characterized by changing the starting conditions to solve an intractable (wicked) problem. It does not involve:

• A Compromise
• Turning a difficult situation into an opportunity (a lemons to lemonade approach)
• A Hobson's choice (a free choice where only one option is offered. A 'take it or leave it' choice)
• A Pivot (as defined by @EricRies and the #LeanStartUp advocates is changing directions (vision) but staying grounded in what you have learned )

How will you close your next innovation gap (the time between the product concept and delivering value to an abundant number of customers)? How will you get to great faster that your previous attempts or faster than competitors?

I will not provide recommendations to overcome specific problems in this post. I can summarize several factors that may inspire more creative starting conditions. These include:

• Enlist individual contributors with the an abundance of domain knowledge and a mastery of their skills.
• Facilitate interoperability within the development network (encourage cross-functional cooperation and collaboration, improve communication,...)
• Evolve combined efforts produce the appropriate experience for the users of the product 
• Adapt development models better suited for development networks (environments where many individual contributors are either geographically dispersed or where individual contributors are employed by separate organizations) 

Kobayashi Maru Examples in New Product Development

One example of Koybayashi Maru Thinking was documented in my first article in Visions Magazine - How to Change Direction in New Product Development in 30 Days without a Budget [3]. This case study from HP documents the transition of someone in the role of documentation specialist to designer. Instead of complaining about the product's user interface, it was changed without a project budget increase and within the previously defined time constraints.  

Many Kobayashi Maru Thinking examples relate the story a person changing hats (roles) for a finite period. In the Star Trek example, Kirk role changed from test taker to strategist and programmer.

Do you have another example of Kobayashi Maru Thinking in new product development? What starting conditions can you change on your new product development project?

Additional resources

[1] The Mythical Man-Month: Essays on Software Engineering Anniversary Edition. 1995 by Frederick P. Brooks, Jr., Page 17.

[2] Insights on Brooks' Law and Launch. Article by Mark A Hart in the June 2008 issue of Visions Magazine at http://www.oplaunch.com/documents/Insights_on_Brooks_Law_and_launch.pdf

Brooks' Law Wikipedia entry. According to Brooks, his law is an "outrageous oversimplification."

For additional insights on overcoming Brooks' Law, view the comments at http://stackoverflow.com/questions/76526/i-need-this-baby-in-a-month-send-me-nine-women where the question is asked "Under what circumstances - if any - does adding programmers to a team actually speed development of an already late project?"

[3] How to change direction in new product development without a budget. Visions Magazine. October 2003

Faster Consequences via Deliberate Practice

This post builds on the "You are what you practice" section of my "Deliberate Practice - Pursuing Perfect Product Launch" article in the March 2011 issue of Visions magazine. This post explores how two teams decided what to pursue and what to make the focus of their practice.

One team experimented with ideas and concepts but didn't build interactive prototypes. The other team advanced their learning by building and testing interactive prototypes faster than their competitors.

The Original Concept from the Google team

As an April Fools Day contribution, a team at Google presented a product concept. They released a video for a faux product - Gmail Motion BETA. 

The pitch for this product was  ‘Using your computer’s camera and a spatial tracking algorithm, Gmail Motion tracks physical movement and turns it into actionable commands’

This product video was moderated by Paul McDonald. According to his LinkedIn profile, he is the current GMail product manager. During the video, the apparent functionality of the product was faked using common video production techniques. 

From conception through production, I suspect that the video required at least a day of effort by a small team. Video production incorporated studio lighting, high quality audio, a finely tuned and edited script, high quality animations, and a supporting cast.

The team at Google knows that much of this product concept is cumbersome. It is reasonable to assume that although they have sufficient resources to develop many product concepts, the Google team understands that this product concept is impractical.

I was entertained by the faux product video. 

Crafting a Functional, Interactive Prototype

Later that same day, another team from the University of Southern California Institute for Creative Technologies (USCICT) posted their video on YouTube (a Google property). From the project description provided by the Google team, the ICT team developed an interactive prototype using a Microsoft Kinect system and functionality from their FAAST project.

Additional information:

Engadget post 

Project reference 

Institute of Creative Electronics

The system was demonstrated by Evan A Suma, Ph.D, a Postdoctoral researcher. One commenter stated ‘consequences will never be the same.’

I admire the team the built the prototype. They integrated their technology and demonstrated a working system in approximately one day. 

You are what you practice

Expanding on the ‘You are what you practice’ concept, one company produced the faux product video that reflects their capability for creative humor. Their deliberate practice has prepared them to produce another humorous video. The next time, their video production may be faster.

The ICT team produced a video that captured my imagination. Their video demonstrated their toolkit. The speed of their response to the faux product video from the Google team, demonstrates their ability to implement and iterate and learn.

On 5 April, Evan Suma of ICT wrote "the Gmail marketing manager contacted me yesterday and said they thought the video was awesome, and thanked me for doing it"* 

The ICT team can produce valuable consequences faster. 

The actions of the ICT team remind me of Colonel John Boyd's OODA loop described in a book by Chet Richards. The aptly titled book is Certain to Win.

 

* e-mail correspondence. Evan A Suma and Mark A Hart

Success Limiting Factors in New Product Development

During new product development, some problems are fatal. In other cases, certain factors may limit the success of development efforts.

To facilitate the discussion of items that impact qualities such as the efficiency or effectiveness of new product development, I began using the phrase "Success Limiting Factor" (SLF) on 11 December 2010.

The intent of the phrase success limiting factor is to convey an explanation that avoids linear reductionism. The intent is to provide insights that are more subtle than overly simplistic conclusions about "the weakest link."

Rationalized post-project review comments

Perhaps you have overheard conversations in a post-project review session that can be summarized by comments such as:

• "The project was a success but our timing was bad. The problem is the economy."
• "The project was a success but our target customers are buying the competitor's product. Our competitor has more resources."
• "The project was a success but the news of a few minor defects hurt our sales. Why can't our marketing department do a better job of controlling what is posted on Twitter?"

Instead of congratulating ourselves regarding internal metrics, new product developers should be reminded that when we fail to deliver value to an abundant number of customers, the project failed.

Impacts of SLFs

SLFs are items that impede new product development. They are detrimental to success. There are many SLFs and each has a unique relative impact. The most important indicator from all SLFs is the impact at product launch. This is the aggregate indicator.

Some SLFs have a deterministic nature. In some cases, there is a simple cause and effect relationship. These types of factors have first-order effects.

In other cases, the relationship between an SLF and the impact is more complex. These types of SLFs have second-order (or higher) effects. The impact varies because of interactions in the system. For more information refer to the Wikipedia entry for a complex adaptive system.

Achieving more success with less wasted effort

For a given set of project constraints (budget, resources, scope, time table,...), what does it look like when a team achieves better results?  When plotted as revenue versus time, the desired outcome is more success for the development investment. This is more return on investment.

When SLFs are reduced, customer's are more likely to recommend a product to their friend. This is the basis for assessments such as net promoter score.

In future posts in this series, I will identify specific SLFs and suggest ways to reduce their impact.

Listen to Success Limiting Factors in New Product Development [4:50 minutes, 1.9 MBytes, Apple iTunes / QuickTime is required]

Implicit Coordination and Collaboration Equity

Have you ever reminisced about your best experiences in new product development teams. I have. I wanted to be able to explain why some experiences were outstanding.

Explicit coordination

Some organizations embraced a sequential development approach that transfered responsibilities from one group of specialists to another. Projects proceeded in mutually exclusive phases. Progress was assessed by management at predetermined times. This approach relied on central control and explicit coordination.

Explicit Coordination includes coordination via planning and coordination via communication which includes feedback processes, personal coordination, and the exchange of information (1)

Information was stored and knowledge was managed.

Typically, job classifications were used to select project resources. Sometimes, it was presumed that individuals were interchangeable if there was someone with a similar curriculum vitae in the talent pool.

There was tension between engineering and marketing. Sales and Marketing had different priorities. There were debates between individuals with titles such as Product Manager, Product Marketing Manager, and Product Owner. Within the 'research and development' group, some individuals considered themselves a Designer while others claimed the role of Developer.

Often, it was just logomachy - a dispute concerning words. The origins of the misunderstanding could be traced to experiences from another prevailing framework or another company culture.

Implicit coordination

Implicit coordination is a team interaction behavior. It is a process that takes place when “team members anticipate the actions and needs of their colleagues and task demands and dynamically adjust their own behavior accordingly, without having to communicate directly with each other or plan the activity”

When there is implicit coordination, individuals do more than just 'turn in their assignment.

When implicit coordination thrives, collaboration equity is maximized.

Collaboration Equity is the amount of positive value your NPD receives from the totality of your efforts to maximize collaboration effectiveness.

I prefer teams that are paragons of implicit coordination. The Rico et. al. article includes of model that details the contributions to team implicit coordination processes.

I will provide several suggestions to facilitate implicit coordination. I welcome your suggestions.

1. Ramon Rico, Miriam Sanchez-Manzanares, Francisco Gil, and Cristina Gibson. 2008. “Team implicit coordination processes: A team knowledge-based approach.” Academy of Management Review, Vol. 33, No. 1, pp. 163-184.

Are processes incidental to the value stream?

In the Agile Manifesto, the statement,"Individuals and interactions over processes and tools," declares relative value from the perspective of the signatories. In other development environments, processes and tools may seem to command a lot more attention than people. A people versus process discussion may polarize many participants.

This post explores a potentially more polarizing idea:

"In New Product Development (NPD), processes are incidental to the value stream" (1)

From Wikipedia:

Value Stream: The an end-to-end business process which delivers a product or service to a customer or consumer. The process steps along the way may both use and produce intermediate goods, services and information to reach that primary end.

Analysis may suggest the removal of intermediate process steps, goods, services and information that do not move the value stream forwards to its primary end, provided they do not serve important secondary ends such as compliance, quality control or employee loyalty.

Initially, the value is realized at launch when people begin to interact with your new product.The value depends on the user experience with your new product. For the most part, customers don't care too much about your processes.

Speculative Products and Speculative Processes

In NPD, most projects begin as speculative product concepts. A speculative product is not developed for a particular customer and there are no guarantees that sales will be abundant. Your 'finished' product may not have a great product/market fit. If your product doesn't have traction in the marketplace, an expensive advertising campaign or extensive public relations effort will be inefficient.

The product concept is speculative. The processes used to commercialize the product are more speculative even if it is implied that the processes are aligned with 'Best Practices.'

Incidental

Incidental doesn't imply unimportant. 

It is a reminder that NPD is a multi-variable problem and the desired primary output is value in the economic domain. Sometimes contributors to NPD get distracted by proxy variables such as waste, cycle time, variability, efficiency, and unit cost and processes. (2)

In new product development, mobilize your team to delight customers and incidentally you can publish the results on your brilliant processes that facilitated your success. 

Acknowledgements

1. The title of this post was inspired (in part) after viewing a presentation by Hal Macomber on Target-Value Design at the UK Lean Conference in 2009.

2. According to Don Reinertsen, the goal of NPD is to maximization of life cycle profits.

Adding social media to your new product development efforts

If you intend to employ more social media in your new product development (NPD) efforts, it may be helpful to begin by re-evaluating how presentations are delivered within your organization.

At the Web 2.0 Expo in November 2009, the keynote presentations were enhanced using a live Twitter feed generated using a publicized hashtag (#w2e) and multiple WiFi access points for the audience. 

  

I suspect that some of the Presenters were more comfortable with the established paradigm of delivering a monolog with a prepared set of images in a darkened room. 

The addition of a live Twitter feed provided a public sampling of the realtime conversation within the audience.

What was revealed in the conversations?

Some tweets contained simple status information such as "The presentation is starting now." Commonly, audience members posted quotes from the presenter. Other tweets contained supplemental information such as 'The link for more information is ...' Occasionally, the tweets were fact checks. A few tweets contained a surprising insight or humorous anecdote.

Capacity problems

Because so many people were attempting to use the WiFi, the system was overloaded. Joel Spolsky has an excellent post on "The WiFi at Conferences Problem." Additional suggestions are in the "Why is Interet access and Wi-Fi always so terrible at large conferences" discussion.

Benefits of having social media during a presentation 

The addition of hundreds of tweets during presentations provided:

• Richer experience for the audience. Potential for more excitement and greater engagement.
• Realtime evaluation. When the presenter was motivational, the content of the tweets reflected it. When there was too much superficial content, dissatisfaction was registered in the tweets. The absence of feedback signaled that the audience was distracted and likely to be using the WiFi connection for other activities.
• Disintermediated information. Instead of a dashboard summary, the raw text is available.
• Traceable sources. Tweets are not anonymous. Authorship is revealed.
• Analytics. The tweets can be reviewed after the presentation to extract other information.
• A multi-perspective summary of the event.
• Feedback for the presenter. Opportunities for realtime adjustments. Insights for improving future presentations. 
• Feedback for the event planners that complements survey information and subjective assessments.

After experiencing the enhanced presentations last month, it will be difficult to accept another dull PowerPoint monolog in a darkened room.

Don't feed the trolls (DNFTT)

During the Web 2.0 expo, the feed generated from #w2e (the publicized Twitter hashtag) was moderated. There was a mechanism to remove inappropriate comments before they were displayed on the big screen. Trolls were thwarted.

Implications for new product development

There seems to be a growing urgency to add social media capabilities to new product development efforts. The budget for social media capabilities has been increased in many organizations. Now, 'Social Media Strategist' is a job title. This is reminiscent of the job title 'Web Master' from the 1990s.

It will take more than adding Web 2.0 capabilities to your site and devoting resources to your Twitter effort to maximize the effectiveness of your development efforts. It will require more than mastering the jargon.

Perhaps one way to gain experience using social media is to evolve the established presentation paradigms to empower new communities and improve open innovation.

This is possible because social media provides a great method for listening. Likewise, new product development benefits from listening as the product evolves from a concept to a commercially viable solution

Detrimental Connotations in New Product Development (10/10) - Collaboration

In the conclusion of the 10-part series on Detrimental Connotations in New Product Development - Collaboration, opportunities for collaboration are explored. Opportunities for collaboration include the following interactions:

• Between individual contributors
• Across functional groups
• Agents (something that acts within the system) whose contributions focus on different portions of the development effort
• Individuals and information

This post address improving NPD environments and especially those embracing Web 2.0, social computing, NPD 2.0, co-development, open innovation, or geographically dispersed (virtual) teams concepts. It explores the concepts of neural networks and complex adaptive systems in NPD environments.

It concludes with "When your connotation of collaboration enables you to create an NPD culture that facilitates synergistic interactions among individuals and across functional groups as well enabling better insights from information throughout development, your potential for innovation will improve."

Network the silos - An alternative to breaking down the silos

This post explores the phrase 'breaking down the silos' and presents alternative strategies that include the concepts of refactoring, networking, neural networks, and complex adaptive systems to improve the effectiveness of new product development (NPD).

Some individuals accept the admonition to 'break the silos' as 'good advice.' Other individuals have the expectation that the process of 'breaking down the silos' will be accompanied by an unpleasant disruption of current workflows and a dilution of effort.

The function of a silo

Outside of NPD, some silos are recognized as beneficial. Farmers use enclosed structures to store grain. The military uses them to shelter missiles. 

Are there beneficial silos in NPD? If so, silos that produce the intended results should be preserved, nurtured, and improved.

Common usage of the phrase 'breaking down the silos' in business environments

In the United States, the phrase 'breaking down the silos' has become synonymous with removing barriers in business environments. The typical intent of this generic prescription is to remove barriers within hierarchical organizations.

Within many new product development environments, the phrase 'breaking down the silos' has the connotation of removing barriers between functional groups to enhance cooperation. In such cases, the implication is that the removal of these barriers will improve the organization's performance.

Examples of detrimental conditions between functional groups include:

• Problems exchanging information
• Problems sharing and creating knowledge 
• Disagreements about priorities
• Slow responses due to internal bureaucracy

In this hierarchical organization diagram, the vertical segments of the organization chart resemble the physical silos in the preceding image from a farm. Formal communication between individuals from different groups may require the participation of their managers. Ideas may be collected and reviewed by a committee before some are implemented. 

In this diagram, four individuals are not designated as part of this NPD effort but are direct reports to managers that are assigned to the project. Two individuals do not report directly to a manager that is assigned to this project. Such inefficiencies may increase the administrative requirements without improving the NPD effectiveness.

Typically, context-sensitive solutions to remove barriers may include the adoption of:

• New processes
• New training programs
• New tools  

An example of a beneficial silo

Some barriers are beneficial.

One of the most effective silos I have encountered was an NPD group at Hewlett-Packard. This group developed many successful, profitable products. Group members had many opportunities to improve their skills.

The group leader was an R&D manager. He protected his group from interruptions and distractions. His desk was positioned at the entrance to the work area and he scrutinized every visitor to the area. He worked on many tasks that required interaction with Marketing so that his team could concentrate on their primary assignments. He protected flow. The Wikipedia entry for flow (psychology) includes: 

Flow is the mental state of operation in which the person is fully immersed in what he or she is doing by a feeling of energized focus, full involvement, and success in the process of the activity... According to Mihály Csíkszentmihályi, flow is completely focused motivation. It is a single-minded immersion and represents perhaps the ultimate in harnessing the emotions in the service of performing and learning.

Refactoring a silo

The phrase 'breaking down a silo' may have the connotation of indiscriminate destruction. The results of 'breaking down a silo' may have unintended consequences. Valuable qualities may be destroyed while removing detrimental barriers.

Instead of 'breaking down a silo,' consider the concept of refactoring. The Wikipedia entry for 'code refactoring' includes:

Code refactoring: the process of changing a computer program's internal structure without modifying its external functional behavior or existing functionality, in order to improve internal quality attributes of the software. Reasons include to improve code readability, to simplify code structure, to change code to adhere to a given programming paradigm, to improve maintainability, to improve performance, or to improve extensibility.

To improve the effectiveness an NPD team, consider ways to:

• Encourage effective interactions and minimize interruptions
• Maximize productivity and minimize rework
• Maximize knowledge creation
• Improve the level-of-mastery of team members

What refactoring techniques will be effective?

Network the silos

Before indiscriminately breaking down silos, analyze the beneficial aspects of each functional group. What are the potential detrimental consequences of breaking down these silos?

As an alternative to 'breaking down the silos,' consider ways to network the silos.

What are the benefits of networking silos instead of breaking them? Using a model similar to an Ethernet network suggests an improved way of exchanging information within a development team.

In this hierarchical organization with networked silos diagram, a portion of the information flows in and out of a central hub. Each silos has an equivalent connection to the hub. This model facilitates the introduction of new processes and tools within an NPD environment. 

This model support concepts such as idea and information management.

Neural Networks

The connections in a neural network differ from those of an network that uses a central hub. In a neural network model, an individual can have from one to many connections with other agents (something that acts within the system). The connections are made and broken dynamically. The 'bandwidth' of the connections between individuals can grow or shrink depending on the qualities of the tasks. 

This team that has connections that have formed like a neural network. Agents are proficient. Communication is efficient. Collaboration is facilitated.

Complex adaptive systems

A complex adaptive system is characterized by:

• Cooperative individual behavior
• Emergence of a community
• Adaptation to feedback
• Use of barriers and attractors

In this complex adaptive system for NPD that uses neural network concepts to facilitate interaction, innovation is facilitated.

An introduction to complex adaptive systems is included in my December 2008 Visions article. For more information on complex adaptive systems, examine the work of Dave Snowden at Cognitive-Edge.

Progressing from a coworker environment to cooperation and then to collaboration

An indiscriminate prescription to 'break down the silos' may not be the best strategy to improve results in a high performance NPD environment. The most effective NPD environments are more than a collection of coworkers juggling multiple assignments in a hierarchical organization. 

A more effective NPD environment facilitates cooperation where agents form a network to develop new products. 

The most effective NPD environments facilitate appropriate collaboration. The interaction of agents produce innovative solutions that are superior to the results of individuals working in isolation. These environments are synergistic. Such an environment is consistent with a complex adaptive system that uses neural network concepts.

To quote a line from Strawberry Fields Forever from the Beatles, the next time I hear a suggestion to improve NPD that includes breaking down the silos, "I think I disagree."