The Product Developer's Plight – And How to Overcome It

While product management is about the “WHAT”, product development is about the “HOW”. Product managers think about “What problem should be solved, for whom and why?”, while product developers find solutions to bring projects to life. This is the theory. But the reality is often different. In many cases, technical product developers do not get the input they need to develop a product that will succeed on the market. They certainly get a lot of information from other departments – wishes, ideas, requirements, and so on, but this information is not structured, prioritized, validated or detailed enough. Random input results in random success: That’s the true plight of many product developers and a source of common product development traps.

Trap 1: Starting concept development without a clear target.

Product requirements communicated by Marketing, Product Management, or Market Research are often vague, replaceable and conflicting. How will you develop a mind-blowing product when the input requirements are “easy to handle”, “multimodal” or “attractive”?

To be workable for product development, the requirements have to be formulated in a very precise and targeted manner, such as the so-called “Outcome Statements”, which are results when applying the Outcome-Driven Innovation ® (ODI) process. Outcome statements are desired outcomes, i.e. very clearly and actionable defined customer need statements. They are the metrics that customers use to evaluate success on getting a certain job or task done. An example of an outcome statement is: “Minimize the time it takes to secure a circular saw when it is not in use” or “Minimize the likelihood of damaging the gums when cleaning teeth”. In an ODI project, usually 100 – 150 outcome statements are revealed and can be grouped later on by developmental topics to facilitate processing by product development.

Trap 2: The product concept doesn’t address unmet needs.

Even if the product requirements are communicated in an actionable format, the product developer cannot be sure if it is the right type of information. If the product features do not address unmet needs, good ideas and the most stunning design would be a waste of time and effort.

In the Outcome-Driven Innovation® (ODI) process, all revealed outcome statements are quantified through a large-scale survey to identify the level of satisfaction and importance for each single outcome. The results are then related to each other in a proprietary algorithm to calculate the opportunity score. The opportunity score indicates potential for value creation or disruptive innovation: The more important the need and the less satisfied the customer is, the higher is the opportunity score.

Trap 3: The more – the better.

Trap 3 is a consequence of the preceding traps 1 and 2. By not knowing where to put the focus, product developers tend to add all kinds of features to the product. It would be wrong to call the result a “Swiss-Army-Knife” product, because the Swiss-Army-Knife has a very simple and strong value proposition – to have a hand-sized toolkit that you can count on wherever you are. Adding more features than necessary to a product dilutes a clear positioning, makes it more difficult to communicate product benefits, and creates additional costs. Focus, in contrast, delivers a clear customer value: Research revealed that 62% of consumers will pay more for a simpler experience.

Outcome-based segmentation can help us out of this trap. The outcome-based segmentation analysis in the ODI process provides a new and more effective segmentation typology based on true customer needs. It creates segments that have internally coherent need structures and are strictly separated from each other. This makes it easier for product developers to create offerings that deliver just what the segment cherishes – but not more.

Trap 4: Method-Clinging.

Knowing that the product development process has to be improved, many product developers hope to find the saving solution in a specific method like Design Thinking, Agile Development or Lead User Methodology. They believe that if they follow the instructions of the method well enough, success will come by itself. The result, however, often looks different. The reason is that most of these methods weren’t designed to guide the entire product development process. They work perfectly in the concept development and testing phase – but they cannot be better than the input they are fed with.

The early stages of the product development process should be characterized by needs alone. The development team have to gain a deep understanding of what needs exist in a market, and what needs are underserved, to which degree and to what type of customer. This facilitates the design stage of the product tremendously and eliminates the need for correction loops and inefficiencies. Outcome-Driven Innovation ® is a strategy and innovation process that guides the complete product development – from needs assessment to market launch. It is perfectly compatible with and can incorporate methodologies that were designed for specific phases in the development process like Design Thinking, Agile Development or Lead User Methodology.

So, what can you as a product developer actually do to improve your situation? First, work closely together with upstream departments and try to convince them to provide you with the information you need to create products and services that customers will love. If that doesn’t work out, do the homework by yourself. We can help you out. Just call us and together we can think about how Outcome-Driven Innovation® can improve the product development process in your market. Our Mayer & Co Beschläge Case Study might be also a good example for you how a product development process can be supported with ODI.