According to Dr. Robert Cooper, (Winning at New Products) a recognized thought leader in new product development, identified that only 11% of product development failures are for technical reasons associated with the performance of the product itself.
The predominant causes of new product failure are marketing or market-related reasons including the development of products the customer did not want and the development of “me too” products.
“Me-too” products and “solutions-looking-for-problems” are a result of not fully understanding the customer’s problem set. Too many assumptions are made in the definition phase resulting in inadequate product requirements based on opinions, not market realities.
Without clear and relevant requirements, new product development is doomed to failure
All too often, development teams march forward without a clear understanding of customer requirements (what customers need and desire) thinking they know what’s best for the customer.
Or perhaps the development team thinks it’s getting the right data by asking customers what they want. But customers may be too close to “just getting their jobs done today” the way they always have done it. Thus they are unable or unaware of how to imagine, let alone articulate, new approaches to get their important jobs done better.
Defining requirements takes upfront effort, resources and know-how
There are several reasons why development teams don’t invest enough time to understand the customer’s problem set up front. Some development teams have been successful in the past by using their own instincts and assumptions of what the market wants. They believe “what worked in the past will work in the future.”
Sometimes this works, especially in the hyper growth stage of a technology adoption curve (i.e., inside the tornado) where customers will accept less than perfect solutions to keep pace with the new paradigm (enabled by a new technology/process/biz model) as to not to be left behind.
Or when technology is evolving along clear and predictable performance vectors that customers value. What Clayton Christensen calls “sustainable innovation.” (The Innovator’s Solution) But tornadoes are rare, and customers have gotten a lot more sophisticated when it comes to adopting new technologies. And eventually performance vectors overshoot the market (i.e. increasing performance provides diminished returns).
Just get the product out there and iterate to success
Some developers believe time is better served by just getting a product out there and learning quickly. Again this approach can work, and in some industries like software, a build, test and iterate approach provides a path to co-develop solutions with the customer.
The philosophy of iterative methods is to create a “minimal viable product” as fast as possible and work with existing customers to identify and validate an expanded set of requirements as you go. Iterative approaches work because they build on real requirements defined by the customer and are tested and validated throughout the development process.
But successful iterative development methods work more effectively and efficiently when essential requirements are understood upfront before a development cycle begins. Without clear direction and requirements, companies can spend lots of resources and time chasing phantom problems resulting in “solutions-looking-for problems.”
A reliable innovation framework and common language is lacking
I believe main reason why companies don’t invest time up front in uncovering and defining requirements is that they don’t know how to. They don’t have a repeatable and reliable front end process that allows them to gain deep insights into the customer’s problem set, and a method to translate these insights into relevant requirements they can innovate around.
Many companies also confuse specifications with requirements. They assume too early in the discovery and design process that they have “the” solution for “the” problem under investigation and jump into creating specifications. Instead, they end up with solutions based on prior knowledge that no longer provides a differentiated solution but rather a “me-too” product that forces a company to compete in a “red ocean.”
Thinking about the problem and designing solutions from the customer’s perspective
Using the J2BD marketing lens, we know that people execute jobs to get “things done.” And they hire products and services to get their jobs done. We also know that people do these jobs to achieve specific outcomes, the reasons they embark on executing a job in the first place. And they execute their jobs under specific circumstances that affects their ability to achieve 100% satisfaction in getting their jobs done.
It is up to us as developers to understand what important jobs customers are trying to get done. Our target customers are the experts in executing their current jobs. Customers may or may not know “how” to get their jobs done better, but they will know why they are doing the jobs in the first place, and what desired outcomes they are trying to achieve by doing the jobs.
The jobs-to-be-done innovation framework provides a clear understanding of the problems people face, their circumstance and challenges in executing the job, and how people define success in their terms.
By exploring and answering the following questions, the development team will have the right set of market insights to develop clear and relevant requirements:
What jobs are people trying to get done and why?
Under what circumstances and constraints to they face in getting these jobs done?
How satisfied are they with the results they are getting?
Bottom line
The jobs-to-be-done innovation framework provides you a repeatable and predictable method to discover problems worth solving and defining the right set of product requirements to innovate around. So instead of guessing and hoping you get the right functionality for a problem you think customers have and want solved, discover what important jobs they need to get done, how they define success by expressing their desired outcomes, and what prevents them from achieving 100% satisfaction.
Kevin
Comentários