Product Launch

Good Ideas, Many Ideas, and Linus Pauling

According to PDMA's Glossary

Idea: The most embryonic form of a new product or service. It often consists of a high-level view of the envisioned solution needed to solve the problem identified by a person, team or firm.

In product development contexts, the word "idea" may refer to a "new product concept" and other information described in project documents.

A common belief in new product development (NPD) is "If you want to have good ideas you must have many ideas." An alternative version is "The best way to get a good idea is to get a lot of them." Often, these quotes are attributed to Linus Pauling."

To acquire many ideas, some organizations make significant investments in idea generation techniques and idea management systems. These may be associated with innovation management efforts.

Additional Context and Interpretation

When Pauling was asked how he developed ideas, a colleague recalled that Pauling said:

"If you want to have good ideas you must have many ideas. Most of them will be wrong, and what you have to learn is which ones to throw away."

The colleague interpreted Pauling's intension:

"Having the ideas is the easy part... The difficult part is to know which ones to hang on to and which ones to throw away."

The colleague was Francis Harry Compton Crick. He was the Crick of the team of Watson and Crick that is known for their work on the structure of DNA.

Crick's interpretation provides additional insight regarding "good ideas" for new product developers. Discernment can be a more important success factor than just generating many ideas.

High Quality Ideas

Instead of producing a greater quantity of ideas, Pauling produced ideas of greater quality.

By the time Pauling was asked "How do you get ideas?" he had become very proficient and had been recognized for his accomplishments. A Wikipedia article describes him as "an American chemist, biochemist, peace activist, author, and educator. He was one of the most influential chemists in history and ranks among the most important scientists of the 20th century." His accomplishments and awards include:

• Obtained PhDs in physical chemistry and mathematical physics in 1925
• Summarized his work in his book "The Nature of the Chemical Bond," an influential chemistry book. Published in 1939
• Awarded Nobel Prize in chemistry in 1954
• Awarded Nobel Peace Prize in 1962
• Linus Torvalds, the developer of the Linux kernel, was named after Pauling in 1969
• Called one of the founders of molecular biology by Crick in 1996

Pauling mastered the fundamentals of his discipline, contributed to the advancement of his discipline, and interacted with other proficient colleagues to synthesize good ideas. 

By interacting with proficient peers, Pauling maintained effective ways to discern good ideas from the ones that should be discarded.

Contrasting two approaches to value creation

The approach advocated by Pauling includes proficient individuals interacting with proficient colleagues to develop a few ideas and reject others.

Another approach solicits contributions from a more general population. This approach is likely to generate more low quality ideas. The potential value of each idea may be evaluated by a committee. The ideas may be evaluated using sophisticated analytics. A portfolio of ideas may be managed by another committee. This approach is consistent with many social media campaigns and bureaucratic efforts.

One of these approaches is much more satisfying than the other and is more likely to produce better results.

 

Contrasting Risks and Asymmetric Payoffs in New Product Development

Why do executives motivate individuals to take risks in new product development (NPD)? Taking risks is not the primary objective of NPD. The driver for taking risks is the expectation of asymmetric payoffs.

The expectation of the value that results from an asymmetric payoff is greater than that of taking random risks as if the outcomes of development were a game of chance.

Instead of taking random risks, some executives foster a company culture that promotes the formation of hypotheses and conducting experiments. A relatively small amount of time and resources are allocated for experimentation. There are expectations that a set of experiments will produce learning. There are expectations that a set of experiments will improve the capability of the team. There company culture accepts the concept of supporting multiple small initiatives and an associated number of failures for the expectation of an asymmetric payoff. 

Asymmetric Payoffs

An asymmetric payoff occurs when the profits from one of these experiments covers more than the combined costs of all the 'failed' experiments. There is an asymmetric payoff when one of the small bets provides a large win.

There is an asymmetric payoff when the value produced from one success exceeds the costs to fund all the failures. This is an adaptation of what Don Reinertsen wrote in Principles of Product Development Flow on Page 90.

How Leaders Manage a Portfolio of Risks

To manage a portfolio of risks, leaders estimate market opportunities and evaluate factors such as execution risks. In part, leaders make assessments based on the presentations of persuasive individual contributors.  Decisions are influenced by:

• The way leaders prepare for critical portfolio discussions
• The way individual contributors prepare for critical portfolio discussions
• Other cognitive biases  

Preparations

