pmNERDS Community: Login

  • Innovation_e_Publication
  • Integrated_PM_Feedback_Blog
  • Job_Board
  • pmNERDS_Center_of_Excelence
  • Research_and_Development_Journal
  • Community_Blog
A+ A A-

Problem Validation and Verification

If problems that are addressed by projects are validated and verified, then development investment decisions are made more wisely, but the problems may not be the right ones unless you understand the voice of the customer.

 

You have done a good job defining the problem or project idea that your project will address, taking care to avoid hinting at arbitrary premature solutions, so as to allow plenty of room for design creativity. You have wisely used a standard format in which to state the problem and the benefits for solving it, so that the keepers of resources will be more willing to allocate them to your project, compared to other projects that are vying for their attention. So far so good.

Now it’s time to try to strengthen your theory in order to prove that solving this problem or meeting this need, is really deserving of more investment. "Validating" the problem will either, give you more reason to keep going, or cause you to rethink your understanding of the problem. Likewise, when you have completed your project, “verifying” that the problem was addressed, will confirm that the investment was a wise one.

Validation and verification are not the same processes as functional analysis techniques, which help explain HOW buyers do or would interact with the process/product. That kind of analysis converts the already validated buyer needs, and expectations into features and requirements, that drive engineering of that value into the final product.

No, it will take a bit of work to confirm that you have accurately defined and addressed the problem. And the best way to do that is to check with your buyers. But how would you go about that? One approach is to borrow from the methods usually associated with the “voice of the customer.”

Plan for Capturing VOC

First, decide who are your target customers. No one buyer can speak for all buyers. So, you should consider various types of buyers, such as current customers, customers of competing products, potential customers, and avid or lead customers who know the product well.

Next, have product / service developers participate in capturing customer data alongside traditionally assigned marketing types and analysts. This will provide better visibility for the engineers who must make development decisions.

Lastly, be choosy about the data you capture. Some kinds of data are not suited to guiding the development effort, and some are. Also consider your ability to organize the information captured into meaningful expressions of buyer needs.

Pay Now or Pay (Much More) Later

Studies have shown that up to 80% of the total cost of a product or service is taken up by the ideation and conversion phases of development. Taking the time to validate that you have the defined the problem correctly, allows early course correction, during the time when the cost to impact relationship is much, much lower than later on, when design changes are accomplished only at high costs. Those changes include rework, warranty claims, and even buyer dissatisfaction. More importantly, problem validation and verification will reduce the chances that you develop products that buyers do not like now and in the future.

Problem Vetting & Levels of Innovation
Problem Definition Formats
 

Comments

No comments made yet. Be the first to submit a comment
Already Registered? Login Here
Guest
Tuesday, 21 November 2017
If you'd like to register, please fill in the username, password and name fields.