Massively parallel thinking

The following is crazy talk, but sometimes it’s helpful to aim impossibly high to uncover the roadblocks to dramatic improvement.

Why does it take 6, 12, 18, 24 months or more to design and deliver a new product to market?  How fast could it be done if all the inefficiencies were removed?  Is there a theoretical limit to our thinking speed?  Could a new tablet, medical device, bulldozer, drug therapy, household appliance, software application, training course or consulting service be designed in a month, week or a day?  If not, what prevents it?

From my experience, the primary roadblock to dramatically accelerated design is the inability to decompose the “problem domain” into loosely-coupled, well-framed decisions that can be attacked with massively parallel thinking.  Let’s suppose that a product design requires 100 decisions to be made to the point at which all that remained were 1000 1-week implementation tasks (writing a chunk of software, fabricating a part, creating a lesson module or setting up a database) that could be done independently by a skilled practitioner when provided a firm set of requirements.  There’s no theoretical reason why those 1000 well-defined tasks couldn’t be farmed out to 1000 ready-to-work implementers and be completed “to-spec” within 1 week.  If these 1000 components were all correctly defined to fit together and correctly implemented to match their requirements, they could surely be integrated together (assembled, compiled, etc.) within a week.  If so defined and built, they would work together flawlessly, without the need for testing, failure analysis and rework.

But what about the 100 decisions?  Could they be done in a week also?  For most products, I believe so.  Over the past 20 years I have “reverse engineered” a Decision Breakdown Structure (DBS) for more than 100 products, systems or solutions.  The Decision Breakdown Structure typically contains about 100 decisions; the reverse engineering process generally has taken a few days using existing documents, including a “Decision Blitz” session with the team to confirm my understanding of their solution.  There is almost never a surprise in this process; every solution can be mapped quickly on a proven decision pattern with predictable branch points regardless of the type of product conceived or technology used.  The limiting factors in this exercise are usually:

  • Poorly structured documentation that hides rather than highlights decisions
  • Missing decisions in the documentation
  • Design by PowerPoint – lots of pretty graphics with ambiguous meaning to anyone but the author
  • Fuzzy thinking on the part of the team; no agreed-to baseline on where the product fits in their portfolio and what it must accomplish; this slows down the capture of “already-decided” decisions

But what does reverse engineering prove concerning the ability to “forward” frame a new product as a network of 100 decisions?  Quite a bit.  A comprehensive decision pattern already exists; the only unknowns are the answers to the top-level decisions that drive the name/number of branches that exist at the “fan-out” points in the structure.  Based on this experience, I’m certain that the “frame the problem domain as a Decision Breakdown Structure” step can be done in one day for most products, down to these fan-out points.

The only exception that I know that prevents “one-day framing” is if a product attempts to leverage science that is not yet understood.  If the causality cannot be explained behind material properties or scientific behaviors on which the product is based (the Operating Regime, Behaviors to Exploit, Behaviors to Control decisions in our Decision Driven® Solutions decision patterns, then technologies don’t really exist to form solution building blocks.  Science has to be there to be utilized.

Most product Decision Breakdown Structures are no more than 6 or 7 layers deep; this means that there are no more than 7 decisions in series on the “critical chain” through the DBS.  Many of these decisions can be done in an hour or two; a few may take a day or two.  On average, the critical chain through these serialized decisions works out to just 5 days, if you have:

  • A method for staffing the decisions with experienced thinkers as the model fans out
  • A proven criteria pattern for each decision so criteria definition/prioritization can be done in less than 1 hour
  • A method of maintaining continuous alignment between decisions (requirement-to-decision-to-requirement traceability)
  • Proven models for estimating the performance of alternatives with adequate precision

I believe a “4-week product development” process is theoretically possible; 20 working days from the spark of an idea to a product or service you can sell to your customers.  It breaks down into the following steps:

  • 1 day – Frame the design as a Decision Breakdown Structure (DBS) from a proven pattern
  • 5 days – Massively parallel thinking; Complete 100 design decisions that define 1000 components and their requirements
  • 5 days – Massively parallel implementation: Create 1000 solution components “to-spec” and ready-to-assemble
  • 5 days – Assemble and integrate the components into a ready-to-ship product (zero testing needed)
  • 4 days – Contingency; nobody’s perfect

20 days total design/development

I’m not naive; I know there are funding and staffing constraints, approval cycles, mandatory trials and testing, etc. that will be hard to overcome.  However, the value-creating thinking that produces the product can be dramatically compressed by better decision patterns and methods.

A 4 week development cycle sounds too good to be true, but none of the prerequisites above violate any laws of physics.  It’s really just a matter of deciding to grow the capability for 4-week product development for your organization.  Even if you only get half-way to this goal, it would transform your business and crush your competitors under a deluge of new and innovative solutions.  It starts with your first learning cycle in using a decision pattern to frame your design.  It can start today.

In order to learn more about the Decision Driven® Solutions Framework (DDSF) and the use of decisions for massively parallel thinking to accelerate your product development, we encourage you to start a DDSF trial today. Please contact the Decision Driven® Solutions team at or

About decisiondriven

Innovator in Decision Management, Systems Thinking and System Engineering methods and tools
This entry was posted in Decision Concepts, Decision Driven Innovation, Decision Driven Product Development, Decision Driven Strategy and tagged , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s