Preparation goes beyond the apparent 'qualifications' of those involved. It includes factors such as due diligence and deliberative practice. All new projects have unknowns. The more disruptive the idea, the greater the potential that success will be impeded. Can the individuals, the team, the company produce value by committing to a new project before a competitor capitalizes on the opportunity?

The following examples describe individuals that prepared so that they consistently produced the value that results from asymmetric payoffs. 

• Sun Tzu described his approach in "The Art of War." 
• Miyamoto Mushashi wrote about it in “The Book of Five Rings.” As a swordsman, he was undefeated. 
• John Boyd was dubbed "Forty Second Boyd" for his standing offer as instructor that beginning from a position of disadvantage, he could defeat any opposing pilot in simulated air-to-air combat in less than forty seconds. He was never defeated.

What is better than taking audacious risks? Being certain to win.

Additional Information

For more information on John Boyd, I recommend "Certain to Win" by Chet Richards, @FuentesDeOnoro. For more information on asymmetric payoff functions, I recommend "The Principles of Product Development Flow: Second Generation Lean Product Development" by Donald G Reinertsen, @DReinertsen. The book Little Bets by Peter Sims explores the emergence of breakthrough ideas from discoveries.

When to finalize product requirements

To evaluate when most of the product requirements are determined in a specific new product development (NPD) context, invest the time to discern characteristics of the product domain.

Simple Domain

In Dave Snowden's Cynefin framework, when the domain is characterized as "simple," it is reasonable to enlist proficient individuals to specify most of the requirements in the early stages of a project.

In the 'simple' domain:

• There is a direct, easy-to-understand relationship between cause and effect
• The concept of best practices is likely to be adopted

Complicated Domain

If the Cynefin domain is characterized as "complicated," more specialists and more analyses are required. 

In the 'complicated' domain:

• Analyses are required to determine the relationship between cause and effect
• Typically, there are several good practices that are likely to produce acceptable results

 

Complex Domain

If the Cynefin domain is characterized as "complex," properties will emerge as the project progresses. Over time, the system will impact the contributors. The contributors will impact the system.

In the complex domain, contributors strive to learn as the project progresses. This requires hypotheses and experimentation. Unknowns emerge. Requirements evolve. The Lean Startup methodology embraces this evolution with build-measure-learn cycles.

The system is likely to be a complex adaptive system.

Determining what to do about requirements

The question of "Which is better?" is not the most insightful requirements inquiry. The wise product development practitioner discerns the domain and proceeds with the correct approach for the context. This assessment will provide guidance regarding the capabilities of the contributors that will be required for a successful engagement.

After one has insights about the domain and the capabilities of the contributors, another issue can be addressed.

Beyond the Iron Triangle

In many new product development environments, there is a common belief that trade-offs of product functionality, quality, and price are inevitable. This model is known as the Iron Triangle, Triple Constraint, or Project Management Triangle.

The wise product development practitioner consistently attains the appropriate levels of functionality, quality, and price because they enlist individual contributors to the project with better capabilities for the context of the project. They do not need to compromise on requirements in a 'painful' or 'desperate' manner because an informed, shared orientation enables them to consistently make appropriate design and development decisions and implement their plans efficiently and effectively.

In the 1982 book Software Engineering Economics, Barry Boehn stated that the most important factor regarding productivity was team capability. Characteristics of the domain determine specifics of the team capability. When the project domain is simple or complicated, there can be more reliance on explicit procedures and processes. When the project domain is complex, additional capabilities are needed.

Day-to-day development activities

Some product requirements evolve throughout the project. There are more changes later in projects when the domain is complex. The probability of success for any new product development network (team) improves as their adaptability increases.

