The truth about “any color so long as it is black”

Posted on April 30, 2015 by OpLaunch

Henry Ford (1863-1947) documented that he made the “any color so long as it is black” comment during a meeting in 1909 (Henry Ford in collaboration with Samuel Crowther in My Life and Work. 1922. Page 72).

My Life and Work by Henry Ford in collaboration with Samuel Crowther. 1922.

Henry Ford had a different perspective than the salesmen attending the meeting.

“This season demonstrated conclusively to me that it was time to put the new policy in force. The salesmen, before I had announced the policy, were spurred by the great sales to think that even greater sales might be had if only we had more models. It is strange how, just as soon as an article becomes successful, somebody starts to think that it would be more successful if only it were different. There is a tendency to keep monkeying with styles and to spoil a good thing by changing it. The salesmen were insistent on increasing the line. They listened to the 5 percent, the special customers who could say what they wanted, and forgot all about the 95 percent, who just bought without making any fuss. No business can improve unless it pays the closest possible attention to complaints and suggestions. If there is any defect in service then that must be instantly and rigorously investigated, but when the suggestion is only as to style, one has to make sure whether it is not merely a personal whim that is being voiced. Salesmen always want to cater to whims instead of acquiring sufficient knowledge of their product to be able to explain to the customer with the whim that what they have will satisfy his every requirement – that is, of course, provided what they have does satisfy these requirements.” (Ford. Page 71)

The first Model T left the factory in September of 1908. In the 1909 fiscal year, 10,660 units were produced. Ford considered that their offering was good enough. The Model T had product-market fit.

In the language common to product development, the Model T was a platform product. Over the next 18 years, there were numerous body styles that included 2-door and 4-door touring, roadsters, town cars, pickups, and sedans.

Platform Product: The design and components that are shared by a set of products in a product family. From this platform, numerous derivative products can be designed. [Definition from the PDMA glossary]

Henry Ford provided his vision for the Model T:

“I will build a motor car for the great multitude. It will be large enough for the family but small enough for the individual to run and care for. It will be constructed of the best materials, by the best men to be hired, after the simplest designs that modern engineering can devise. But it will be so low in price that no man making a good salary will be unable to own one – and enjoy with his family the blessing of hours of pleasure in God’s great open spaces.” (Ford. Page 73)

The Model T was designed by Henry Ford, Childe Harolde Wills, József Galamb, and Eugene Farkas.

In 1909, Henry Ford had a vision to scale production. He believed the the Model T platform was the best strategy to produce an affordable car for the world.

“Therefore in 1909 I announced one morning, without any previous warning, that in the future we were going to build only one model, that the model was going to “Model T,” and that the chassis would be exactly the same for all cars, and I remarked:

‘Any customer can have a car painted any colour that he wants so long as it is black.’

I cannot say that any one agreed with me. The selling people could not of course see the advantages that a single model would bring about in production. More than that, they did not particularly care.” (Ford. Page 72)

Fortunately, there is production data for 18 years. Production went from thousands per year in 1909 to millions per year.

Ford Model T production numbers derived from http://www.mtfca.com/encyclo/fdprod.htm
Worldwide production except for Canada.
Model T production ended 25 May 1927. 15 million were produced.
The 1920.5 data discontinuity reflects the transition from a fiscal year to a calendar year.
The Model A was launched at the end of the 1927.

Development Experience

Because the Model T chassis that did not change much in 18 years, the designers could devote more effort to the passenger related parameters.

Henry Ford’s resolve set the focus and direction of the project. He was not detracted by the reports from the salesmen. He monitored development to minimize unvalidated additions to the product backlog which is also known as product feature creep.

Feature Creep: The tendency for designers or engineers to add more capability, functions and features to a product as development proceeds than were originally intended. These additions frequently cause schedule slip, development cost increases, and product cost increases. [Definition from the PDMA glossary]

Any Color So Long As It Is Black

Ford’s first prototypes and production models were designated by the letters A to T. They came in many colors. For example:

The original Model A 1903-1904 was sold ‘only in red by the factory.’
The Model F was ‘rich dark green, yellow running gear’
The Model K was ‘Royal Blue’
The Model R was red
15 million Model Ts were produced by 1927. This car is green with black trim (fenders and running boards).

The Fifteen Millionth Ford Model T. Henry Ford is the passenger in the front seat.

In late 1927, Henry Ford had the replacement for the Model T. The new Model A was produced from 1927-1931. Nearly 5 million were produced.

Success

Henry Ford’s resolve was consistent with the comment he made in 1909. Henry Ford was able to scale production to produce over 2 million cars per year by:

Minimizing changes to the Model T platform. Many components of the chassis were the same for every body style.
Reducing the number of factory hours required to produce each car. This included minimizing the number of body colors.
Setting aggressive target prices then finding ways to achieve those prices
Producing cars with standard parts in factories all over the world

Henry Ford disrupted the way people moved from one place to another by designing and manufacturing an affordable car to anyone making a decent salary. One of the color choices was black.

More than a shared understanding is required

Posted on March 1, 2015 by OpLaunch

To be very successful in new product development, more than a shared understanding is required.

A Common Perspective on Shared Understanding

In some cases, a shared understanding is facilitated during ideation (brain storming) sessions with a diverse group of individuals guided by a facilitator. The progress toward agreement may be managed by creating and arranging sticky notes and voting. In some cases, ‘shared understanding’ implies consensus. In some cases, certain opinions are promoted by the most dominant personality in the room or the Highest Paid Person’s Opinion (HiPPO).

This type of shared understanding facilitates progress in a Big Design Up Front (BDUF) context. A shared understanding promotes a feeling of confidence when requirements are written.

Note: For this post, I am not addressing the benefits of project artifacts such as style sheets, templates, and processes. These tend to promote consistency. They do not drive shared understanding.

Shared Understanding and User Stories

Recently, I have noted that the meme of ‘shared understanding’ is being associated with the requirements for user stories. The assumption seemed to be that ‘when there is a shared understanding within the development team, requirements can inform the writing of user stories.’

Challenging Shared Understanding

A shared understanding is problematic when it is incorrect or insufficient. Memes that are incorrect or insufficient are insidious.

Better Understanding

Instead of a shared understanding that may be insidious, strive to develop a network-informed, self-correcting understanding. Strive to improve the capability to detect mismatches.

Mismatch: the difference between the phenomena that is observed and the conceptual description of that situation.

A better understanding improves through cycles of synthesis, testing, and observing interactions between proposed solutions and stakeholders (such as customers, sales representatives,…). Development networks that can deliver and test prototypes are positioned to appreciate the trends that emerge and adapt to provide better solutions more efficiently.

A development network can achieve a shared understanding or, better yet, they can improve their capability for a better understanding. Shared understanding can be achieved in the isolation of a conference room. The capability for better understanding can be accelerated through interaction between stakeholders (including potential customers) and prototypes. Instead of prematurely accepting requirements, hypotheses can be validated.

Impact on Development Experience

When a development network has ample potential to improve capabilities that they value, individuals (such as designers, engineers, subject matter experts, …) are more likely to be motivated. The development environment facilitates the improvement of factors such as autonomy, mastery, and purpose. Such environments promote a culture where the quality of the Development Experience [DX] enables multiple successes.

A better perspective on competition during new product development

Posted on January 5, 2015 by OpLaunch

Miyamoto Musashi (1584-1645) was a swordsman, a masterless samurai, and an independent teacher. He won his first duel at age 13. By the time he was 29, he had dueled more than 60 times. He never lost.

Subscribe on iTunes. Duration: 6 minutes. File Size: 3.5 MBytes

The Book of Five Rings by Minamoto Musashi

Rule 9 from “The Book of Five Rings” by Miyamoto Musashi is “Do not do anything useless.”

Musashi’s Rules

Musashi began to write “The Book of Five Rings” in 1643. In The Earth Scroll, he summarized his rules for “learning the art:

Think of what is right and true
Practice and cultivate the science
Become acquainted with the arts
Know the principles of the craft
Understand the harm and benefits of everything
Learn to see everything accurately
Become aware of what is not obvious
Be careful even in small matters
Do not do anything useless” [Page 22]

To expand #9, Musashi offered the following advice about combat:

“Whenever opponents try to attack you, let them go ahead and do anything that is useless, while preventing them from doing anything useful” [Musashi, The Book of Five Rings, The Fire Scroll, Page 54]

Opponents and Competition

In new product development contexts, it is more common to use the word competition than opponent.

In new product development, discussions about competition usually evoke thoughts of external struggles between organizations to complete projects and capture market share.

During new product development, competition also exists internally. Typically, internal competition discussions include topics such as negotiations about the schedule and project resources such as headcount and equipment budgets.

There are more subtle aspects of internal competition.

Internal Competition during New Product Development

During new product development, engaging skilled and experienced practitioners can address Musashi’s rules 1-4. Involving wise practitioners can address rules 5-8.

Rule 9 is more subtle. Familiar practices and past successes may make it difficult to detect what is useless.

Success in new product development depends on your ability to determine the relative usefulness or uselessness of all potential efforts.

For a simple exercise, consider your next scheduled meeting. A decision to have a meeting creates internal competition for attention. What might be done to improve the usefulness of the meeting? Will the agenda be available before the meeting? Is there a prominent objective? Are there new documents that must to be reviewed before the meeting? Will the completion of action items be verified? Will the duration of the meeting be less than one hour? Will meeting notes be created interactively during the meeting? Can remote contributors participate in the meeting? Can these needs be fulfilled more effectively by other means?

For a more complex exercise, consider how an individual contributor (a coder, engineer, scientist, communications specialist, subject matter expert,…) validates that their contributions provide value to the project. Besides completing a task (such as writing code to implement specific functionality), how will you determine if the effort was valuable? Was there a better use of the time? How will the effort be validated in terms of project success?

For a more substantial exercise, consider how an individual’s efforts contribute to improving their development experience factors such as autonomy, mastery, and purpose.

Developing a better perspective

Musashi’s advice was “Do not do anything useless.” This is a practical project objective and a desirable career strategy. Developing this perspective requires substantial effort and it produces significant rewards.

When efforts are not wasted on the useless, individuals can develop better perspectives to win as they evolve their focus and direction throughout projects.

End Notes

The “Helping Gnomes that Code” post included descriptions of Requisite Variety, Pair Development, Disintermediation, and Recursion approaches to improve development options. These also apply to minimizing the potential to do anything useless.

A Better Perspective on Competition during New Product Development [ 6:03 ] Play Now | Play in Popup | Download

Helping the Gnomes that Code

Posted on October 31, 2014 by OpLaunch

Some emphasize that product development begins with writing code and that effort transforms into a win. The lingering question for this type of three-part development model is “What is Phase 2?”

Some emphasize that product development begins with writing code and that effort transforms into a win. The lingering question for this type of three-part development model is “What is Phase 2?”

What is Valued by Gnomes that Code?

Many managers track business metrics and project metrics during Phase 2 to forecast the potential to win.

What is valued by gnomes that code?

Gnomes associate winning with factors that include autonomy, mastery, and purpose. Dan Pink wrote about what motivates individuals in his book Drive.

Gnomes can develop autonomy, mastery, and purpose in an environment when there is a moderate amount of volatility, randomness, disorder, and stressors. Gnomes can benefit in a development environment that is characterized by a moderate amount of adventure, risk, and uncertainty. Taleb called this type of environment antifragile.

Development Options

Taleb wrote ‘The option is an agent of antifragility.’ An agent obtains results.

An appropriately designed network continuously synthesizes development options that provide the potential to take action that may result in a favorable gain. When an attractive gain may be realized, options are exercised.

Development options:

Include tasks that are likely to improve the antifragility of the network during a project
Are a response to the question ‘what should the network embrace now to improve the potential to win in the future?’
Are continuously synthesized and exercised during a project within the development network to refine the focus and direction of efforts to generate a win
Are consistent with the concept of safe-to-fail experiments that have an asymmetric payoff function (large potential gain, small potential loss)
Are exercised, evolve, or expire

The capabilities of the network impact the attractiveness of the development options that are generated.

To the extent that options are exercised and provide feedback, confidence in their attractiveness tends to increase.

Multiple options can be active simultaneously to provide multiple opportunities to win within the network’s current capabilities and within the project’s current constraints.

Precursors to Development Options

Analysis is a precursor of synthesis. Analysis is a problem solving approach that divides the whole into its constituent parts. Synthesis is a process of connection.

A synthesis approach enables one to imagine how several capabilities may work together to produce the desired result. Validation may follow from a combination of decision, action, interaction, and more observations.

John Boyd represented these items in his OODA Loop sketch in his final briefing titled “The Essence of Winning and Losing” in 1995. I have expanded Boyd’s notation to represent the interactions of individuals and their efforts during a project.

John Boyd’s OODA Loop sketch notation can be expanded to represent the interactions of individuals and their efforts during a project. This illustration includes the representation of simultaneous efforts within a hierarchy and the pursuit of two options simultaneously.

The following notation represents synthesizing options and exercising options throughout a development project.

Synthesizing and exercising options during new product development

Synthesizing many options and exercising attractive development options should occur rapidly throughout a project. ‘Synthesize options’ includes imagining solutions and documenting them. The cloud filled sky background of the ‘exercise option’ portion of this graphic represents the interaction of prototypes with the environment (which includes customers).

Designing to Improve the Capability to Synthesize and Exercise Attractive Development Options

Optionality can be improved by design. Concepts that can be employed in a development environment to help gnomes that code improve their capability to synthesize and exercise attractive development options include:

Requisite variety
Pair Development
Disintermediation
Recursion

When the network has requisite variety, the network has to potential to recognize all problems and to activate appropriate responses.

