Accelerating new product development

There’s no quick fix for accelerating the development of a new product.  That’s because your organization has a baseline (existing, current) capability for product development that is comprised of a mix of existing solutions, people, process/methods, tools and knowledge assets.  If you haven’t been investing in your new product development (NPD) capability roadmap then there is no magic accelerator pedal to mash on when you want to speed up a specific project.

Which NPD capability investments can yield the greatest payoff in reducing time to market?

Capability #1: Control requirements volatility with decision baselines

Nail down the product’s requirements baseline. The fastest and best way to stabilize requirements is to understand the upstream customer and business decisions that created these requirements (all requirements are derived requirements!).  If you have a set of proven decision patterns, you can quickly reverse engineer these decisions and build an explicit decision-to-requirements trace.  You can use this trace to confirm the requirements derivation with the customer, identify fuzzy or open decisions that could lead to requirements volatility and work through these decisions with your customer early in the project.  This can dramatically reduce the flow and severity of requirements changes and save much time by preventing engineering rework.  See my August 25, 2008 post for more on this capability.

Capability #2: Platform engineering

You most likely have a portfolio of existing products and solutions that can deliver 20, 50 or 80% of the functionality required for a new product that you have in mind.  Your teams may do a pretty good job of incidental reuse of hardware and software components, documents or models based on a “been there, done that” approach.  However, that’s a far cry from the speed you can gain from architecting a highly configurable, scalable platform comprised of designed-for-reuse assets.  A well-designed platform doesn’t just document the structure, behavior, requirements, interfaces and configuration options associated with each asset; it also documents the decision rationale behind the platform design.  This allows a product team to quickly revisit the decisions behind the platform, confirm that their product concept fits within its scalability limits and identify the specific functions that are beyond the scope or performance reach of the platform.  This focuses the team on the “vital few” open decisions that must be made on the project, typically “Choose Technology for Function X” decisions.  See my June 11, 2008 post for more on this capability.

Capability #3: Never make a decision from scratch

Decision patterns are the key to both capabilities describe above.  These same decision patterns can be used to enable massively-parallel, aligned and efficient thinking when forward engineering the product.  Team members save time when their decisions are visible and consistently well-framed as “fundamental questions/issues that demand an answer/solution”.  A decision pattern includes the typical criteria that should be considered for each type of decision; this saves time in defining and prioritizing the attributes of a successful solution and reduces the chance of missing or redundant factors that skew that decision analysis.  The criteria create a knowledge pull that highlights important unknowns that need to be known before a decision can be made with confidence.  Team members gain learning cycles by using the same decision-making process across multiple decisions; they become faster, more innovative and confident thinkers.  Higher quality decisions reduce downstream rework.

I created the Decision Driven® Solutions Framework (DDSF) to bring the power of decision patterns to new product development.  If this sound intriguing, please contact the Decision Driven® Solutions team at or to begin your DDSF trial today.

About decisiondriven

Innovator in Decision Management, Systems Thinking and System Engineering methods and tools
This entry was posted in Decision Concepts, Decision Driven Product Development 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