“We had asked sales, sent questionnaires to our customers, asked development for technical ideas, and had a few of our own ideas. This resulted in a long, long list. We had a hard time prioritizing because everything seemed equally important to us. Besides, it’s often the little things that make the decisive product success – you never know that beforehand! Then we had long and annoying discussions with the development team. We had the impression they were finding fault with everything and weren’t really excited about our challenge!”

After 3 years, they showed us THEIR result. After such a long time, the requirements had changed, the product was a flop. This is no fun!”

Before we can define the requirements for a specific product, we need strategic guidelines. Years ago, Stihl had the strategic orientation: We do not sell in DIY stores, only in specialized retail! This provided clarity for the company at that time.

The corporate strategy with mission, vision, and strategic guidelines is especially valuable when it helps to determine what should NOT be done. Strategy is the art of sacrifice! It forms the basis for the market strategy with target industries and industry segments and a clear competitive positioning. The technology strategy feeds new opportunities. From these 3 documents, the product portfolio strategy is derived. When this framework exists, the requirements document can be logically derived from it.

What do we expect when we ask customers about their wishes? Can a customer know what is technologically possible? Requirements that a customer can formulate often refer to the existing product portfolio and are essentially a complaint about expected but not yet fulfilled functions. This way, we repair the past but do not shape the future!

The sports shoe manufacturer ON has shown: Even in highly competitive and saturated markets, newcomers can take significant market share from established competitors.

With the CPM method, we analyze and observe customers and users so systematically that solutions arise that surprise customers and force competitors to imitate – a double advantage!

A good requirements document is above all one thing – it is short, concise, and to the point. Complexity comes naturally! The brilliant abilities of a successful entrepreneur lie in clarity. Metaphors help with this, using comparisons from nature or other environments. This helps the developer to regularly surface from the world of technical details with a multitude of possibilities and restrictions.

When a requirements document is misused to dictate technical development, to control R&D rather than guide it, then product management has not fulfilled its role. Technical specifications that describe the implementation path, the ” HOW “, have no place in this document!

A good requirements document describes a target state from the perspective of a happy customer. There are various alternatives for the technical solution, and often many roads lead to Rome.

1. Current State Analysis.
– First, we want to understand your current situation.

2. Self-Assessment-Workshop.
– In the self-assessment workshop, we will show you best practices.

3. Action Plan.
– Based on this, you assess your need for action.

4. Improvement Potential.
– We estimate the quantitative improvement potential.

5. Vision.
– Together, we define a vision.

6. Implementation Plan.
– We establish an implementation plan.

The R&D Performance Self-Assessment.

In a 3-hour workshop with the R&D leadership team, you will learn about our methodology:

Part 1: Self-assessment of R&D EBIT cost potentials.

Part 2: Maturity level of the organization across 5 levers.

Part 3: Result interpretation.

By narrowing down through scenarios, it quickly becomes clear whether an initiative is worthwhile.