Requisite variety addresses the importance of having proficient practitioners with a diversity of capabilities that can be mobilized in a dynamic network. The table indicates that this environment has requisite variety because the number and type of responses represented are greater than or equal to the number and type of problems represented.

Requisite variety is associated with mobilizing a network of contributors with diverse specialties and multiple perspectives. To be successful, individuals may require additional training, access to individuals with unique expertise, and new ways to cooperate.

During the project, individuals engage and disengage to maintain requisite variety and avoid the paralysis associated with excessive variety.

Pair Development facilitates the synthesis of options to develop a self-correcting focus and direction informed by the analyses of multiple perspectives.

Pair development is implemented by facilitating the interaction of individuals of different disciplines (such as a coder and a market specialist). Pair development may include activities such as dialog and sketching.

Pair development provides an opportunity for interaction through activities such as dialog and sketching to transform orientations. The result of pair development should be a synthesis of options, not a summary of previous activities.

Pair development provides benefits beyond distributed cognition. The purpose of pair development is not cross-training. The result of pair development should not be a summary of previous activities.

Disintermediation efforts may involve removing layers of management or removing other barriers. Disintermediation efforts may have objectives such as:

Improving agility
Rapid recognition of problems
Rapid implementation of solutions
Faster cycle times

Achieving these objectives may require the re-design of the network to facilitate communication, cooperation, collaboration, and harmony among individuals.

Achieving these objectives may require evolving the way that individuals experience the interactions of customers with prototypes (or other experiments related to the product being developed). Direct observations that promote full-fidelity interactions are preferable to mediation approaches such as presenting individuals with reports that summarize activities.

Recursion is a solution or technique in which large problems are solved by reducing them to smaller problems of the same form.

Recursion is a solution or technique in which large problems are solved by reducing them to smaller problems of the same form. A recursion approach works best in a development network with requisite variety that observes the interactions of multiple potential customers with evolving, functional, holistic prototypes.

The network’s perceptions of large problems shape the focus and direction (schwerpunkt) of the project. When developing a new product, the large problems include the customer’s experience with the product.

Large problems are evaluated by the interactions of people with products during activities such as buying, setup, use, maintenance, and troubleshooting. The large problems include the customer’s perceived value of the new product in comparison to alternatives. The large problems may be evaluated in terms of the delight produced using the product to accomplish a task.

Recursion approach to new product development

A recursion approach provides multiple channels of feedback to a development network with requisite variety that evaluates multiple opportunities to win. Customers interacting with prototypes is represented in the upper-right corner. Four snapshot of the development network are represented during the project.

A recursion approach provides multiple channels of feedback to evaluate multiple opportunities to win.

A recursion approach works best in a development network with requisite variety that observes the interactions of multiple potential customers with evolving, functional, holistic prototypes. The interactions provide multiple opportunities to detect mismatches and develop corrections.

Mismatches: the difference between the phenomena that is observed and the conceptual description of that situation

A recursion approach provides validation that is beyond the results available from surveys. Prototypes are evaluated beyond their functionality. A recursion approach includes evaluating how one user describes a solution to another user.

A recursion approach is used to validate the attractiveness of development options.

When practicing recursion approaches, individuals that tend to identify themselves as independent specialists shift to identifying themselves as contributors to development options. Their perspectives change. They engage in efforts to solve the large problems.

Transitioning from Coding to Winning

Gnomes know how to write code.

To transition from writing code to winning, gnomes benefit from concepts such as requisite variety, pair development, disintermediation, and recursion contribute to improving the capability to synthesize and exercise development options rapidly in an antifragile development environment.

This enables gnomes that code to become winners that code.

The gnomes synthesize and exercise options.

During Phase 2, the capability to synthesize many options and exercise attractive development options rapidly enables a properly prepared network of individual contributors to realize non-linear gains that are not possible by alternate development approaches such as ones that focus on managing mandates. This enables gnomes that code to transition to winners that code.

Diversity in Expressing Wins

Ultimately, gnomes that code express their wins through actions that are consistent with motivating factors such as autonomy, mastery, and purpose. Gnomes that code may express their wins to their peers through recurring actions such as pushing files to their Git repository or answering questions on StackOverflow. These types of actions improve their development experience.

When the gnomes that code win, their success propagates. Customers express their wins by actions such as posting product reviews that described how the products enable them to be successful. Managers achieve their desired business objectives and project objectives. Managers may express their wins through actions such as presentations and publication on innovation. They may be rewarded with stock options.

Individuals in different roles express their wins to their peers through unique actions. Gnomes that code may express their wins through actions such as pushing files to their Git repo or answering questions on StackOverflow. Customers may express their wins by actions such as posting product reviews that describe how products enable them to be successful. Managers may express their wins through actions such as presentations and publications on innovation.

Notes:

The “What is Phase 2?” question was included in the “Gnomes” episode of South Park, Season 2. 16 December 1998. That episode provided an inspiration for this post.

The Law of Requisite Variety was formulated by W. Ross Ashby.

This post included material from my book Developing Winners.

[Requires iTunes or Apple Quicktime. Duration 9:24 minutes:seconds]

Helping the Gnomes that Code [ 9:24 ] Play Now | Play in Popup | Download

Design Thinking and the OODA Loop Sketch

Posted on July 10, 2014 by OpLaunch

Design Thinking is associated with innovation. The OODA Loop sketch encapsulates ideas associated with the essence of winning and losing. There are similarities in these two approaches and several significant differences.

Design Thinking

According to Wikipedia, Design Thinking is a “formal method for practical, creative resolution of problems or issues, with the intent of an improved future result.” Some illustrations of a process model for Design Thinking include six process phases.

A simplified process model for Design Thinking with iterative linkages between phases

Detailed process model for design thinking (Thoring & Müller, 2011)

A detailed process model for Design Thinking (based on Thoring & Müller, 2011)

The process phases are:

Understanding: Typically characterized by communication with other stakeholders and research. The goal is to collect existing information and become an expert.
Observe: Typically characterized by designers conducting interviews and observing people with a problem. The goal is to gather insight about the needs of users.
Point of View: Typically characterized by storytelling, clustering insights, and synthesis. The goal is to shape the perspective of each team member.
Ideation: Typically characterized by brainstorming, clustering ideas, and prioritizing. The goal is to generate ideas for possible solutions and then select one idea for more development.
Prototyping: Typically characterized by creating models, role playing, developing videos and graphics, and creating prototypes.
Test: Typically characterized by observing individuals interacting with prototypes. The goal is to gather feedback from users and stakeholders about the concept and the prototype.

The exclusive OR gateway (illustrated as an ‘X’ in a diamond shape) is a decision point for releasing/shipping the product to the market.

To some, a Design Thinking approach suggests that individuals can improve their potential for innovation by embracing a perspective consistent with that of the role of a designer. Alternatively, individuals without formal design training can embrace a design thinking approach as a complement to techniques associated with a master of business administration approach to management.

When employed for new product development, Design Thinking is an approach to innovation, not a guarantee. The product may be an innovation or a relatively worthless result. The market decides.

Proponents of Design Thinking include the Hasso Plattner Institute of Design (D-school) at Stanford University, Roger Martin at the University of Toronto, and Tim Brown of Ideo.

OODA Loop Sketch

The OODA Loop Sketch was presented in “The Essence of Winning and Losing” briefing to the public in June of 1995 by John Boyd, a retired US Air Force Colonel. His sketch encapsulated ideas that he had developed since his time as a US Air Force fighter pilot in the late-1950s.

OODA Loop sketch that includes feedback, feed forward, and implicit guidance & control. Based on a 1995 sketch by John Boyd.

One OODA Cycle, which includes concurrent observation, orientation, decision, action, and unfolding interaction with environment, can occur in a moment. The duration of the OOCA cycle can be represented by the width of one group of OODA components. An OODA Loop approach involves multiple OODA cycles that enable a win.

A representation of a series of air-to-air combat maneuvers

A simplified, illustrated version of a series of air-to-combat maneuvers with corresponding OODA loops during a competitive encounter between fighter pilots (represented by BLUE and RED) plus several gunsight images. This illustration includes a representation of “getting inside an OODA loop” and the win.

Often, an OODA Loop approach is associated with warriors involved in combat. Concepts that can be employed to shape a competitive win include:

Discerning tactical dispositions
Detecting mismatches
Generating mismatches in time, tempo, or rhythm
Generating mismatches in ability
Novelty
Cheng/Ch’i
Shih and the node
Manipulating friction
Generating confusion for the adversary while promoting harmony within your network

Concepts, such as harmony, initiative, adaptability, Schwerpunkt, and cycle time, associated with the OODA Loop sketch can be employed by individuals or groups during projects.

Similarities of the Design Thinking Process Model and the OODA Loop Sketch

The Understand item of the Design Thinking process model is similar to the Unfolding Circumstances and Outside Information items of the OODA Loop sketch.

The Design Thinking process model and the OODA Loop sketch include Observation components.

The Point of View component with its storytelling and synthesis items in the Design Thinking process model is similar to the Orientation component with its prior experience, cultural traditions, and analyses & synthesis items of the OODA Loop sketch.

The Ideation and Prototype items of the Design Thinking process model are similar to the Decision and Action items of the OODA Loop sketch.

The Test component of the Design Thinking process model is similar to the Interaction with Environment item of the OODA Loop sketch.

The phrase Design Thinking and the pre-cursors to the OODA Loop Sketch were developed in the 1970s, 80s, and 90s.

Contrasting the Design Thinking Process Model and the OODA Loop Sketch

Perhaps the most significant difference of these approaches involves perspective. A Design Thinking approach has biases for certain orientations and tools. It tends to be prescriptive.

An OODA Loop approach embraces wider perspectives and requisite variety.

Another difference involves durations. The process model of Design Thinking suggests that the time between “understanding” and “test” is in the range of hours to years. A Design Thinking approach could develop as one sequential progression from understand to test. When there is negative feedback, focus may be re-established on a particular item (such as ideate) and the sequence is resumed from that item.

One OODA cycle can occur in a moment. The goal of a series of OODA cycles is to enable a win.

Building and Employing Snowmobiles

Prior to presenting his OODA Loop sketch in 1995, Boyd summarized his insights about winners and losers in statements about snowmobiles.

“A loser is someone — individual or group — who cannot build snowmobiles when facing uncertainty and unpredictable change; Whereas,

A winner is someone — individual or group — who can build snowmobiles, and employ them in an appropriate fashion, when facing uncertainty and unpredictable change.” (Boyd, Revelation, 1987)

The concept of a snowmobile was used as a placeholder for something valuable. Boyd’s distinction that winners “build snowmobiles, and employ them” acknowledges that winners go beyond synthesizing options. They design, engineer, assemble, and test their products. They are persistent in evaluating the interaction of people with their products.

The phrase ‘appropriate fashion‘ includes characteristics such as the product’s features and the product’s reliability. It includes communication about the product. It refers to the user’s experience.

The word ‘can‘ emphasizes factors such as timing (such as the availability of snow to test a snowmobile), technology readiness, and the current alternatives offered by competitors.

The phrase ‘when facing uncertainty and unpredictable change‘ acknowledges the need to improve qualities such as agility and adaptability.

A winner is not required to be the inventor of a product or technology. A winner is not required to be the first-to-market a product.

The interplay of building, employing, and evaluating produces innovation. Boyd concluded that a “continuing whirl of reorientation, mismatches, analyses/synthesis and the novelty” is a “conceptual spiral for… innovation.” (Boyd, Conceptual Spiral, 1992)

Innovation and Winning

