The following is crazy talk, but sometimes it’s helpful to aim impossibly high to uncover the roadblocks to dramatic improvement.
Why does it 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 PDA, 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, setting up a database) that could be done independently by a skilled practicioner 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 Network model for more than 100 products, systems or solutions. These Decision Networks typically contain 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 model. Based on this experience, I’m certain that the “frame the problem domain as a Decision Network” 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 the Decision Driven® Strategy pattern), then technologies don’t really exist to form solution building blocks. Science has to be there to be utilized.
Most product Decision Networks 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 Decision Network. 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 Network 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.
Please sign up for our next Using Decision Patterns webinar. It’s free! See the What’s Happening panel on the left for details.
Filed under: Decision Concepts, Decision Driven Strategy | Tagged: decision, decision network, thinking breakdown structure, thinking, speed, time to market, product development, accelerate, value-added, problem domain, massively parallel, process improvement, decision blitz