According to John Boyd in Patterns of Conflict (#125, 1986),

Adaptability: Power to adjust or change in order to cope with new or unforeseen circumstances

Regardless of the primary domain characterization of a project, typical day-to-day activities will present tasks that can be characterized as simple, complicated, complex, chaotic, or disordered domains. Individual efforts and group efforts should be able to adapt appropriately to maintain a cohesive development effort.

A sufficiently adaptable new product development network can deliver great products and user experiences that meet requirements. In addition, these projects are likely to be completed on-time and on-budget.

Chaotic Domain

There is alway some chaos in every new product development effort. In the Cynefin framework, this domain is charaterized by the lack of a relationship between cause and effect.

To be productive during times of chaos during development, individuals may consider engaging in other activities such as organizing their workspace or taking a professional development class.

Decisions about product requirements should be delayed until more is learned about the domain. Consider crafting additional experiments. Often, this may be an appropriate time to enlist help from other individuals who can provide new insights.

Disorder

If everyone contributing to the project does not know how to characterize the domain, the domain is Cynefin's fifth domain, disorder. In this domain, there will be confusion about when to determine the product requirements.

Additional information

Other posts will provide insights on how individuals and group can improve their capability and adaptability. For additional information, visit the OpLaunch website.

How to decide which features to build for a high profile demo

For a high profile demo, the features that should be the highest priorities are the items that provide the most value to the people that are in the audience. 

This post was inspired by a post at The Startup Toolkit titled "Deciding which feature to build for a big demo" by Robert Fitzpatrick, @RobFitz.

Prioritization using boardroom logic

One way to prioritize a list is to sit in a conference room that has a white board and ask for opinions. List the opinions on sticky notes. Spend hours re-arranging the sticky notes. The problem is that the results will be based on unvalidated opinions (also known as guesses, forecasts, knowledge gleaned from old research reports about potential preferences in the future,... ). It is likely that the loudest voice will have too much influence. The HiPPO (the highest paid person's opinion) will have extra influence.

Prioritization informed by dialogs with customers

A better way to prioritize a list is to interview the potential customers and review the notes from the interviews. To prioritize a list, the team has to 'get out of the building' and learn and confirm what provides the most value.

Not all of the functionality has to be in the demo. Not all the 'important' behavior has to be faked. The more important factors are understanding what the customers value and acknowledging that your team is working to provide this value.

Under such a framework, the team will not have to apologize for features that are not implemented. Customers will be more impressed when your team recognizes that a feature is critical to providing value for them. The customer will be more impressed that your team is continuing the dialog than a slick demo that doesn't match their value requirements.

Demos and new product development

To glean the most value from a demo, it should not be limited to a monolog. Strive for dialog. 

A demo provides a unique opportunity for conversation and an environment for learning. The resulting insights can be used to decide how to prioritize the development of features for every new product development (NPD) project.

For more information

For more information on ‘get out of the building’ see Steve Blank, @sgBlank. For more information on interviewing customers see Kristin Zhivago, @KristinZhivago.

Innovation is not a Forecast

This post was inspired by a Paul Sloane post titled "The Innovation Disconnect." Sloane notes that many leaders commit to "innovation" and collect ideas. He cites the lack of implementation. His post contains several suggestions.

I prefer a different approach.

Innovation is a Result

Innovation is a result. When the discussion is framed this way, the organization can shape their efforts in better ways.

I agree that "The innovation disconnect occurs when corporate statements and employee experiences are inconsistent." Some of the disconnect is perpetuated because of ambiguity in the presumed meaning of the word "innovation."

Components of innovation include "new" and "valuable.

More than Ideas

Too many organizations don't progress beyond collecting ideas and congratulating those those that present 'good' ideas. In such organizations, the system is gamed easily.

Innovation is not a Forecast

Innovation is not a forecast. It requires implementation and assessment. 

An idea is valuable just because it received the approval of the leadership team.

A project isn't valuable just because it was implemented. Assessments regarding on-budget and on-time compliance can be meaningless, vanity metrics.

An abundant number of customers is a better way to assess value. Ideas that are not implemented are not likely to produce abundant value.

Risks and Objectives

Leaders can convey that "innovation and risk-taking are desirable and rewarded" but more context should be conveyed.

When pursuing innovation, risk is not the objective. Fast failure is not the objective. Learning is recommended. Faster learning is desirable. Abundant value is the objective.

Therefore, hypotheses (ideas) should be tested with well-crafted experiments. It requires that prototypes be built and tested. Results are analyzed with regard to the desired outcome. This requires the efforts of proficient individual contributors that have the appropriate training and have performed the due diligence.

Risk-taking may be OK but, better yet, is an organization that runs well-crafted experiments that contribute to the creation of value. The experiments contribute to a cohesive effort that results in innovation.

The Disconnect

To reduce the "Innovation Disconnect," leaders can start by evolving the discussions regarding the components of innovation.

Agility is a quality and a relative assessment

I prefer to frame "agility" as a quality. It is a relative assessment. It is not a binary assessment - not a 1 or or 0.

Use of the word "more" in the phrase "while there is value in the items on the right, we value the items on the left more" from the Agile Manifesto supports a relative assessment approach. 

Agility is associated with the power of moving quickly and easily. It is associated with the ability to think and draw conclusions quickly. Often, improved agility correlates with improved reaction time. Synonyms include nimbleness and quickness. The German word “behedig” is translated as clever, dexterous, and skillful. Behedigkeit is translated as agility.

Often, agility is a quality that enables someone to accomplish the desirable. Typically, through training and deliberative practice, one's agility can be improved.

I prefer discussions that reinforce the concept of agility as a quality and a relative assessment. When agile is associated with qualities such as clever, dexterous, and skillful, it is a quality that is desirable for nearly everyone.

Agile is a Set of Values

Stated another way, agile is a set of values, not a process. There is not a definitive, single Agile method. A mix of Agile methods are used to support agile values.

The phrase "Agile requires" is not in the Agile Manifesto.

Better Results

Today, I noticed that someone posted "Once a team installs agile..." This paradigm is different than mine. 

Although some may insist that they can install agile, I have found that better results are obtained when agility is developed by investing in individual contributors.

According to Boyd in later versions of Patterns of Conflict, the ingredients for vitality and growth include insight, orientation, harmony, agility, and initiative.

One can evolve and exploit agility as a basis to win. 

Reframing the concepts of product delay and customer requirements in NPD

The concepts of "product delay" and "customer requirements" in new product development (NPD) can be reframed beyond the typical perspective of some practitioners.

This post was inspired by a December 2012 question in the NPD In-the-Know Linked in group. The question was "A leading cause of product delay is the late discovery of customer requirements. Shouldn't this be done in detail prior to development?"

One of the reasons for new product development is to attain future successes (reflected in metrics related to financial return on investment, market share,... or to increase knowledge, solve a customer's problem, ...). When I reflected on this, my perspectives of two terms, "Requirements" and "Delays," evolved.

Requirements

All of the requirements can not be discovered at the beginning of a development effort. There are uncertainties associated with the scope of the project.

Most products have very few requirements. For example, an electronic product must conform to regulations (such as electromagnetic compatibility and safety) in specific geographies at the time of product introduction. Even these regulations may evolve. There may be other contractual requirements.

Other development parameters are unvalidated opinions (guesses, forecasts, preferences,...) about what features and price points will be embraced in an uncertain future. Often, these unvalidated opinions provide faux confidence. Success is determined by the interaction of these parameters with an evolving, future system that includes competition, new technology, and emergent trends. 

Successful products integrate combinations of many choices with a few requirements to provide a solution to a customer's problem.

Delays

Schedules and associated delays are artifacts of the development effort. Typically, they can be gamed within a context that includes negotiations and biases in forecasts. Compliance with a bureaucratic schedule or budget will not guarantee development success. 

Forecasts about the viability of future product development efforts are always subject to errors because of problems that include the lack of awareness.

Phillip G Armour described Five orders of Ignorance. These include:

• 1st Order Ignorance — Lack of Knowledge.

            You know what you don't know, you have the question.

• 2nd Order Ignorance — Lack of Awareness.

            You don't know what you don't know. Unknown unknowns (unk unks)

Schedules and requirements are based on guesses about the future. They can be helpful to facilitate cooperation within a development environment but they are only artifacts of the development effort.

Causes of Delay

This post began by summarizing a question from a LinkedIn NPD group. The structure of the question implied that the "discovery of customer requirements" should be "done in detail prior to development." This suggests that some practitioners recommend that NPD efforts should follow a sequence of steps with pre-defined handoffs.

There are many alternative to this serial approach.

What is the mismatch between your current development progress and success? Which delays can be reduced? Which delays are unnecessary or unwanted?

In Software Engineering Economics, Barry Boehn stated that the most important factor regarding productivity was team capability.

Another approach to improve team performance is described in my Deliberate Practice - Pursuing Perfect Product Launch article. The article includes a comparison of explicit coordination and implicit coordination through team situation models.

Development approaches

It is rather easy to develop a product that meets some set of requirements and is delivered on-time. Some managers are rewarded for meeting the milestones associated with these projects. Often, metrics and milestones are proxies for success.

It is much more difficult to develop a fantastic product that provides the appropriate solution at the appropriate time that is embraced by an abundant number of customers and provides abundant profits (or some other desirable metric) to those that made the investments.

When a development effort conforms to what Cynefin refers to as a "Simple" or "Complicated" domain, one may achieve success while embracing beliefs about discovering all requirements and avoiding delays. 

In most development contexts, the Cynefin domain is "Complex," and other development approaches are more likely to produce development success.

Maximizing the potential for success involves more than contrasting waterfall [or BDUF (big design up front)] approaches and agile approaches. It requires a focus on improving the skills of individual contributors and the quality of their interactions within new product development networks. It includes efforts to improve individual and network capabilities such as:

• Agility
• Adaptability: Power to adjust or change in order to cope with new or unforeseen circumstances
• Cooperation
• Cohesion
• Collaboration
• Harmony: Interaction of apparently disconnected events or entities in a connected way

Definitions for adaptability and harmony were extracted from Boyd, Patterns of Conflict, 1986

When the fitness of the development network improves, this facilitates the discovery of better solutions in shorter amounts of time. This inspires individuals to enthusiastically take action as informed contributors to achive the desired goal — the development and delivery of a fantastic new product.

How to make better release or defer decisions

This post was inspired by the following advice from a software test professional:

"Don't let managers tell you when the software will be ready—you tell them when it is ready. Don't say it's ready when it isn't—offer options instead of unreachable deadlines"

This advice may be inspirational for some but it may limit the solution space.

A Framing Error

Although it is convenient to refer to "the software," this phrase contributes to a framing error. It is unlikely that someone in the compartmentalized role of a software tester will have sufficient insights to know when the application is ready. Just because all the documented software release procedures have been completed (test driven development approach, software checked in, automated test suite completed,...) doesn't confirm that the application is ready.

In the past at Apple, the evaluation of 'ready' would have been confirmed by Steve Jobs. He evaluated the elegance of the design and the quality of the user experience.

Recall that before iOS 3, there was no cut-and-paste functionality on an iPhone. When the development team's solution met Steve's standards, cut and paste was released in 2009.

Steve's user experience expectations permeated new product development at Apple. His holistic vision exceeded the contributions of one functional group such as 'Software' or 'Test.'

At too many companies, determining when an application or product is ready becomes a negotiation involving business interests, sales and marketing interests, engineering interests, and compliance interests. When the company culture support compartmentalized contributions (when functional groups act as independent silos), it is unlikely that the better decision will be made. The arguments tend to be myopic. Usually, the loudest, most persuasive voice (frequently the HiPPO) prevails.

Something better than options

Too often, many hours of the project are consumed discussing options and revising deadliness. Too often, opinions are unvalidated inputs. Too often, unvalidated opinions become requirements.

A better approaches employs multiple hypotheses and well-crafted experiments. This places the focus on validated learning. This approach celebrates proof points, not milestones. 

This is an agile approach that embraces set-based design and testing beyond the board room and team room. Validated learning requires the evaluation of results from testing with target customers.

Holistic Decisions

To make better decisions, the product development efforts should be holistic. The user experience criteria should be elevated. It would be nice to have a user experience champion like Steve Jobs to comment on what will be released and what will be deferred. Perhaps, we can all try to be a bit more like Steve in this regard.

How do you successfully launch a product?

The following post was inspired by a question on Quora. The primary question was "How do you successfully launch a product?" In addition, "What factors will help you take your product to the broadest audience?"

Whenever I hear the phrase "launch a product," I calibrate my orientation by examining the perspective of the individual involved. 

ROLE = TYPICAL MARKETER

If the role of the individual is a typical marketer or a communications specialist or a social media advocate, then expect an explicit list. The list provided by Balaji Viswanathan is consistent with this perspective. Such lists have the appearance of a 'best practice' and are easy to edit. Such lists are process-centric. Responsibilities can be delegated according to roles with a consideration of headcount in an organization. 

Too often, I have noticed that the list is held in higher regard then the individuals contributing to the effort. Too often, the individual contributors are considered plug-and-play resources that have a minimal ability to shape new product development. Too often, the individual contributors are expected to follow an explicit process and do what is expected.

It is my experience that such an approach contributes the failure rate of new product development efforts. Such an approach tends to produce mediocrity. Such an approach tends to lack the agility to adapt to emergent conditions. 

ROLE = TYPICAL ENGINEER

If the role of the individual is a typical engineer or programmer, they may hope that some other specialist provides a list of requirements and project constraints. Under such conditions, they can do what they do well - solve problems. 

Typically, this is a sub-optimized approach. There is always a question about requirements. Have they been validated? Will they be valid in 6-12 months when the project is ready for launch? Should the requirements have been labeled 'hypotheses?' How significant were the framing errors associated with the requirements? What framing errors have cascaded through the project constraints to become milestones?

When an intelligent engineer or programmer lacks a holistic involvement with the project, it is likely that they will not provide the most value to the project and contribute in the ways that are most likely to result in success. 

ROLE = TYPICAL MANAGER

Some identify their primary role as managers. They may augment their title with words such as 'section,' 'product,' or 'project' manager. The least passionate of these see their role as 'herding cats' and enforcers of the schedule. Often they work in the shadow of an iron triangle. Some adopt newer titles such as 'Product Owner' or 'Scrum Master.' 

Too many are managers and not leaders. Too many are enforcers and not enablers.

ROLE = TYPICAL FRAMEWORK DEVOTEE

Another common role is the evangelist for the latest framework or method. They advocate for new jargon and processes associated with their favorite celebrities. Examples include those that are exuberant about Agile, Scrum, Kanban, Lean, Lean Startup, or INSERT_YOUR_FAVORITE. 

Too often, such efforts are what Alistair Cockburn refers to as Shu-level. The understanding barely goes beyond a limited vocabulary. The commitments by the other individual contributors are modest. Adopting a new methodology or framework is likely to need more than 18 months to show significant impacts. 

ROLE = NEW PRODUCT DEVELOPER

When Clinton Keith described this for the context of game development, he wrote:

 “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.

This framing facilitates extraordinary cooperation and collaboration. The contributions can transition from following an explicit set of directives to embracing implicit cooperation and collaboration. In this context, implicit is used to convey a meaning of closely connected, joined, interwoven, and intertwined.

This context enables individual contributors to thrive in a complex adaptive system. Such systems co-evolve with the environment, have interacting agents, and emergent properties. The system impacts the agents. The agents impact the system. They have the potential to be self-organizing. There is not a single point of control.

In a complex adaptive system, the system and the agents co-evolve. We manage the present and evolve to an uncertain future. In these systems, we manage the boundaries and the probes. In such systems, you can do better with less. In these types of systems, we strive to manage the network relationships. 

Weak signal detection is very important in complex adaptive systems. They are not causal. They may be pre-disposed but one will not get 100% predictive capacity.

Complex Adaptive Systems are nonlinear. A small change can have a huge outcome.

In this role, an individual contributor does not identify themselves with a 'front end of innovation' specialist, R&D engineer, or marketing communications generalist with special social media capabilities.

 

LAUNCH FROM ANOTHER PERSPECTIVE

I prefer to view launch in terms of validation. 

• How did my efforts contribute to the value assigned by the customer?
• How much of my efforts were directed by unvalidated inputs?
• Am I better equipped for the next project?
• How much clean-up (re-work) will be necessary after the product is used by a large number of customers?

SATISFACTION

I expect a few baseline items during any project. I expect to receive fair compensation for my work. I expect to be treated respectfully.

Satisfaction requires more than that. 

The Principle of Obliquity applies. Some objectives (such as a successful product launch) are best pursued indirectly. 

Barry Boehm stated that the most important factor regarding productivity was personal/team capability. (From the cover of his book, Software Engineering Economics)

 Several suggestions that will position your efforts for a more successful launch:

• Populate your development environment with individual contributors that are pre-disposed to embracing their role as a new product developer who specializes in X.
• Emphasize a holistic approach. Minimize the perpetuation of independent silos of expertise that are disconnected from contact with potential customers.
• Encourage autonomy, mastery, and purpose for individual contributors (for more information, see Dan Pink's book - Drive)  
• Refine Schwerpunkt - a concept that provides focus, direction, an actionable guidance to the operation
• Design the environment to maximize the potential for the insights of individual contributors to impact the vision of the development effort
• Design your development effort as a network where individuals can enter and leave the effort as needed while ensuring the effectiveness of their contribution.  Minimize the command-and-control mentality that pretends that all the contributors are listed on your internal organization chart and subject to annual performance reviews.
• Embrace Alistair Cockburn's concept of development as a 'cooperative game.' 

 

SUMMARY

At the end of a project, I want to do more than confirm that I followed someone’s explicit list and met each milestone.

To maximize the potential for a successful launch, strive to ensure that the development environment is awesome for the network of individuals that have an implicit sense of how their contributions impact the effort. When the project is coming to completion, individual contributors should feel that their time was well spent, they advanced their skills, they made some valuable acquaintances, and that they are better prepared for success on the next project. A successful product launch is best pursued indirectly.

Silver Bullet Examples in New Product Development

Is there an exception to the claim that "There is no silver bullet to New Product Development?"

This post was inspired by a 12 November 2012 Strategy 2 Market post. The post asserts:

"The truth is that there is no single solution. Instead, a well-run new product development organization is a complex and demanding endeavor."

The author did not specify a definition for "silver bullet" or a quantitative assessment. Perhaps the author's intended definition is similar to:

Silver Bullet: Something that instantly solves a long-standing problem.

Frederick P. Brooks, the author of the book "The Mythical Man-month" specified that the "no silver bullet" phrase asserted that "no single software engineering development will produce an order-of-magnitude improvement in programming productivity within ten years."

Kelly Johnson and Skunk Works®

One famous exception was Kelly Johnson and the Skunk Works at Lockheed Martin. According to Wikipedia, they designed and built the XP-80 Shooting Star jet fighter in only 143 days, seven less than was required. Success factors included the unique abilities of Kelly Johnson plus the collaboration of a proficient group of individuals with a high degree of autonomy with Schwerpunkt - a concept that provided focus, direction, an actionable guidance to the operation.

Bantum and the Jeep

Another exception occurred in 1940. The US Army needed a four-wheel drive reconnaissance car. The original request was to supply a working prototype within 49 days. The American Bantum Car Company of Butler Pennsylvania accepted the challenge and produced a hand-built prototype and drove it to the test. The project success factors included collaborating with the talented designer, Karl Probst, leveraging existing components, and incorporating custom parts from Spicer, an agile partner. Their reconnaissance car is now known as the Jeep.

Complex Adaptive Systems

Beyond factors such as hard work, determination, and luck, I have found it helpful to explore more about the "system" described in the "There is no silver bullet to NPD" post.

Typically, much of an NPD environment can be characterized as a complex adaptive system. These systems co-evolve with the environment, have interacting agents, and emergent properties. The system impacts the agents. The agents impact the system. They have the potential to be self-organizing. There is not a single point of control.

In a complex adaptive system, the system and the agents co-evolve. We manage the present and evolve to an uncertain future. In these systems, we manage the boundaries and the probes. In such systems, you can do better with less. In this system, we strive to manage the network relationships.

Weak signal detection is very important in complex adaptive systems. They are not causal. They may be pre-disposed but one will not get 100% predictive capacity.

Complex Adaptive Systems are nonlinear - a small change can have a huge outcome.

New Product Development Networks

Instead of the concept of a "new product development team," I prefer to use a network paradigm to emphasize that individual contributors enter and leave the effort. They have multiple roles.

A development network is a complex adaptive system that changes its structure based on external or internal information that flows through the network during the learning phase

Leveraging Nonlinearities

In such NPD systems, you can do better with less. The specifics vary with every context. When you can identify the factor that will have a huge impact, this provies the insight for how to use a silver bullet.

Directions for using Silver Bullets

To produce the intended results, one must do more than possess silver bullets. Success requires more than reading about silver bullets.

Silver bullets should come with directions. In a simplified format, the direction are:

1. Ready
2. Aim
3. Fire
4. Repeat and refine

In an NPD context, the "Ready" step includes the appropriate leadership and talent. It requires the effective communication of mission intent. 

The "Aim" step requires wisdom. A silver bullet analogy requires that one eliminate the factors that inhibit success. The use of a silver bullet implies that problems are eliminated without destroying success factors. One must have the wisdom to aim at the appropriate items.

Once the ready and aim pre-requisites have been achieved, one fires. In an NPD context, this is execution. To achieve success, a silver bullet plan must be implemented. 

Success requires repetition and refinement. A new product development environment is a complex adaptive system. The system evolves. Previously identified threats and emerging threats must be eliminated for continued success.

Effective use of Silver Bullets

A silver bullet is not intended to be used as a talisman or an amulet. Silver bullets do not bring good fortune to those in proximity. A silver bullet is not a passive remedy.

The best results are obtained when silver bullets are used by skilled, vigilant practitioners. The skunkworks needed Kelly Johnson. The effort at Batum would not have been successful without Karl Probst. To ensure success, they accentuated the positive factors and eliminated the negative factors.