The Product Development Process and the Essential Product Investigation Phase Gate

Almost all engineering-oriented companies have a product development processes with phase gates.  These phases generally include, at least, investigation, development, alpha-testing, beta-testing, production, and obsolescence.  Each company generally customizes the process in their way since efficiently realizing products is about as fundamental as it gets in business. Today we talk about the product investigation phase gate.

In this essay I want to address the phase gate between investigation (or research) and development.  What is the essential investigation phase gate?  It starts and ends with business.  Every phase gate has a business reason.  The fundamental question at the investigation-exit phase gate is: do we have a product worth developing from a business standpoint?  Because we don’t know the answer to this question before the exit of the investigation phase and because we are supposed to know the answer as we begin development, this phase gate exit also generally gates the release of major funding.  This is why before the investigation phase exit, the team should be small and funding modest relative to the size of the division.  This is simply prudent business.   By the way, some investigations should recommend not going on with the product (without penalizing the investigation participants).  If one were to pass every investigation phase exit, then that would be a sign that one is being too conservative.

Given that the investigation phase’s essence is about knowing that we have a product that makes business sense, several other points follow.  From a marketing standpoint, we need to know that the product solves a real customer problem.  You have heard the idiom, “no pain, no gain.”  If there is no customer pain then there will be no commercial gain for us. Not only does the product need to solve the problem, but there must be a known business model wherein we get paid enough to meet our business objectives.  To get paid enough, we typically need to have a differentiated product with a sustainable competitive advantage in a large market.  Companies do well in businesses were they can create useful differentiation in the eyes of the customer.  From this it follows that we need to have done a red team (competitive) analysis to understand the competitive landscape.  We also need a new idea or unique solution.  Again, it all goes back to the business question.

Our CEO had six questions he traditionally asked at an investigation phase checkpoint review, 

• Does the technology work?
• How much risk is involved?
• Will it win against the competition?
• Is it where the company should be?
• What is the expected market size?
• What is the expected return on investment?

From an engineering perspective, there are several points to make.  First, in order to be able to predict the return on investment you need to be able to predict schedule and cost.  If there are still unsolved science and technology issues, then you cannot predict the schedule or cost.  Therefore you cannot predict the return.  One of the biggest mistakes people typically make is launching into product development with technology landmines still in front of them.  Conversely, you should not be working on the graphic user interface (GUI) and safety interlocks if you don’t know for sure that the differentiated technology actually works (unless, of course, the GUI is the differentiation).  If you want to have short predictable schedules you must have done the technology development before you start engineering.  Technology development risks are typically either component risks or risks in meeting the systems specification given all of the tolerance uncertainties in the components.  Let me say it again.  In order to pass an investigation phase checkpoint, you have to have reduced the engineering project to one you can characterize as “turning the crank,” (though it could be a very big crank) with no leaps of faith or miracles required.  The domain experts should have high confidence that they can solve all of the remaining problems on a predictable schedule.  And as projects get bigger, the demand for the science and technology to be done before you start the development phase becomes more and more critical.  Countless projects have gotten in trouble because they felt that they had time-to-market “constraints” and therefore launched into high burn rate engineering efforts before the science was done.  In these cases you will often hear the following code words, “We need to assume success.” “This is the schedule if everything goes right.”  “If we don’t do <fill in the blank engineering> in parallel we won’t make the market window.”  

From the standpoint of any specific project, it makes sense to spend as much as possible to potentially speed the product to market.  Any net present value analysis will show that being slightly earlier to market is worth a lot.  So why not accelerate the program by spending more in the investigation phase on non-essentials?  The answer is that we have to look at it from a portfolio perspective.  If we were to spend more than suggested here on investigation phase work, then we would have to do fewer investigations (there is no more money) and thus have fewer products.  It is the opportunity cost that makes the strategy discussed here more desirable.  

What about all of the other things that need to go into an investigation phase?  As time goes on there is a tendency to demand more and more issues be crammed into this phase, such as service costs, reliability models, cost models, etc.  Which are essential and which are not?  The simple answer is that it all goes back to the business case.  After the investigation phase we are saying that we are convinced that we have a winning product and that it is time to spend money, perhaps a lot of money, implementing.  Thus if the business case requires that the raw parts cost be less than $350,000, or $3.50, to achieve an acceptable return on investment, then you have to have proven that, if you turn the crank, you can get this with high confidence.  If, for competitive or use-case reasons, you need a MTBF (mean time between failure) of 1500 hours and a service cost of less than $150 per year then you must have high confidence that you can do that.  One other area that often gets neglected or given short shrift is the supply chain. As technology is advancing so fast, it is easy for Engineering to have identified an enabling technology for a new product. If there isn’t due diligence done by a cross functional team to understand the business risks of utilizing a sole source supplier without putting in place the appropriate safeguards, then the whole project is at risk. All of these risks; technical, market, supply chain, etc., need to be critically understood and mitigated to the appropriate level before proceeding.   

In essence, passing an investigation phase checkpoint means that you can now deterministically meet the specifications needed to make the business case work.  No less.  And no more.

Why no more?  Because sometimes people put too much time into getting to the end of the investigation phase.  Before a bunch of time is spent on the details of the project management (as opposed to the details of the technology), management wants a chance to review the plan.   We can know that it is possible to deterministically develop a winning product without yet knowing the details of the schedule, cost, etc.  This needs to be done quickly after the investigation phase and, of course, the details impact funding decisions.  

And another point.  You do have to hold the checkpoint review and get the signatures.  Peer review and management oversight are critical to risk management, which is in turn critical to business, especially in a public company.  In the end, it is always a business judgment.  Pretend you are the CEO.  What is best for the total business?