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:

“For a cross-discipline team th[...]