Individuals that embrace a Design Thinking approach tend to pursue innovation efforts from a specific perspective and to promote a specific process. Individuals that embrace concepts encapsulated in Boyd’s OODA Loop sketch strive to win with a “variety of possibilities as well as the rapidity to implement and shift among them” (Boyd, Patterns of Conflict, #176)

In Boyd’s revelation, the capability to build and employ snowmobiles in an appropriate fashion when facing uncertainty and unpredictable change was used to recognize innovation. Therefore, individuals within a network that have this capability are innovators. Boyd’s revelation can be re-written as: An innovator is a winner — individual or network — who can build new products, and employ them in an appropriate fashion, when facing uncertainty and unpredictable change.

Additional Information

1. This post included extracts from my book “Developing Winners: Assimilating the Insights Encapsulated in Boyd’s OODA Loop” 2. A humorous presentation, entitled “How to Lie with Design Thinking” by Dan Saffer quips that a Design Thinking approach relies too much on “the fun parts of design” and rearranging small pieces of paper with glue on one side. 2. Virgil D. White “received a patent (in 1917) for an attachment designed to convert a Model T into a ‘Snowmobile,’ a name coined and copyrighted by White” in 1913.

2. In 1917, Virgil D. White received a patent for “an attachment designed to convert a Model T into a ‘Snowmobile,’ a name coined and copyrighted by White” in 1913.

Antifragility in New Product Development

Posted on April 30, 2014 by OpLaunch

In the book Antifragile: Things that Gain from Disorder, Nassim Nicholas Taleb shared insights on optionality that can be expanded to include new product development environments.

This post provides an introduction to the non-linear gains associated with antifragile systems that may be realized by designing new product development environments that help individuals improve their capability to synthesize many new options continuously and enhance their proficiency to exercise options that are attractive. This post includes a comparison to concepts represented in Boyd’s OODA Loop sketch.

Fragile, Robust, Resilient, and Antifragile Development Environments

Taleb’s classification of systems as fragile, robust, resilient, and antifragile may be used to characterize development environments. Every development environment can be characterized in terms of its fragility, robustness, resilience, and antifragility.

Antifragile: Things that Gain From Disorder by Nassim Nicholas Taleb

A development environment that tends to be fragile does not welcome disorder. When uncertainty is injected, the results may be unpleasant.

In a fragile development environment, one obstacle can prevent the realization of value. Examples of harmful conditions include:

Incorrect, incomplete, or misleading information
A problematic handoff between functional groups
Disagreements among functional groups

Unpleasant results may include delays, cost overruns, and insufficient adoption of the product. Individuals tend to be frustrated. The more fragile the development environment, the less likely it is to thrive.

From project-to-project, a robust development environment tends to survive unchanged. Processes tend to be preserved. Individual contributors tend to retain their employment status.

From project-to-project, a resilient development environment survives changes from external factors. After a project is complete, there may be changes such as a re-arrangement of the organizational chart. New tools may be incorporated. The organization survives to serve the needs of the next project.

The word ‘antifragile’ is an adjective created by Taleb. It can be defined as the exact opposite of fragile. According to Taleb, “Antifragile is beyond resilience or robustness.”

An antifragile system thrives and grows when exposed to a moderate amount of volatility, randomness, disorder, and stressors. An antifragile system benefits from a moderate amount of adventure, risk, and uncertainty.

Iatrogenesis

In Chapter 7, Taleb described the concept of iatrogenics as “damage from treatment in excess of the benefits.”

Iatrogenesis: preventable harm resulting from the treatment or advice of a healer.

The word iatrogenesis is not common in product development but harmful inputs may come from multiple sources. These include:

Specialists that assume that solutions to development problems relate to their area of expertise.
Innovation pundits, consultants, and vendors that offer their favorite tools and techniques as solutions
Interventionalists that believe that their contributions will improve outcomes
Status quo

It may be difficult to recognize the harmfulness associated with specific sources because of cognitive biases or unvalidated claims. Recognizing harmfulness is more difficult in development environments that isolate individuals of different functional specialties.

New product development efforts can suffer from iatrogenesis. Approaches to recognize potentially harmful inputs and reduce potential damage from harmful inputs include:

Requisite Variety
Disintermediation
Pair Development

Requisite Variety

The concept of requisite variety can be used to emphasize the importance of having a diversity of potential responses in a development environment.

Requisite Variety: For a system to be viable, only a variety in responses can force down the variety due to disturbances.

The Law of Requisite Variety was formulated by W. Ross Ashby

For a development environment to be successful, only a large repertoire of possible responses can address the variety presented by a complex set of development problems that emerge throughout projects.

In a new product development environment, requisite variety may be achieved by mobilizing a network of contributors with diverse specialties and multiple perspectives. To be successful, individuals may require additional training, access to individuals with unique expertise, and cooperation.

Without requisite variety, previously successful responses to familiar patterns may not be recognized as insufficient responses.

Without a variety of potential responses at the appropriate times, a development environment may be fragile.

If there is excessive variety, the agility of the development environment may be reduced. To ensure appropriate adaptability, the network determines that certain responses should be amplified. Other responses are attenuated.

Disintermediation removes layers between individual contributors and data. It removes barriers between decision makers. One way to facilitate disintermediation in new product development environments involves individual contributors experiencing the interactions of customers with prototypes (or other experiments related to the product being developed). Direct observations that promote full-fidelity interactions are preferable to mediation approaches such as presenting individuals with reports that summarize activities.

Pair Development is implemented by facilitating the interaction of individuals of different disciplines (such as a coder and a marketer). Pair development provides an opportunity for interaction through activities such as dialog and sketching. The result of pair development should be the synthesis of options, not a summary of previous activities. Typically, no slides sets are used during these interactions.

Pair development in new product development

The result of pair development is the synthesis of options that is informed by the analyses available from multiple perspectives.

The purpose of pair development is not cross-training. The purpose is to develop a self-correcting focus and direction informed by the analyses of multiple perspectives.

Reducing iatrogenesis is a pre-requisite to synthesizing more attractive options.

Typical Options

A typical option, such as a financial option, provides a buyer with the potential to take action by a specified date without an associated obligation to buy or sell. Typically, an individual decides to exercise an option based on their perception of value at a specific time.

According to Taleb, optionality is the property of asymmetric upside (preferably unlimited) with correspondingly limited downside (preferably small).

Optionality: a quality of state where choice or discretion is allowed.

In Chapter 12 Taleb stated that “An option is a substitute for knowledge” In Chapter 13, Taleb wrote “antifragility supersedes intelligence.”

The value of a typical option depends on factors such as the negotiation skills of the individuals involved and the type of control individuals have over their decisions. Development options require additional proficiencies.

Example

Taleb summarized the experience of Thales, an ancient philosopher. Thales acquired an option to use equipment that may be needed during next year’s harvest. His potential profits or losses were not be determined solely by the accuracy of a crop forecast. If there was an abundant harvest, he could exercise his option for the equipment and be rewarded financially. If the harvest was scarce, he could decline his option and not suffer a loss. The harvest was bountiful and Thales built a substantial fortune.

Development Options

To improve the potential for success in new product development environments, an option must be more than a negotiated agreement based on a speculation. Development options are the most valuable when associated with current capabilities or a capabilities that may be acquired within an appropriate amount of time for an appropriate cost within the project constraints.

The approach to development within a network of individual contributors includes the interplay of capabilities with analyses and synthesis.

Synthesis is a process of connection. Synthesis generates something new and different. A synthesis approach enables one to imagine how a several capabilities may work together to produce the desired result.

In a properly designed new product development environment, proficient individuals analyze situations and synthesize new options continuously.

The interplay of synthesizing options and exercising options to improve antifragility

The interplay of synthesizing options and exercising options improves antifragility

The interplay of synthesizing options and exercising options includes interaction with the environment (feedback) that enables a network of individuals to comprehend, shape, and adapt during development. This enables operation at faster tempos and rhythms and the compression of cohesive observation-orientation-decision-action time cycles.

The capability to synthesize many development options and exercise a few attractive development options rapidly and repetitively enables a properly prepared network of individual contributors to realize non-linear gains that are not possible by alternate approaches such as ones that focus on managing mandates.

Comparing Development Options to Concepts Represented in Boyd’s OODA Loop Sketch

Concepts related to development options have similarities with concepts represented in John Boyd’s OODA Loop sketch.

The concept of synthesizing development options is similar to the Observation and Orientation items represented in Boyd’s OODA Loop sketch.
The concept of exercising development options is similar to the Decision, Action, and Unfolding Interaction with Environment items represented in Boyd’s OODA Loop sketch.
The outcome from cycles of synthesizing a multitude of development options and exercising a multitude of development options is consistent with victory and the representation of a “series of maneuvers” in an OODA Loop context.
The non-linear gains associated with exercising attractive options in antifragile environments are similar to Boyd’s themes for vitality and growth.

Concepts related to development options have similarities with concepts represented in John Boyd’s OODA Loop sketch. Synthesizing development options is similar to the Observation and Orientation. Exercising development options is similar to the Decision, Action, and Unfolding Interaction with Environment items.

Enhancing Optionality throughout Development

For each development project, the goal is to change the environment to improve the capability to synthesize a multitude of development options and exercise a multitude of development options that are attractive. To increase this capability throughout development, invest to improve the following objectives:

Design the development environment to embrace optionality
Produce new repertoire based on theory and refined by practice with others seeking a high level of proficiency. This requires a sustained, deliberate effort.
Develop the capability for rapid cycles of observation, orientation, decision, and action which is based on the OODA Loop concept from John Boyd.
Improve the capability to shift rapidly between options which is similar to the concept of Fast Transients from John Boyd. This is similar to improving agility.
Improve the capability of individuals to synthesize options that are cohesive across the network and cohesive over the duration of the project(s).
Improve the proficiency to exercise attractive options. Identifying attractive options includes developing a holistic perspective and recognizing iatrogenesis.

Antifragility and Development Experience

Individual contributors invest much of their time in new product development projects. Their personal investment is what Taleb refers to as “skin in the game.” I refer to an individual contributor’s day-to-day and year-to-year set of perceptions and responses as Development Experience [DX].

There are multiple approaches to improve an individual contributor’s development experience by reducing fragility, increasing robustness, or increasing resilience of the development environment. An individual contributor’s development experience may improve dramatically by designing the development environment to improve antifragility. According to Taleb, “The option is an agent of antifragility.” Options make vitality and growth possible.

Development options are agents of development experience. Development options drive non-linear gains in antifragile development networks. Designing to improve development options stimulates better performance from individual contributors even when there is volatility. This inspires better performance from others. This creates virtuous circles, beneficial cycles of development efforts. This inspires greater commitments to project success.

Additional Information

1. Taleb includes Post-Traumatic Growth as a characteristic of antifragility in Table 1 in his book. In “Beyond Surviving New Product Development” I defined:

Post Development Growth: the positive changes experienced by individuals that result from enhanced new product development capabilities. Post Development Growth includes reflection to achieve cognitive clarity. It goes beyond reflection to action.

An antifragile development environment is more likely to produce Post Development Growth. This tends to enable better outcomes in future projects.

2. A fragile development environment is consistent with the model introduced in “The Devastating Zero Model of New Product Development.”

3. Too many inputs may be harmful because it may be difficult to discern the valuable from the harmful or signal from the noise. Too many inputs reduce a network’s agility. A requisite variety approach must include ways to evaluate potential contributions to project goals. One approach is the development of “continuously correcting, network-informed schwerpunkt” described in my Reimagining How New Product Development Artifacts Impact What We Should Be Doing Today post.

4. This post included extracts from my book “Developing Winners: Assimilating the Insights Encapsulated in Boyd’s OODA Loop”

[Requires iTunes or Apple Quicktime. Duration 15 minutes]

Antifragility in New Product Development [ 14:45 ] Play Now | Play in Popup | Download

Reimagining How New Product Development Artifacts Impact What We Should Be Doing Today

Posted on March 31, 2014 by OpLaunch

In this post, I will share ways to categorize new product development artifacts. I will clarify several memes. Then, I will offer a concept that individual contributors can use as they determine what they should be doing on a particular day.

Two Types of Artifacts in New Product Development

During new product development, many artifacts are produced. The word artifact is from the Latin phrase arte factum, skill + to make.

Typically, the product is a valuable project artifact. Other artifacts include items such as “design documents, data models, workflow diagrams, test matrices and plans, setup scripts, …” (from “What does artifact mean” on Stack Exchange).

In the context of new product development, deliverables are a subset of artifacts.

A product may be characterized as a set of external deliverables. Other items may be characterized as internal deliverables. Some of the internal deliverables may be maintained as documents. These are not the only artifacts.

In the context of new product development, deliverables are a subset of artifacts.

Other Artifacts in New Product Development

In addition to external deliverables and internal deliverables, artifacts include:

Items used to produce deliverables such as tools
Secondary items produced during development. These may be unintended items.
Items that are not incorporated into the current project but may be incorporated into future development efforts. This includes training.
Incomplete, unfinished, or abandoned items
Intangibles such as development strategies, tactics, and culture

These items are a subset of artifacts.

Why it is Difficult to Determine What is Important Today

Individual contributors ask “What should I be doing now?” and “Why?” There may be questions such as ’Should a specific artifact be created?’ and ‘How much effort should be expended creating it?’ Resolving priorities may be difficult because of situations such as:

The number of items that could be explored during a project may be greater than the network’s (1) development capacity.
Predictions about the future (including how much effort will be required to develop a particular item such as a user story or feature) are estimates about an emerging set of conditions.
Some items are not on the list of considerations. Because of a lack of experience and insight, these items are not known.
Some priorities may be specified explicitly. Some issues seem to require immediate resolutions. Some priorities evolve.
Interruptions impact flow (2). This includes flow within functional groups and flow between functional groups and the system.
There are dependencies. For example, a coder’s efforts may precede a technical writer’s efforts during development.

Perspectives Influence the Perception of Value

The value of any artifact is subject to the perspectives of the stakeholders. Coders tend to value working code. Some individuals may stress the importance of prototypes they created. Copywriters tend to value persuasive messages. Other individuals favor spreadsheets.

Even though the word artifact has noble origins, it may have positive or negative connotations. Sometimes, there is an implication that certain types of artifacts have less value than a product delivered to the customer. For example, the Agile Manifesto includes the phrase “working software over comprehensive documentation.”

Perceptions about the value of artifacts and the attention that they should receive are driven by factors that include:

The status quo. A bias to repeat what was done previously. Value is attributed to what was delivered previously.
The loudest voice. The person that has the most authority. HiPPO, which is an acronym for “Highest Paid Person’s Opinion”
Curated information that may of may not be validated
Expectations from estimates and milestones.
Feedback from well-crafted experiments

Sub-optimization

When a multitude of individuals with diverse specialties develop artifacts, there may be a tendency to sub-optimize efforts.

Sub-optimization: A situation characterized by an individual (or a group of practitioners with a specific function) that tends to work within their specialty (sometimes referred to as silos) without regard for the impact on the output of the entire development effort (also known as the system).

Indicators of sub-optimization may include:

Efforts expended to improve a component do not improve the system performance
The success-limiting component does not receive the appropriate resources
Rewards are silos-centric instead of the system-centric

For the individuals that comprise the development network, producing artifacts quickly is not the main objective of new product development. That would be sub-optimizing based on a proxy for value. However, the capability to produce artifacts quickly contributes to achieving the main objectives.

Besides making decisions about which artifacts to develop, choices are made about developing the capabilities to produce artifacts. These choices depend on the proficiencies of the individuals that are mobilized for the development network and additional training that they receive.

Preparing to Make Better Choices

Suggestions that may help individual contributors make better hour-by-hour and day-to-day choices include:

Better choices are enabled when individuals improve their proficiency. According to John Boyd, “It is advantageous to possess a variety of responses that can be applied rapidly to gain sustenance, avoid danger, and diminish adversary’s capacity for independent action.” (Boyd, Patterns of Conflict, #12)
Some specialists tend not to believe that solutions exist outside of their area of expertise. Although a cross-functional team strategy may surface a few perspectives, employing the concept of Requisite Variety provides multiple perspectives to inform better choices about the system.
Better choices require considering the immediate needs and the entire timeline of the current project and the impact of the timelines related to future products.
The interplay of functional specialties accelerates the development of implicit coordination. It improves the resiliency of the network.

Suggestions that may help development networks (which are also be known as the system) improve their capabilities for cooperation, collaboration, and harmony include:

Invest in the development of Einheit, the short-term alignment of individual efforts.
Invest to improve schwerpunkt, a concept that provides focus and direction for the long term. It provides actionable guidance in situations where there are no explicit directions. It reinforces mutual trust. According to John Boyd, Schwerpunkt “acts as a center or axis or harmonizing agent.“ (Boyd, Patterns of Conflict #78) It contributes to a focus on the results.
Invest in the development of continuously self-correcting, network-informed schwerpunkt. This is the capability to adapt the concept that provides focus and direction over time so that the network can detect and correct mismatches from factors such as accumulated learning, evolving market conditions, and new boundary conditions.

A continuously self-correcting NPD network has the capability to detect and correct mismatches from factors such as accumulated learning, evolving market conditions, and new boundary conditions.

The phrase “working software over comprehensive documentation” from the Agile Manifesto should not be over-simplified to “eliminate documentation.” The improvement kata, a systematic, scientific routine of thinking and acting from the Toyota Production System should not be over-simplified to “eliminate artifacts by reducing the seven wastes (muda).”

Functional Specialists Embracing the System Perspective

To be more successful in a development network, find better ways to produce and integrate artifacts that contribute to the goals of development.

To make better hour-by-hour and day-by-day decisions, embrace a system perspective when writing more lines of code or producing more pages of documentation. Move beyond a perspective that is limited by reductionism or procrustean solutions. Encourage deliberative subtraction (deciding what not to develop) from the perspective of the system. Embrace new product development as more than a collection of diverse artifacts.

Embrace new product development as more than a job characterized by obvious answers where choices are framed as ‘OR’ selections. Embrace “AND” selections that meet the needs of the present and anticipate development in the future. Facilitate set-based design over point-based design. Strive to be proficient problem solvers that also invest in future capabilities. Incorporate artifacts that contribute to the goals and minimize distractions.

First rate individual contributors have the ability to hold a requisite variety of ideas about artifacts in their mind at the same time and still retain the ability to function. Refactoring F Scott Fitzgerald from The Crack-Up, April 1936 (3)

With that capability, you can improve your Development Experience [DX] which is another artifact that should be made skillfully.

Endnotes

This post included extracts from my book “Developing Winners: Assimilating the Insights Encapsulated in Boyd’s OODA Loop”
1. The definition of New Product Development Network from the Glossary for New Product Development

A New Product Development (NPD) Network is a temporary, dynamic, adaptive system designed to evolve a product vision and compare that to the reality of their current version. In an NPD network, individuals may report to multiple managers in multiple companies and have multiple priorities. Many individuals engage and disengage during the project.

Often, the word “teams” implies that most of the individual contributors are employed by one organization and assigned to a relatively small number of functional areas (such as engineering and marketing). Often, an individual is assigned to a project for most of the duration of the project. In contrast, NPD work groups are assigned specific tasks.

2. Mihály Csíkszentmihályi proposed this concept of flow.

3. The original quote was “The test of a first rate individual contributor is the ability to hold two opposed ideas in the mind at the same time, and still retain the ability to function.” by F Scott Fitzgerald

[Requires iTunes or Apple Quicktime. Duration 12:18]

Facts about Artifacts [ 12:18 ] Play Now | Play in Popup | Download

Paul McCartney and Subtle Signals

Posted on February 21, 2014 by OpLaunch

When the Beatles performed on the Ed Sullivan Show on 9 February 1964, there was noise from screaming fans. During this performance, John, Paul, George, and Ringo had difficulty hearing each other. However, they delivered a great performance. How did they coordinate their musical efforts?

Requisites to Coordination

The requisites to coordination in that noisy environment included:

Individually, John, Paul, George, and Ringo were proficient musicians. They invested years developing their musical abilities.
As a group, the Beatles practiced together for years. They performed under a diverse set of conditions. They had experience in ideal performance conditions and challenging performance conditions.
Musically, they knew what to expect. They pre-selected songs for the performance that they had mastered. The arrangements were designed for live performance by four musicians. These arrangements were familiar.
They did not rely on a technology that they could not control. They did not have a sophisticated audio monitoring system. They did not have headphones or in-ear personal audio monitors.
They did not rely on delayed feedback from others involved in the production.

In part, the quality of the musical performance required using information accumulated in the past to influence the future. This can be called a feed forward approach. A feed forward approach benefits from the involvement of proficient practitioners. In a feed forward approach, training precedes performance.

In other contexts, a feed forward approach may be characterized by a control signal that is transmitted from a source to a destination.

Prominent Signals and Subtle Signals

During the performances in 1964, the crowd noise was a prominent signal. During the performances, there were valuable subtle signals.

In a noisy environment, these subtle signals correlated with specific parts of each song. They included:

Discernible sounds such as the crash of a cymbal or the rumble from the bass drum
Facial expressions of the other musicians including mouth movements
Movements of fingers, arms, and feet of the other musicians
Interactions with the environment such as instantaneous interaction of the performance and reactions from the crowd

(Based on remarks by Paul McCartney in “The Beatles: The Night that Changed America. CBS 9 February 2014)

The subtle signals provided feedback during the performances. Feedback is an approach that uses information about current results to influence operation in the present. Feedback modifies a system based on interim results. Feedback changes the system output. This approach may be referred to as closed-loop feedback.

Subtle signals should be incorporated judiciously. Considerations include:

Valuable subtle signals may not be available when they would be the most useful.
Valuable subtle signals may be overlooked by novices.
An individual musician may not have the capacity to discern valuable subtle signals from the spurious subtle signals. Stated another way, an individual may not know that a subtle signal is valuable when they detect it.
The value of amplifying a particular signal by a specific amount is assessed by the nature of the results and the interaction with the environment.

Incorporating the appropriate subtle signals enabled the Beatles to be proficient performers in environments with nearly overwhelming undesirable noise.

Camera Operators Coordinated Their Efforts

It was so noisy in the Ed Sullivan Theater during the Beatles’ performances that the camera operators could not hear the instructions from the program director. The camera operators were proficient individually. They formed a cohesive team. They framed every shot without being able to hear the coordinating instructions from the director. The next week, a decision was made to replace the open-ear headphones with over-the-ear headphones.

(Based on remarks by the production crew in “The Beatles: The Night that Changed America. CBS 9 February 2014)

Mismatches

Mismatches address the differences of “our mental images/impressions and the reality it is supposed to represent” (John Boyd, Conceptual Spiral, 1992, 25)

A 2-dimensional model of impression, representation of reality, and reality.

Impressions flow from previous experience which includes knowledge, skills, training, and capabilities. Practice and theory shape impressions. Impressions establish the boundaries of the decisions that can be made and the actions that are possible. Words that can be substituted for impressions may include hypothesis and model.

Impressions may be faulty or incomplete. Impressions are built on assumptions. Biases influence impressions. Individual observations may be misleading. Errors may be unknown.

Representations of reality are influenced by:

Observations
Feedback from decisions
Feedback from actions
Interactions with the environment

Representations of reality may be faulty or incomplete.

Approaches should be developed to detect and correct mismatches. A properly developed approach enables impressions and representations of reality to be addressed and improved.

Mismatches address the differences of “our mental images/impressions and the reality it is supposed to represent” (John Boyd, Conceptual Spiral, 1992, 25)

The mismatch approach summarized in this post is based on the insights of John Boyd. Some of his insights are encoded in his OODA (for Observation, Orientation, Decision, and Action) Loop sketch (Boyd, The Essence of Winning and Losing, 1995).

OODA Loop sketch that includes feedback, feed forward, and implicit guidance & control. Based on a 1995 sketch by John Boyd.

Although the word “mismatch” is not one of the labeled items, the concept is encapsulated in the sketch and described in Boyd’s Conceptual Spiral briefing of 1992.

In situations that rely on a coordination of efforts, the potential for success is improved with rapid feedback and feed forward capabilities. An approach that has been developed to detect and correct mismatches can provide a way to make corrections dynamically. It provides a framework to ensure that mistakes aren’t propagated.

Proficient craftsman can incorporate selected subtle signals appropriately to achieve valuable results nearly instantaneously.

Proficient craftsman incorporate selected subtle signals appropriately to achieve valuable results instantaneously

Click To Tweet

A mismatch approach can be used in situations that include preparation, performance, and retrospective phases. In these situations, there may be long delays between analysis, plans, actions, and consequences. In these types of situations, feedback is delayed and it is more difficult to perceive relationships between cause and effect.

Prominent signals, subtle signals, and noise plus their interactions contribute to mismatches. Mismatches are multidimensional.

Applications to Development Experience in New Product Development

John, Paul, George, and Ringo continuously synchronized their efforts. Subtle signals helped Paul McCartney and the other Beatles coordinate their musical efforts during performances on the Ed Sullivan Show under conditions of extreme noise in 1964.

To improve your development performance, evaluate your approach to:

Requisites to Coordination
Subtle signals
Feedback
Feed forward
Impressions
Representations of reality
Mismatches

An appropriate analysis will suggest additional investment opportunity areas such as theory and practice. You will have insights to discern the valuable subtle signals from the spurious. Strive to improve your agility so that you can learn faster than the speed of the market and faster than competitors.

Analogous concepts can be applied to improve Development Experience [DX] in new product development.

Additional Information

The concept of prominent and subtle signals is not the same as weak and strong signals as described in the February 2014 McKinsey & Company article, “The strength of ‘weak signals:’ Snippets of information, often hidden in social-media streams,” offer companies a valuable new tool for staying ahead. In that article, weak signals refer to beliefs of a small population of elite users that may be thought to have a better than average capability to predict trends in the future. Subtle signals can be used to impact the present.

Endnotes

This post included extracts from my book “Developing Winners: Assimilating the Insights Encapsulated in Boyd’s OODA Loop”

[Requires iTunes or Apple Quicktime. Duration 9:20]

Paul McCartney and Subtle Signals: Applications to New Product Development [ 9:19 ] Play Now | Play in Popup | Download

The Unexpected Benefit of Interactive Prototypes in New Product Development

Posted on December 1, 2013 by OpLaunch

The greatest value of producing interactive prototypes can be the impact on the network developing new products. In some development environments, this value may not be communicated as a primary objective.

Sequential Development Processes

Some textbooks summarize the steps to new product development (NPD) as a sequential process:

Select one idea from a large list of possibilities
Scope the project. Develop a plan that includes estimates to transition from an idea to a complete new product
Craft a business case or business model
Develop the product. These development activities are typically done by individuals in roles such as scientist, engineer, coder, tester, marketer, subject matter expert, project manager, product manager, …)
Test the product internally
Produce high fidelity prototypes
Place prototypes with potential customers for external test
Craft a marketing communications package
Launch the product to the intended market

A phased-gate approach to new product development is characterized by a sequential process used to manage projects

Often, this approach is administered by:

A formal management process such as a Stage-Gate® process
A resource management process that includes a list of requirements for specific project roles
Other explicit processes, checklists, procedures, and practices

Often, when Agile or Lean concepts are introduced, the impact is limited to the day-to-day activities of development.

Common Uses of Prototypes in New Product Development

There are many kinds of prototypes associated with a sequential product development process.

Some prototypes are produced quickly. They are used to evaluate a few design parameters. Typically, these prototypes are discipline specific. Artists sketch. Electrical engineers breadboard. Designers wireframe. Marketers test messages with focus groups. Typically, these prototypes are produced early in the development effort. Often, the process of designing and building these prototypes enhances the capabilities of the functional specialists that produce them. The raw data from testing these prototypes remains within a small group of like-minded specialists. In many cases, an interpretation of the test results is summarized in reports that are distributed to other specialists and managers.

Other prototypes are produced in limited quantities near the end of the development process. The construction of these high-fidelity prototypes requires the integration of components from multiple functional disciplines. Since the prototypes are constructed prior to the market launch, the potential for changing the product is minimized. Often, the major reasons for the production of high fidelity prototypes are:

Test the integration of components developed by separate groups of specialists
Gather testimonials for use in the market launch
Use for compliance testing (such as electrical safety, crash testing, drop testing,…)
Forecast production problems

Other names for these prototypes include alpha-units or beta units.

Typical Benefits of Interactive Prototypes

Prototypes can be static or interactive. Typically, interactive prototypes can provide insights that a static prototypes can not. For example, instead of a designer producing static sketches of web pages, the prototype could be designed and developed in HTML and CSS. Instead of asking someone to evaluate the aesthetics of sketches, evaluators interact with dynamic prototypes to perform tasks and solve simulated problems.

Dynamic prototypes have the potential to provide valuable feedback. Since the feedback loop from the evaluator to the designer is faster, the potential for misinterpretation of the evaluator’s comment by the designer is minimized. The potential to detect mismatches (what the designer believed that the customer wanted and what the customer needs) is maximized.

When evaluators interact with prototypes, deficiencies are revealed. Individual contributors are presented with an opportunity to fix their mistakes and learn from the experience. When the testing efforts focus on product functions, prototype testing tends to impact individual contributors. Individual learning is associated with this testing.

Typically, interactions with prototypes impact an individual contributor’s orientation (the way they approach the challenges of development).

Typically, the primary benefits associated with the testing of interactive prototypes are associated with the potential to improve user experience (UX).

Unexpected Benefits

The value of producing interactive prototypes can go beyond generating user experience data. The greatest value can be the impact on the network developing the new product.

Individuals with enhanced capabilities in a new product development network are indicated by the difference in color and size. The white-colored field that surrounds these two individuals indicates better interactions between these contributors.

When the development of interactive prototypes involves many individuals from diverse specialties, it changes the way the network approaches development. When individuals from different perspectives (such as engineering and marketing) work together to develop an abundant number of interactive prototypes, the benefits include:

New opportunities for cooperation, collaboration, and harmony
Reduction of the innovation gap (the time from an idea to value creation)

Fewer tasks must be defined explicitly. Tacit knowledge is developed. The construction and maintenance of To-Do lists can be minimized because corrections are more likely to be made in real-time instead of adding items to a backlog for processing at a later time. The network becomes more cohesive. Appreciation of other perspectives improves. Situational awareness improves. The ability of the network to adapt improves. Network agility improves. The orientation of the network becomes more implicit. The potential for innovation improves.

When interactive, holistic prototypes are built and evaluated frequently throughout the development effort, the unexpected benefits include realtime improvements to feedback, feed forward, and implicit guidance and control proficiencies throughout the network.

OODA Loop sketch that includes feedback, feed forward, and implicit guidance & control. Based on a 1995 sketch by John Boyd.

As the development capabilities of the network are enhanced, the development approach becomes more recursive, the Development Experience [DX] for improves, and the probability of project innovation is maximized.

An improved potential for innovation is compounded. It can span the current project, the next project, and adjacent projects. Individuals retain enhanced capabilities for future development projects with other networks.

Endnotes

This post included extracts from the book “Developing Winners: Assimilating the Insights Encapsulated in Boyd’s OODA Loop” by OpLaunch founder, Mark A Hart.

The Unexpected Benefit of Interactive Prototypes in New Product Development [ 8:43 ] Play Now | Play in Popup | Download

An Alternative to Herding Cats in New Product Development

Posted on October 31, 2013 by OpLaunch

In some new product development (NPD) organizations, managers may feel that they are herding cats. Other organizations embrace a different approach and produce better Development Experiences [DX].

Herding Cats

Herding cats is an idiomatic saying that refers to an attempt to coordinate an intractable situation where individuals that are part of a team tend to do very different things. A manager may say “Managing developers is like herding cats” or “Managing designers is like herding cats.” When managers use this phrase, they may be invoking a stereotypical treatment of specific contributors. Alternatively, the phrase may be used to convey the frustration that arises from moderating disagreements between groups such as marketing and engineering.

My search of LinkedIn today returned 749 results for the phrase “cat herder.” There were 2101 results for “herding cats.”

One humorous treatment of this type of situation was depicted in the Cowboys Herding Cats advertisement in 2000.

The Development Experience where there are Cat Herders

When someone works in an organization that includes cat herders, the following cultural characteristics may be present:

The prevailing development approach relies on explicit coordination. The roles and responsibilities of individual contributors are documented extensively. Processes and checklists govern day-to-day activities.
Resources are considered to be interchangeable. The common belief is that one engineer can be substituted for another with similar qualifications.
It is assumed that the development environment is relatively stable and predictable. It is assumed that the cat herder will be able to manipulate behavior within the development environment. It assumes that the cat herder knows the criteria for success.
Cat herders shop for cat herding tools that incorporate the latest technology and fads. They do not refer to their tools as cat herding tools.
Cat herders transition from deadline to deadline.
Some individual contributors may be satisfied producing specified deliverables on specified dates. They may be glad to be working in an environment that embraces hand-offs between functional groups.

Orientation and Interplay

In Boyd’s OODA Loop Sketch, (Boyd, The Essence of Winning and Losing, 1995) the Orientation component includes the interplay of the following items:

Genetic heritage
Cultural traditions
Previous experience
New information
Analyses & synthesis

: The Orientation component from Boyd’s OODA Loop Sketch from “The Essence of Winning and Losing” 1995

The previous experience item includes a representation of an individual’s knowledge, skills, and capabilities. Some relevant experience is a result of specific training and deliberative practice.

Analyses is a problem solving approach that divides the whole into its constituent parts.

Synthesis is a process of connection. It generates something new and different. Synthesis benefits from inputs from a network of individuals with a diverse set of specialties. A synthesis approach enables one to imagine how a series of techniques may work together to produce the desired result.

Orientation and Schwerpunkt

Orientation can be defined as the way an individual approaches development. The appropriate orientation provides a unifying focus that pervades the development environment.

John R Boyd stated “Orientation is the Schwerpunkt. It shapes the way we interact with the environment—hence orientation shapes the way we observe, the way we decide, the way we act.” (Boyd, Organic Design for Command and Control 1987, 16)

The literal translation of schwerpunkt is “difficult point.” Carl Philipp Gottfried von Clausewitz (1780–1831) described schwerpunkt in “On War” which was published posthumously by his widow in 1832. Schwerpunkt conveys strategic objective, goal, or destination. Schwerpunkt is any concept that provides focus and direction to development. It provides actionable guidance in situations where there are no explicit directions. It reinforces mutual trust. It contributes to a focus on the results.

Schwerpunkt is a concise version of your strategy. It can be communicated in one sentence. In a military context, a schwerpunkt example is “Control the city in 72 hours.” For the Toyota Production System, it is about shortening the time it takes to confer customer orders into vehicle deliveries.

Schwerpunkt “acts as a center or axis or harmonizing agent.“(Boyd, Patterns of Conflict #78)

Schwerpunkt is “A focusing agent that naturally produces an unequal distribution of effort as a basis to gain superiority in some sectors by thinning-out-others.” (Boyd, Patterns of Conflict 78) Schwerpunkt guides individuals when they set priorities. It clarifies what to next to add value to your efforts.

The preferred orientation is implicit. In a development context, the intended meaning of implicit is closely connected, joined, interwoven, and intertwined. It is what you do without prodding from cat herders.

An Improved Development Experience

When a well-crafted, shared orientation exists throughout a development network, the development experience will be characterized by an abundant amount of cooperation, collaboration, and harmony. The development approach will be more recursive. Problems of a similar type will be solved instead of waiting for handoffs. Small continuous adjustments that are created simultaneously across specialties will cumulate and create substantial change.

Needs are anticipated. Dynamic adjustments are made. Multiple interdependencies are managed. Friction is diminished. Network efficacy, the shared belief in its capacity to successfully develop a specific item, increases.

Developing Orientation

Boyd had advice for developing a better shared orientation in military contexts:

“Arrange setting and circumstances so that leaders and subordinates alike are given opportunity to continuously interact with external world, and with each other, in order to more quickly make many-sided implicit cross-referencing projections, empathies, correlations, and rejections as well as create the similar images or impressions, hence a similar implicit orientation, needed to form an organic whole.” (Boyd, Organic Design for Command and Control 1987, 23)

For new product development contexts, ‘individual contributor’ can be substituted for “subordinates.” Steve Blank’s customer development advice about ‘getting out of the building’ is analogous to the phrase “interaction with the external world.”

In preferred NPD environments, schwerpunkt should not be about herding cats. The predominant metrics should not highlight process metrics. It should recognize individual contributors as knowledge workers and value contributors.

Closing Thoughts

Instead of focusing your efforts on herding cats or gaming the cat-herding-system, I advocate investing to develop better implicit orientations. This enables the development of a compulsion loop that can become a vital driver to sustain a vibrant new product development environment. A byproduct of this approach is a series of great products that are associated with great user experiences.

What is the schwerpunkt of your development environment?

Endnotes

This post included extracts from the book “Developing Winners: Assimilating the Insights Encapsulated in Boyd’s OODA Loop” by OpLaunch founder, Mark A Hart.

An Alternative to Herding Cats

An Alternative to Herding Cats in New Product Development [ 9:58 ] Play Now | Play in Popup | Download

Feedback and Feed Forward Approaches in New Product Development

Posted on September 30, 2013 by OpLaunch

This post explores feedback and feed forward approaches to improve development experiences in new product development (NPD).

This post was inspired by a new appreciation of the feedback and feed forward labels in John Boyd’s OODA loop sketch of 1995.

: OODA Loop sketch that includes feedback, feed forward, and implicit guidance & control. Created by Mark A Hart. Based on a 1995 sketch by John Boyd.

A more common and older use of the phrases feedback and feed forward is from the design of control systems for mechanical and electrical devices.

To prepare for sharing these insights relating to new product development, I will review simplified electrical circuits that can be used to control the temperature in an electrical, tank-type appliance used to heat and store hot water.

Initial Design of a Water Heater

An initial system design includes a tank to store hot water. It includes a heater in an insulated tank. It includes a switch to activate the heater and a sensor to measure the water temperature. The water temperature is regulated by turning the heater switch on and off.

An initial design for an electrical, tank-type appliance used to heat and store hot water

A more sophisticated design would permit a user to input a set point for the desired water temperature. Ideally, the system would provide water at the set point temperature regardless of how much water was used for any task.

A Feedback Approach to Controlling Temperature

When a feedback approach is implemented, the temperature of the water exiting the tank is measured and that information is used to control the heater circuit.

A feedback approach to controlling the temperature of a water heater

This type of control is a feedback approach because the temperature sensor is after the circuit element producing the heat.

Feedback is an approach that uses information about current results to influence operation in the present. It includes modifications to a system based on results. Feedback produces a reactive response. This approach may be referred to as closed-loop feedback.

For this design, there is a characteristic lag (a delay after hot water is depleted before the heater is activated to raise the water temperature) and overshoot (a condition caused by exceeding the temperature set point because of a delay in deactivating the heater). An unsophisticated control circuit can not distinguish a scenario when a small amount of water is used or when a significant amount of water is used.

A Feed Forward Approach to Controlling Temperature

One implementation of a feed forward approach senses the amount of cold water entering the tank. The heater is turned on as a function of the amount of cold water entering the tank. This approach uses knowledge about the system to predict how much additional heat will be required. Such an approach is proactive.

A feed forward approach uses knowledge about the system to transmit a controlling signal from a source to a destination

Feed forward is an approach that uses knowledge about the system to transmit a controlling signal from a source to a destination. A feed forward approach is a rules-based approach.

Simultaneous Control Systems

A feed forward approach should be used with a feedback system. These are complementary approaches. The combination provides a system that is more responsive and more effective.

There are examples of analogous approaches in new product development.

Feedback Approaches in New Product Development

During new product development, it is common to present product prototypes to potential customers and gather feedback. Prototypes can take the form of surveys, A/B tests, and other interactions with hardware, software, and concepts.

This approach may be associated with other popular phrases such as ‘fail fast’ or ’safe to fail experiments’ where learning follows the development of a prototype. Another popular version of this type of approach includes the concept of a minimum viable product (MVP).

Feedback approaches are consistent with processes such as Steve Blank’s Customer Development methodology where ideas and hypotheses are tested ‘outside of the building.’

Like other feedback approaches, these approaches are reactive approaches. There is a lag between ideation and observing results. There is a lag between research, developing an approach to the problem, decisions, and actions and the results from the unfolding interaction with those efforts.

Feed Forward Approaches in New Product Development

In a feed forward approach, a controlling signal is transmitted from a source to a destination. This is more a sophisticated approach than a simple handoff from one person to another. This is more effective than operating in silos. The control signal is persistent.

Rules shape the next steps. Rules may be explicit. Exceptions to rules may be permitted. Rules are propagated to the next development effort.

A feed forward approach benefits from the involvement of proficient practitioners. In a feed forward approach, training precedes effort. Training precedes the development of a prototype.

A design thinking approach is consistent with the concept of a feed forward approach.

Actionable Items

Feedback and feed forward approaches provide advantages in system controllers and new product development.

Now that you understand how to differentiate feedback approaches from feed forward approaches, take some time to classify some of your most frequently used methodologies.

Where there is feedback control, you can investigate ways to reduce the lag time following decisions and actions. You can review how feedback from prototypes is evaluated and incorporated into your efforts.

Where there is feed forward control, you can determine how investments in mastering the fundamentals and deliberative practice can enable you to do things that are beyond your current ability. Embrace more diversity in how problems are framed and solved. Learn faster ways to correct mistakes.

Feedback and Feed Forward in the OODA Loop Sketch

In John Boyd’s OODA loop sketch of 1995, feedback is indicated between Decision and Observations. Feedback is indicated between Action and Observations. Feedback is implied between the Unfolding Interaction with Environment and Observations.

In new product development, it is common to present product prototypes to potential customers and gather feedback. There is a lag between research, developing an approach to the problem, decisions, and actions and the results from the unfolding interaction with those efforts.

There are three labeled instances of feed forward control. These feed forwards should not be oversimplified to the concept of a transfer in a sequential process. Observations continuously shape orientation. Orientation shapes Decision. Decision shapes Action. These enable individuals to:

Create and test new actions
Update the way they approach problems by employing “a variety of domains or across a variety of competing/independent channels of information.” (Boyd, The Essence of Winning and Losing, 1995)
Employ new repertoire

An Additional Approach

There are two implicit guidance & control labels in the OODA Loop sketch. Implicit guidance & control combines the best attributes of feedback and feed forward approaches. These will be explored in another post.

Summary

Feedback, feed forward, and implicit guidance & control approaches provide advantages that include improved agility, better accuracy, and more effectiveness. These advantages contribute to better development experiences in new product development.

This post included extracts from “Developing Winners: Assimilating the Insights Encapsulated in Boyd’s OODA Loop” by OpLaunch founder, Mark A Hart.

Feedback and Feed Forward Approaches in New Product Development. This podcast is available on iTunes. Search for Development Experience.

This podcast is available on iTunes. Search for Development Experience. [ 9:50 ] Play Now | Play in Popup | Download

How to Absorb Changing Requirements in New Product Development

Posted on August 6, 2013 by OpLaunch

This post explores several approaches to prepare for absorbing changing requirements in product development projects. This post was inspired by Alistair Cockburn’s recent remarks.

Project Requirements

Many development projects have formal requirements. Most often these are found in projects that follow a waterfall methodology or those that embrace the Big Design Up Front (BDUF) approach. Typically, these types of projects contain requirements that include features that must be in the final product and constraints related to the schedule and budget. Sometimes the requirements change significantly as the project progresses. The changes may be frustrating to the development team.

Alistair Cockburn (@TotherAlistair) declared that he does not ‘welcome changing requirements.’ He sets up projects to absorb changes in requirements in the best possible way.

Cockburn made these comments on 2 July 2013 (VIDEO: the ‘set up to absorb’ comments are at at 38:30). The phrase ‘welcome changing requirements’ refers to one of the Principles behind the Agile Manifesto

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

To understand the context of his remarks, let’s review a few items from 2001.

Recollections from the meeting that produced the Agile Manifesto

Cockburn (pronounced Co-burn, the Scottish way ) was one of the 17 signatories of the Agile Manifesto in 2001. This meeting was not to develop something new. It served to summarize similarities in the approaches that had been used by the attendees for several years.

He recalled that the manifesto was crafted in one day. There was complete agreement over the wording. This includes the familiar phrases:

“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan”

Work began on the Twelve Principles behind the Agile Manifesto the next day. His recollection is that there was not complete agreement on all of the wording for the principles.

During the one hour Q&A 2 July 2013 session, Cockburn playfully emphasized the word ‘welcome.’ It seems that Cockburn may not have been in complete agreement with the choice of the word ‘welcome’ in the ‘welcome changing requirements’ principle.

The Mindset Regarding Changes

Cockburn has been involved with enough development efforts to know that requirements change during projects.

Some changes occur because of incomplete research or misunderstandings. Some errors may be perpetuated in the documentation. Mismatches may be revealed because conditions in the marketplace have changed since the requirements were gathered.

Projects can be designed to respond to changing requirements. Cockburn has adopted an active approach to absorb changes.

When Cockburn spoke of ‘absorbing changes’ he was not suggesting something analogous to a sponge absorbing water. The better analogy is a shock absorber on a vehicle. It is a device designed to smooth the driving experience for the passengers. It improves comfort and safety.

Several Ways to Set Up a Project to Absorb Changes

There are many ways to prepare projects to absorb changes. In this post, I will summarize a few approaches that Cockburn has employed.

Information Radiators

When the team has access to relevant, emerging information, they are more likely to be able to absorb changes. One way to share emerging information is with an information radiator. Cockburn coined the phrase “information radiator” in approximately the year 2000. According to Cockburn, an information radiator needs to be large (easily seen), easy to understand, public, and changing. Information radiators promote interaction. Current development information, including problems, should be visible to everyone on the team so that specific problems are perceptible to the individual that may have the solution.

Often, information radiators are positioned on the team room wall or some other conspicuous place. An information radiator facilitates distributed cognition.

The opposite of an information radiator is an information closet. Cockburn cautioned against the tendency to store necessary information online and assume that team members are interacting with it.

Capture educational information from interactive sessions in rich formats

To efficiently and effectively facilitate information transfer to new or less experienced members of the team, Cockburn advocates a one-to-one interaction format that is recorded. For example, the expert on a specific item can meet with a new team member to explain specific items. A white board or flip chart can be used to visually capture some of the information. The session should be interactive with questions and answers. The session must be recorded so that when the next new team member needs to learn about this item, they can start by reviewing the recording.

Instead of an emphasis on formal documents or presentations, this approach relies on the interaction that results from dialog.

Overall, this interactive approach emphasizes the pursuit of activities that maximize the production of value and minimize the time spent on project artifacts.

Ensure that the team includes Ri-level practitioners

To maximize the potential to respond appropriately to changes in requirements, Cockburn advocates that development teams include Ri-level practitioners.

Cockburn uses the concept of Shuhari to characterize the stages of learning to mastery. For a particular set of skills, an individual can be classified in one of three levels:

Shu-level: An individual has learned a technique but is not aware of the limitations. They look for broad level clues.
Ha-level: An individual has collected multiple techniques but may not know why they are appropriate for every context.
Ri-level individuals invent and blend techniques. They insist on contextual clues before providing recommendations.

An individual can be a Ri-level practitioner in a narrowly defined area such as a particular programming language or in the broader context of product development. Having a critical mass of Ri-level individuals as part of the team improves the potential for selecting the appropriate options based on the specifics of the project.

In addition, individuals that have the insights to craft experiments and the skills to produce rapid prototypes are more likely to distinguish unvalidated inputs from validated inputs. They are more likely to distinguish opinions that may be unsubstantiated from refined information that can shape project requirements.

A Series of Cooperative Games

A cooperative team is equipped to handle changes better than a team that promotes non-cooperative functional areas (also known as silos). Cockburn envisions development as a cooperative game.

“I would like you to consider software development as a cooperative, finite, goal-seeking, group game. The goal is to produce a working system. The group, or team, consists of the sponsor, manager, requirements or usage specialists, software designers, testers, and writers. Usually the goal is to produce the system as quickly as possible, but there are other factors that affect the time goal: ease of use, cost, defect freedom, and liability protection. In general, it is a resource-limited game, which affects how the moves are made”

A cooperative game approach is consistent with a harmonious team effort toward a common goal. Within a cooperative game paradigm, changes to requirements are more likely to be viewed as a correction to achieve the common goal rather than a struggle to promote a particular perspective.

Development Experience

A team that has the benefit of items such as appropriate information radiators, efficient and effective training, an abundance of expertise that enables a variety of approaches to solve problems, and, a cooperative game approach is likely to thrive when presented with changes to project requirements. A team that has prepared for changes is more likely to thrive.

Cockburn advises teams to improve agility and adaptability. An environment that promotes the qualities of agility and adaptability is more likely to adjust to changes in requirements.
This type of team is more likely to enjoy better development experiences.

How to Absorb Changing Requirements This podcast is available on iTunes. Search for Development Experience.

How to Absorb Changing Requirements in New Product Development [ 10:58 ] Play Now | Play in Popup | Download

Challenging the doctrine of co-located teams in new product development

Posted on July 10, 2013 by OpLaunch

There is an abundance of academic research to support the performance advantages of co-located teams in new product development. Marina Mendonça Natalino Zenun, Geilson Loureiro and Claudiano Sales Araujo in “The Effects of Teams’ Co-location on Project Performance” suggest the following definitions:

Team: a small number of people with complementary skills who are equally committed to a common purpose, goals, and working approach for which they hold themselves mutually accountable.

Co-located Team: a team that has a common physical area specifically allocated to the execution of the tasks related to the project. The team members shall seat close together. By close, it is defined as close enough that they can overhear each other’s telephone conversations.

In “Design Teams: Co-location Trumps Remote” Jared Spool observed that co-location of a team facilitates the development of a common vocabulary for an emerging vision. He wrote “A co-located design team will have an easier time of producing great designs than a remote team.”

Challenging the Implications

The performance comparison of a co-located team and a remote team may have an implication that the two ‘teams’ are composed of the same number of individuals with the same set of unique skills and experiences and training.

The two groups of individuals do not have to be ‘the same’ in every aspect expect where they sit. Consider the following potential differences in the remote network

Challenge 1: The remote network can include individual contributors with superior skills in the designated domains. Several individuals can have enhanced capabilities in appropriate domains.

Challenge 2: The product champion (product manager, product owner, development lead,..) for the remote group can be ten times more capable of leading a remote network of individuals that have a more diverse skill set than the person in the equivalent role for the co-located team. The person recruiting the talent for the remote network can have a better vision of what will be required at various times during the project than their counterpart for the co-located team.

Challenge 3: The remote network can have supporting tools for cooperation and collaboration that are five times better than the generic tools of the co-located team.

Challenge 4: The project may benefit by having individuals that have been immersed in a particular culture or a variety of cultures. The geographically dispersed team may be equipped to understand the regional/global aspects of the project more quickly that the co-located team.

Challenge 5: The nature of the project may benefit from testing the product in multiple geographic locations. The geographically dispersed network may be equipped to make more direct observations of potential customers using the product. They may have better skills to interpret the results.

Challenge 6: There may not be sufficient supporting resources for a co-located team at a central facility. There may be shortages of physical space or IT support. A distributed network may be able to adapt to an evolving need for specified head-counts and expertise better than a co-located team. The remote network may be able to mobilize ‘available resources’ (those that do not have obligations to other concurrent projects) better than a co-located team.

Challenge 7: The remote team may be available to take advantage of an emerging opportunity when a co-located team’s involvement may be delayed. The ability to begin learning soon may provide a unique competitive advantage.

Challenge 8: If the business case is compelling enough to justify starting the project immediately, it may be easier to raise additional funds to expand the portfolio using a remote network than it would be to re-arrange the assignments of individuals that are part of co-located teams with responsibilities to other projects.

Enhancing the Capabilities of Individuals in Development Networks

I have never completed a project where every individual on the team was co-located. Some contributors were located more than 10 meters from the core group. Some contributors were located in other buildings or in other timezones. Some contributors were not employees of the company funding the project. Some contributors may have been described as part-timers, vendors, partners, contractors, or temporary workers. It is unlikely that any of my future projects will be done with a co-located team.

Since more development work will be done with individuals in remote networks, what approach is more likely to produce better outcomes for customers, the business, and the individuals involved in the project?

To improve the outcomes for the customers, the business, and the individuals involved in the project, I recommend investing to improve the capabilities of the individual contributors. This includes enhancing the skills of individuals in their current specialties and providing training to expand their capabilities. This includes improving the potential for selecting more appropriate talent. This includes enhancing the capabilities for individuals to contribute value to the network.

Actionable Items

Evaluate the eight challenges. Contemplate others. Invest to improve the capabilities of individuals that contribute to your remote networks.

Developing the Conditions for Better Compulsion Loops in New Product Development

Posted on July 5, 2013 by OpLaunch

How do you get individuals involved in new product development to do more of the effective activity? There are many approaches. In this episode, I will explore several concepts from game development. I will describe how to develop the conditions for a core compulsion loop to drive positive Development Experiences (DX) in new product development.

Game Thinking and Game Mechanics

Often, playing a game is associated with the concept of fun. During game development, individuals are involved in tasks such as designing, coding, and composing, their deliverables. In addition, they strive to make playing the game fun.

According to John Earner of Space Ape Games, a great game has the following characteristics:

You are not forced to play the game. If you are forced to play, you are likely to resist.
In itself, playing the game may seem unproductive but it allows learning. A game probably has a purpose.
The outcome is uncertain.
You understand the rules
The game may be set in artful, virtual worlds. These worlds can capture an experience in a fictitious environment.
Games have easily understandable goals such as ‘save the Princess.’ Throughout a game, you may avoid obstacles, win tokens, and advance to the next level so that you are closer to saving the Princess.

It is not a surprise that some of these game characteristics have been applied in other contexts. The term for this is gamification. According to Wikipedia:

“Gamification is the use of game thinking and game mechanics in a non-game context in order to engage users and solve problems”

According to Stephanie Morgan, (@notSMorgan) “game mechanics are constructs of rules intended to produce a game. Common game mechanics include:

Scores and points accumulated through experimentation, interaction, and learning
Achievements such as badges and rewards
Avatars that provide a sense of identity”

Unfortunately, the concepts of gamification are frequently misinterpreted. One needs more than a tally of scores or a presentation of leader boards to maximize fun or interest or engagement. It requires more than dazzling graphics and carefully composed music.

Note: Some individuals may try to manipulate the system for a desired outcome. This is also known as “gaming the system” (http://en.wikipedia.org/wiki/Gaming_the_system) . This is different than gamification.

Core Compulsion Loops in Game Development

To understand what makes a game fun, some have explored a concept called the core compulsion loop. Some say that the proper development of a core compulsion loop is the essential ingredient for a successful game.

The word compulsion has definitions that range from:

The state of being forced
A difficult to resist urge to behave in a certain way

In the game context, the ‘difficult to resist urge’ conveys the desired intention for a core compulsion loop. A properly developed compulsion loop feeds the mechanics of the game.

A simple, primary compulsion loop is kill monsters, obtain rewards, buy items to kill more monsters.

A simple compulsion loop from a game

Secondary compulsion loops can be layered and fed into one primary compulsion loop. A secondary compulsion loop may have an element that may be characterized as instant gratification. The primary compulsion loop has a long-term impact. The primary compulsion loop may be characterized in terms of accomplishment.

A properly functioning primary compulsion loop is a virtuous circle that keeps players engaged.

Note: In this post, I am presenting compulsion loops from a positive perspective. Compulsion loops can designed to amplify destructive, additive behavior. I am not addressing those aspects in this post.

Common Gamification Approaches in New Product Development

Common approaches to new product development activities include:

Document explicit processes
Compliance enforcement. Establish milestones and demand accountability to deadlines.
Financial incentives related to salaries and bonuses of individual contributors

There are more subtle forms of gamification. One example is part of the Scrum framework. It embraces the concept of assigning story points for tasks and tracking progress with a burn down chart. This is a reasonable method to track project progress but it does not make for a great game.

Planning Poker Cards used in Scrum to represent story points. The numbers approximate a Fibonacci Sequence.

These methods are not likely to form high performance compulsion loops.

Generalized Version of a Compulsion Loop for New Product Development Environments

A properly designed compulsion loop can become a vital driver to sustain a vibrant new product development environment. A general version of a compulsion loop can be illustrated using goals that are consistent with the concepts of “autonomy, mastery, and purpose” as advanced by Dan Pink (@DanPink) in his book Drive.

Drive: The Surprising Truth About What Motivates Us by Daniel Pink emphasizes the roles of autonomy, mastery, and purpose

Autonomy is defined as the ability of a person to make their own decisions. It is self-direction. In a new product development environment, one strives to make better decisions. In this context, autonomy includes individual and group decisions. It includes decisions that the have an impact in the present and those that impact the future.

Mastery includes becoming more proficient with tools and techniques related to individual specialties (such as coding, testing, and marketing). It includes explicit and implicit coordination, collaboration, and harmony within a group.

Purpose includes the ‘why’ questions. In a new product development context, purpose relates to individuals and the product.

Personal purpose includes questions such as “Why am I doing this?” and “Why should I care about this?” It includes short-term and long-term perspectives. Purpose includes questions such as “How do my efforts impact others?”
Product purpose may include a product vision statement or value proposition. It may not completely express the purpose of the product.

In part, purpose may be transmitted from management. In part, individual contributors inform management. Purpose develops from interactions. Purpose emerges.

Developing the Conditions for Better Compulsion Loops in your New Product Development Environment

The concepts of autonomy, mastery, and purpose may provide a general starting point to develop the conditions required for a compulsion loop.

A compulsion loop for an individual in a new product development environment

A high performance compulsion loop can not be developed instantaneously. It requires more than the aspiration of the leadership or a single individual in the development network. It requires more than creating a motivational graphic to represent a compulsion loop and posting it throughout the workplace.

A high performance a compulsion loop requires the appropriate supporting environment. It requires investments by individuals to understand the theory. It requires sufficient time to develop proficiency through practice.

To explore how this development may occur, consider a few items related to the concept of autonomy.

Someone does not become fully autonomous just because a new initiative begins.
The expression of autonomy is role dependent. Leaders may encourage autonomous behavior in their direct reports but the range of appropriate behaviors will be role dependent. For example, a senior project leader will behave in ways that are different than that of a neophyte. Likewise, a coder will make different decisions than a tester.
An individual contributor may embrace their autonomy but not have sufficient knowledge to make informed decisions throughout development. Ongoing training is required to maximize the potential for desirable results.
An individual’s expression of autonomy evolves and adapts.

In terms of autonomy, the development environment should promote decisions that result in characteristics such as enthusiastic, effective, and efficient decisions for engagement.

In terms of mastery, the development environment should promote activities that result in comprehensive knowledge and accomplishment. An individual should advance their skills in their specialty (such as coding in a particular language) and expand their skills (such as coding in a new language).

An individual should increase their understanding of how they create value through their interactions with others in the development network. An example of purpose is captured by in the following excerpt:

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

Agile Game Development by Clinton Keith

Better Compulsion Loops in New Product Development Environments

To get individuals to do more of the effective activity, develop conditions to ensure that the activity produces fun. I am using the word ‘fun’ to cover a broad category that can also include items such as fulfilling, satisfying, and intellectually challenging.

For knowledge workers, I contend that a compulsion loop based on fun will produce better outcomes than one that is based on compliance.

I acknowledge that deadlines and performance reviews that relate to salaries may motivate individuals during certain times in a project but that is an inferior compulsion loop.

It is better to evolve notions of compliance to reflect the project constraints. In a project, constraints evolve as information emerges.

Prototyping a Better Compulsion Loop in your New Product Development Environment

When a new product is being developed, prototype the compulsion loop before you invoke a lot of technology. Individual contributors want fun and technology.
In a new product development context, prototype the conditions that you believe will produce a great Development Experience (DX). When you have done that, you will have the insights required to develop a high performance primary compulsion loop.

Developing the Conditions for Better Compulsion Loops

Developing the Conditions for Better Compulsion Loops in New Product Development [ 12:33 ] Play Now | Play in Popup | Download

Interview of Gerry Katz on the Voice of the Customer webcast 27 June 2013

Posted on June 25, 2013 by OpLaunch

I will be moderating a PDMA webcast on Thursday 27 June 2013. The presenter will be Gerry Katz of Applied Marketing Science. The topic is “Hijacked Again! Three Trends in the Field of Voice of the Customer – Some Welcome, Some Not”

Gerry Katz of Applied Marketing Science on the Voice of the Customer

When I asked Gerry “Why should someone attend this webcast?” he said:

“Because I am going to clarify all the crazy misperceptions and misinformation about what is going on in the field of VOC.”

Gerry will be describing the roles of Naysayers, Stretchers, Technovangelists. He will provide his insights on the potential for incorporating Social Media in Voice of the Customer efforts.

Here is our pre-event interview:

Mark Hart interviews Gerry Katz on Hijacked Again [Duration 2 minutes. 1 MByte]

Update: The webcast recording is available. Free with registration.

A Common Impact on Development Experience

Some implementations of Voice of the Customer research involve specialists conducting surveys and interviews. Often, reports summarizing the customer’s responses are made available to a portion of the development team and the results are summarized to shape project objectives.

With this type of implementation, some individual contributors may have the following reactions:

Relief. Since there have been interactions with a small group of customers, you as can concentrate on your primary role (such as coding, engineering, writing,…)
Perceived increases in confidence because current decisions are supported by customer research
Belief that a portion of the design has been validated for a future product release.
Confidence that additional project requirements have been finalized

The preceding reactions tend to occur in development contexts that favor compartmentalized workflows and functional silos of expertise.

An Alternative Approach

Another approach strives to enhance capabilities of individuals for implicit coordination, interaction, the design of well-crafted experiments throughout development.

In this approach, multiple techniques, including Voice of the Customer techniques, are employed to learn about:

An evolving set of customer wants and needs
An evolving vocabulary about an appropriate user experience and the product
An evolving set of customer priorities

Simultaneously, individuals contributors in the development network strive to improve their autonomy, mastery, and purpose to improve their development experience.

What I Hope to Learn during the Webcast

During the webcast, I will be attentive to learn about betters ways to integrate Voice of the Customer techniques into development networks. As a bonus, those enhanced capabilities will enable more individual contributors to develop better products for customers.

Reductionism and Recursion in New Product Development

Posted on May 31, 2013 by OpLaunch

Which approach to new product development will produce better results? Reductionism or Recursion?

Reductionism

According to Wikipedia:

“Reductionism is a philosophical position which holds that a complex system is nothing but the sum of its parts, and that an account of it can be reduced to accounts of individual constituents.”

In new product development, reductionism is rationalized as breaking development tasks into manageable pieces. Typical artifacts are seen in organizational charts or the roles assigned to individuals. For example:

Coders or Testers
Designers or Developers
Marketers or Sales
Project Managers or Product Managers
Front End of Innovation or Development

One of the potential advantages of reductionism is that it may provide focus to specialty efforts. Another potential advantage is that is may facilitate the interchangeability of resources (for example, one tester can be replaced by another tester with the equivalent qualifications).

Potential disadvantages of reductionism approaches include:

Degrades communication across functional groups
Acceptance of a hand-off mentality. This occurs when one functional area ‘finishes their job’ and presents their deliverables to the next group.
Increases the amount of explicit documentation
Sub-optimization. Too much effort may be devoted to certain tasks while others items do not receive sufficient attention.
Too much emphasis attributed to reaching milestones. Not enough emphasis on value creation.

Recursion

Recursion involves solving problems of the same form. In new product development, typical primary problems include:

Solving a customer’s problem. This is also described as providing a solution for the job the customer is trying to accomplish.
Increasing the organization’s revenue and/or profits
Positioning the organization for success in the future
Increasing the motivation of the development network. Dan Pink described this using the qualities of autonomy, mastery, and purpose. I describe this as improving the Development Experience [DX]

Recursion in the Development Network

For a recursion approach to flourish, an individual relates their short-term efforts (such as hourly, daily, or weekly efforts) to solve one or more of the primary problems listed in the previous section. For example:

Are their current efforts improving the ability of a customer to solve their problem? Has the learning increased so that individual contributors can determine if they are closer to solving the customer’s problem today than they were yesterday?
Are these efforts valuable to the customer? Are these efforts too bureaucratic?
Will the development efforts for the next project produce better results than the current project? Are the development capabilities being enhanced for future projects?
Will the contributors to the development network feel a sense of accomplishment? Will the predominant feelings relate to burn-out and frustration?

An environment that enables recursion to flourish ensures that individuals embrace opportunities to contribute to value creation during the current project and future projects.

Alistair Cockburn described this type of approach as a series of cooperative games. He stated:

“Software development is a series of resource-limited, goal-directed cooperative games of invention and communication. The primary goal of each game is the production and deployment of a software system; the residue of the game is a set of markers to assist the players of the next game. People use markers and props to remind, inspire and inform each other in getting to the next move in the game. The next game is an alteration of the system or the creation of a neighboring system. Each game therefore has as a secondary goal to create an advantageous position for the next game. Since each game is resource-limited, the primary and secondary goals compete for resources.”

Clinton Keith described it this way:

From the book “Agile Game Development with Scrum” by Clinton Keith (@ClintonKeith) page 227. Published in 2010.

Contrasting Recursion and Iteration

Iteration is repeating. Often, it involves executing the same process with new items from a long list of potential tasks.

In Scrum, Sprint is the term for an iteration. In Scrum, the duration of a typical Sprint is in the range of one to four weeks. During a Sprint, development is devoted to completing selected items from a backlog of items.

Common metrics for a series of Sprints may highlight factors related to the speed of execution. This may include items such as burn-down rate.

One of the potential problems with an iteration mindset is that the number of product features that are completed is associated with a proxy for the value produced by the project.

Which is Better?

Which approach provides better value from a project? Is it a reductionist approach or a recursion approach?

A tyrannical approach does not produce better project value. Debating over a development question that includes the word ‘or’ is not likely to improve qualities such as autonomy, mastery, and purpose.

Better value will be produced with the proper combination of reductionism and recursion. Some individuals excel as reductionists. However, the potential for project success can not be achieved when the reductionist viewpoint is the only viewpoint that is tolerated.

Maximizing the potential for project success requires that one or more of the primary problems is being solved. Solving these primary problems is best accomplished with the inclusion of a recursion approach. This requires more than assigning someone to a role such as Product Owner.

I have found that that potential to maximize success in new product development improves when there is a critical mass of individual contributors that embrace a recursive approach to development. This diversity in the development network improves the potential for harmonious plans, decisions, and actions throughout development. It improves the potential for the self-correcting analysis of feedback.

Vision and Version

The interplay of vision and version in new product development

The interplay of reductionism and recursion is similar to the interplay of vision and version in new product development. These approaches facilitate implicit coordination within a diverse group of individual contributors throughout development that will produce better outcomes than alternatives that enforce handoffs and explicit coordination during development.

With a synergistic approach, the customer’s problem is more likely to be solved. The Development Experience [DX] of the individual contributors is more likely to improve from one project to the next.

Reductionism and Recursion in New Product Development (10 Minutes, 15.5 MBytes)

Reductionism and Recursion in New Product Development [ 9:52 ] Play Now | Play in Popup | Download

Beyond Surviving New Product Development

Posted on April 29, 2013 by OpLaunch

Individuals expect stressful portions of their new product development projects. An abundance of complaints may be a precursor to an abundance of stress. Individuals expect to have sufficient resiliency to cope with the stress. Even when exhausted, individuals expect to recover in time to keep their commitments to the next project. Individuals expect to survive.

There is a potential for something more positive than survival. This post explores the potential for growth.

The Negative Aspects of Stress

During new product development, stress is one of the costs of participation. Because of stress, some individual contributors deliver sub-standard work.

According to Chet Richards, “John Boyd thought of stress as an offensive weapon.” Richards references Boyd’s words to define stress. Boyd stated:
“Generate uncertainty, confusion, disorder, panic, chaos … to shatter cohesion, produce paralysis and bring about collapse. “ (Boyd, Patterns of Conflict, 1986 #132)

For challenging projects, some individuals may feel overwhelmed. Because of their perceptions of the effort required for project success, individuals may risk “burning out.”

For problematic projects, phrases such as “death march” may be used to describe the development experience. According to Wikipedia

“Death March: In project management, a death march is any of several types of pathologic projects involving a dysphemistic, dark-humor analogy to real death marches, such as being gruelingly overworked, and (often and most especially) being gruelingly overworked for ill-founded reasons on a project that is obviously at high risk of bad outcome (i.e., project failure, and possibly threat of personal and group reputation damage). “

To understand the impacts of stress, I will highlight two items from current studies in psychology, posttraumatic stress and posttraumatic growth.

Posttraumatic Stress Disorder (PTSD)

Stress may do more than reduce performance or produce other short-term harmful impacts. Consider the definition of posttraumatic stress disorder, PTSD.

According to Wikipedia:
“Posttraumatic stress disorder (PTSD) is a severe anxiety disorder that can develop after exposure to any event that results in psychological trauma… Posttraumatic stress disorder is classified as an anxiety disorder, characterized by aversive anxiety-related experiences, behaviors, and physiological responses that develop after exposure to a psychologically traumatic event (sometimes months after). Its features persist for longer than 30 days, which distinguishes it from the briefer acute stress disorder and are disruptive to all aspects of life.”

Posttraumatic Growth (PTG)

Something good can emerge from bad situations. In some instances, growth can result from a stressful experience. Psychologists use the phrase Posttraumatic Growth. The phrase Posttraumatic Growth was coined by Richard Tedeshi, a psychology professor at the University of North Carolina in Charlotte.

Posttraumatic growth is not the same as resilience. Resilience is assessed by one’s ability to return to pre-trauma levels. Posttraumatic growth is characterized by achieving higher levels of functionality than pre-trauma levels.

According to Wikipedia:

“Post-traumatic Growth refers to positive psychological change experienced as a result of the struggle with highly challenging life circumstances. These sets of circumstances represent significant challenges to the adaptive resources of the individual, and pose significant challenges to individuals’ way of understanding the world and their place in it. Posttraumatic growth is not simply a return to baseline from a period of suffering; instead it is an experience of improvement that for some persons is deeply meaningful.”

Tedeschi and Calhoun (1) proposed a Posttraumatic Growth Inventory (PTGI) comprised of five factors:

Relating to others
New possibilities
Personal strength
Spiritual change
Appreciation of life

An online inventory tool is available from the American Psychological Association. A scale measures perceived benefits.

Posttraumatic Stress Disorder and Posttraumatic Growth
When Psychologists studied individuals that experienced traumatic life events, they have found that traumatic situations may lead to Posttraumatic Growth (PTG) and Posttraumatic Stress Disorder. The takeaway is that Psychologists are trying to treat stress and promote growth.

What happens in new product development?

Something analogous to posttraumatic stress disorder and posttraumatic growth can occur during new product development. Development can produce stress for some and growth for others.

Post Development Stress
Occasionally, the characterization of a new product development project goes beyond stressful to traumatic.

In extreme cases, an individual contributor can suffer from what I am calling post development stress, PDS.

Symptoms of post development stress may include:

Prolonged grumpiness and irritability
Decreased trust of individuals in leadership and management roles.
Decreased engagement in activities previously characterized as pleasant. An individual contributor can transition from being characterized as a ‘valuable team member’ to performing in a perfunctory, uncommitted fashion.
Transition from current roles in development to other opportunities that are perceived as less stressful. Changes in employment.

Post Development Growth
Everyone wants to survive new product development. Some aspire to go beyond adapting to the situation. Some aspire to what I am calling Post Development Growth (PDG).

To uncover examples of growth, my favorite starting point is to ask someone to tell me about the best project of their career. I do not want to hear about the project that made the most money or won a prestigious award. I want to learn about the project that made them smile when they recall the experience.
Typically, one of the following phrases is part of a story about the best project of someone’s career:

I learned a lot
I developed friendships
That was when I learned how to _________.
I devoted a lot of time but it was worth it.
I hope to work with some of those individuals again.
The product had a profound impact

I based my definition of Post Development Growth on the definition of Posttraumatic Growth. Here is the definition that I am proposing:

Post development growth: the positive changes experienced by individuals that results from enhanced new product development capabilities. Post Development Growth includes reflection to achieve cognitive clarity. It goes beyond reflection to action.
Some factors that may be used to predict the likelihood of growth depend on intrinsic characteristics (refer to the definition of posttraumatic growth) of individuals. Other factors include improved situational awareness and the potential for selecting appropriate actions.

Post Development Growth Inventory (PDGI)

The five factors that comprise the Posttraumatic Growth Inventory can be modified to correspond to new product development environments. For Post Development Growth Inventory (PDGI), my proposed list includes:

Interaction with others in a new product development network. Cooperation and collaboration. Teamwork.
New possibilities to enhance new product development capabilities. New strategies. Better orientations.
Personal mastery of specific skills. Network effectiveness
Understanding and appreciation of how your efforts contribute to project success. Appreciation of the interactions with others. Understanding how the efforts of others contribute to project success.
Autonomy – Capacity for independent action

The Post Development Growth list is similar to the factors described by Dan Pink in his book Drive: The Surprising Truth About What Motivates Us. His factors were:

Autonomy
Mastery
Purpose

The Post Development Growth list is consistent with Boyd’s list of the ingredients needed to pursue vitality and growth. He included “insight, initiative, adaptability, and harmony.” In later versions, he listed “insight, orientation, harmony, agility, and initiative.” (Boyd, Patterns, 1986, #144)

The Post Development Growth list is similar to the OpLaunch list for Development Experience (DX). That list is:

Better orientations
Pathways to proficiency
Strategies to Win

Designing for Growth

In new product development, one can go beyond surviving to thriving.
For growth to occur, one must go beyond surveys and metrics. For growth to occur, there must be activity that includes deliberative practice.

“Deliberative practice includes challenging yourself to do things that are beyond your current ability, doing the new things, analyzing the results, and correcting the mistakes.” (Hart, Developing Winners 2013)

The items of the Post Development Growth Inventory can provide a design template. Activities can be guided by consulting, coaching, and training.

For more information on thriving during new product development, visit the OpLaunch site.

End Notes

The phrases “Post Development Stress” (PDS) and “Post Development Growth” (PDG) were coined by Mark A Hart 23 April 2013.

Tedeschi RG, Calhoun LG: The Posttraumatic Growth Inventory: Measuring the Positive Legacy of Trauma. J Trauma Stress 1996, 9(3):455-71 Online at http://66.199.228.237/boundary/Childhood_trauma_and_PTSD/PosttraumaticGrowthInventory.pdf

The inspiration for this post was Chet Richards comments on Stress and Success at http://slightlyeastofnew.com/2013/04/22/stress-and-success/ Additional information at Success and Success: Fast Fixes for Turbulent Times by author Jonathan Brown at http://stressandsuccess.com

The book “Developing Winners: Assimilating the Insights Encapsulated in Boyd’s OODA Loop” by OpLaunch founder, Mark A Hart will be published in the forth quarter of 2013.

Beyond Surviving Development (12 Minutes, 18 MBytes)

Beyond Surviving New Product Development [ 11:40 ] Play Now | Play in Popup | Download

The Devastating Zero Model of New Product Development

Posted on March 28, 2013 by OpLaunch

A devastating zero model can guide your actions when deficiencies are discovered in projects. This concept may help you recover from new product development problems.

Suddenly aware

In one of my current projects, I had the impression that everything was satisfactory. The objectives were clear. We had support from the highest levels of management. It seemed that many of the individual contributors were engaged and working in a cohesive and harmonious manner, Then, I learned of one exception. There was a potential problem related to the promotional effort for the product.

In a communication with the project sponsor, I wrote that I had just learned of a potential problem and that I had requested more information.

In addition, I wrote the phrase “I am not involved with promotional efforts.”

It was then that I realized the cause of my mistake. An excuse of “not being involved” is inadequate.

When I became aware of the potential problem, my first tendency was to assign blame and demand accountability.

Fortunately, my thoughts shifted to options for recovery.

Two analysis perspectives

During my analysis, I discovered that I could improve my understanding of the situation using a mathematical model that I am proposing for new product development.

Typically, mathematical models associated with new product development projects are associated with financial results such as the return on investment (ROI) or total sales or relative growth. These types of analyses predict post-launch results.

Another type of mathematical model can be associated with development. It requires a pre-launch perspective.

Forecasting success

Prior to launch, there are many approaches to forecasting new product development success. Factors that may be used to predict success may include perceived qualities related to the following:

Initial concept
Refined concept (which is also known as a pivot)
Business model
Process
Management
Individual contributors
Competition

The perceptions impact project decisions (such as go / kill / wait), project portfolio decisions, and business development decisions.

Development equations

Consider the following simplified equations that contain factors A to Z that contribute to the project value.

Value = f[A + B + C + … + X + Y + Z]

Value = f[A x B x C x … x X x Y x Z]

Examples of factors A to Z may include the contributions from individuals assigned to roles in functional groups such as engineering, testing, marketing, advertising, promotional efforts, and commercialization.

In the first equation, the hypothesis is that the contribution from one set of individuals adds to the value created by other individuals. Efforts are additive.

In the second equation, the same factors exist but the contribution factors are multiplied.

Implications

To determine which equation might provide better insights, I asked “What are the implications when the factor associated with ‘promotional efforts’ = 0 ?”

In the first equation, there will be a minor impact on the final value. In the second equation, when the promotional efforts factor has a value of zero, the total value will be zero.

The mistake I made

I realized that our project had system-level problems. The feedback regarding the promotional efforts was inadequate because the feedback was delayed. The lack of progress on promotional efforts was not sufficiently transparent.

I was in this situation because we out-sourced promotional efforts. We out-sourced promotional efforts because of precedents from prior projects.

In the next few hours, the seriousness of the problem became clearer. The project sponsor was furious. The sponsor signaled that they were considering termination of the project.

Two definitions of product

My insight occurred when I compared two of the definitions of product.

Product (noun)

An object produced by the efforts of management and individual contributors. Typically, there is a process associated with developing a new product.
In mathematics, a product is the result obtained by multiplying two or more factors.

Suddenly, I realized an alternative meaning of product development. The alternative meaning for product development is based on the second equation.

To improve product development, evaluate the factors that contribute to the project. Some can be improved. When the magnitude associated with one factor approaches zero, the value of the entire project will approach zero. Ensure that none of the factors has a value of zero. I am calling this a devastating zero.

Improving resilience

Enhancing resilience is one approach to improve the potential for new product development project success.

Resilience: the ability to adapt so that success can be achieved in cases of expected challenges and unexpected challenges.

Resilience is a desirable quality for any project.

The resilience of my project can be improved by any the following:

Improving the appreciation for the quality of execution and teamwork necessary to achieve the objectives
Additional training for the underperforming group. Assist them in developing a perspective regarding how their efforts impact project success
Enhancing the capabilities of individual contributors to recognize situations today that will cause problems in the future
Enhance the ability to detect problems through improved observations and orientation
Improve the feedback throughout the system
Increase the transparency of the work in progress
Develop paths to recovery

Inadequate responses

When a deficiency is found, the other individual contributors should move beyond an “It is not my job” stance. All contributors should move beyond responses that include “assigning blame” or “demanding accountability.”

This simplified model predicts that a project can not be successful when one of the factors contributing to value equals zero.

To visually represent this, imagine several individual contributors in a boat. The boat has localized damage. Someone seated opposite from the damage yells “your side of the boat is sinking.”

New product development projects have system-level problems

Success Limiting Factors (SLFs)

This model builds on what I have previously described as Success Limiting Factors (SLFs). SLFs are items that impede new product development. Some SLFs have a deterministic nature. In some cases, there is a simple cause and effect relationship. In other cases, the interactions are more subtle.

In the extreme case, the project can be terminated because of perceived deficiencies in one factor.

Perception becomes reality

Before launch, all the factors tend to be qualified with words such as forecast, hypothesis, uncertainty, risk, and guess. In this context, perception influences decisions. Perception can be sufficient to terminate the project. Perception can become reality.

Developing products

I hope that the devastating zero model enables you to expand your product development repertoire. It requires that you enhance your capability to detect problems. You will benefit by expanding the way that you approach problems.

With the appropriate orientation, you will not have to relinquish success. You will be better equipped to hold on to success when a devastating zero is discovered.

The Devastating Zero Model of New Product Development [10 minutes, 9 MBytes]

The Devastating Zero Model of New Product Development [ 9:52 ] Play Now | Play in Popup | Download

Introduction to Development Experience (DX)

Posted on March 13, 2013 by OpLaunch

How does one enhance the capabilities of the individuals within the networks that develop new products? Some approach new product development (NPD) with their favorite processes and precedents (which are typically called ‘best practices’). Some tend to insist that individuals follow explicit procedures.

Another approach is to design Development Experiences (DX) to produce better outcomes. This places the focus on the contributors. Can better new products develop from this approach?

Individuals with enhanced capabilities in a new product development network are indicated by the difference in color and size. The white-colored field that surround these two individuals indicates better interactions between these contributors.

Development Experience (DX) Definitions

Development Experience (DX) is the set of perceptions and responses from a diverse set of individuals that develop a new product, system, or service. DX includes emotions, beliefs, preferences, perceptions, physical and psychological responses, behavior and accomplishments that occur before, during, and after development. Factors that influence DX include the system, the individuals, and the context of development. DX varies over the time from concept to commercialization.

Well-crafted DX capitalizes on the mixed nature of diverse disciplines entering and exiting the development effort.

DX strives to capitalize on the mixed nature of groups contributing to development and their approaches (such as Stage-Gate©, waterfall, agile, Kanban, and lean).

Efforts related to Development Experience (DX) are distinct from efforts that focus on the product or the intended user of the product.

DX affects individuals that develop new products
UX affects individuals that use the product

A portion of this definition is based on the ISO 9241-210 definition of User Experience, UX.

Development Experience Design is the design of the experiences of a diverse set of individual contributors during the development of new products. It includes factors related to the development environment such as those that impact cooperation, collaboration, cohesiveness, and harmony of anyone associated with the new product development network at any time during development. It addresses experiences related to the development of items such as the hardware, software, interfaces, purchase, installation, setup, operation, and maintenance of the new product. It spans the time from concept to commercialization.

WHO: A designer shaping the experiences of individual contributors from many disciplines. Some individual contributors are full-time-equivalents (FTEs). Some contributors participate part-time. Some contributors are involved with the project for a short time (such as a few hours or a few days).

A DX influencer is a person that has a big impact on DX because of their intrinsic approach to development.

WHAT: Designing for a better experience for participation in NPD efforts by addressing factors such as cooperation, coordination, and collaboration.

WHEN: Throughout development, concept to cash

WHERE: DX impacts individuals at multiple sites. Some individuals at a central location. Others near the central location. Others are remote.

WHY: Better outcomes, happier individual contributors, and less grief

HOW: A DX designer enhances the capabilities of individuals by providing better orientations, pathways to proficiency, and strategies to win. More than processes, tools, patterns, and templates Beyond individuals that are thought of as interchangeable resources.

A Development Experience Designer is an individual that strives to impact the perceptions and responses of a diverse set of contributors during the development of new products. A DX Designer strives to enhance the new product development capabilities of individual contributors. A DX Designer explores factors related to the development environment such as those that impact cooperation, collaboration, cohesiveness, and harmony of anyone associated with the new product development network at any time during development.

More Information

More information about Development Experience (DX) is included in the OpLaunch website.

End notes

These DX-phrases were coined by Mark A Hart in March 2013.

Parse error: syntax error, unexpected '<' in /data/59/2/21/148/2999800/user/3329880/htdocs/blog/wp-content/themes/twentyeleven/footer.php on line 18