The importance of the definition phase in product development

High-quality hardware design: how do you realize it? In this first part of the blog series, we focus on the initial phase: the definition phase. A phase that has a lot of influence further down the development process. Unfortunately, this phase is sometimes completed too quickly. You will discover the challenges, best practices and requirements for a successful completion of the definition phase.

The pros and cons of a speedy development process

Developing a new product requires a lot of time, attention and therefore money. In addition, the process has uncertainties and risks. It is therefore not surprising that companies and entrepreneurs look for opportunities to keep a development process as short as possible. They are driven by a desire to reduce costs or to achieve an ambitious time to market. In addition, it is desirable to go to the market as soon as possible with a working product. In this way, the market can be validated with an MVP (Minimum Viable Product).

The ambition to save time and costs is a logical one. But an overemphasis on this in the initial phase of a development project can lead to undesirable risks. There is a risk that steps will be skipped during the initial phase in a development process. This has consequences later in the development process that will result in higher costs and longer lead times. That is why it is crucial, especially when the lead time is important, to carry out a good and complete definition phase.

The purpose of the definition phase

In the definition phase, ideas and concepts from people with customer and market knowledge are transferred to people with technical knowledge. The goal is to translate these ideas and concepts in such a way that a successful product can be made.  If this phase is carried out successfully, you will reap the benefits later: the follow-up phases can be carried out at pace and the chance of costly delays is greatly reduced. But how do you successfully go through this phase?

With these 4 tips you ensure a good definition phase and you give your development project a great chance of success!

  1. 1. Take your time to go fast
  2. 2. Make it communicable
  3. 3. Making ideas and concepts concrete and validable
  4. 4. Collaborate

Take your time to go fast

The principle 'take your time to go fast' should be the mantra during the definition phase. This requires a project manager who stands firmly in his or her shoes. A good project manager takes the client on the journey and resists the pressure to skip steps. On the other hand, the project manager needs to motivate the team members involved to ask difficult questions and to examine sufficient level of detail. Both the market and customer-facing stakeholders as well as engineers can tend to make assumptions ("Isn't it clear?" / "I understand what you mean") and skip details. In addition, these team members can be influenced, often by the client, by pressure on time and budget. A good project manager realizes that his or her task is to deliver a successful product and not to complete a phase as quickly as possible.

Make it communicable

The definition phase is largely about making the product idea and the requirements and wishes communicable. In this phase, thoughts and ideas are transferred from one group of people to another group of people. The information needs to stick and can be consulted during the project. The thoughts and ideas must be well understood and lived through. This requires creative sessions and workshops in which marketing, sales, service engineers etc, and the development engineers are present.

In addition, it is important that the output is documented in a concrete and structured manner. A good product definition consists of:

  • A clear description of the context of the product,
  • Use cases, and
  • A list of testable requirements, preferably with a prioritization.

Making ideas and concepts concrete and verifiable

To make the product idea communicable and understandable, it needs to be specified as concretely as possible. Only if this is done properly will engineers be able to design what is expected. This elaboration consists at least of the context, use cases and requirements.


The context describes the story of the product and the broader concept; why it is a good product and what value it offers to the users. In addition, an explanation of the business model is valuable to understand how money will be earned with the product. Finally, it is important to describe the broader environment in which the product must work.

Use cases

Use cases are descriptions of scenarios how a user interacts with the product. Defining use cases is a good way to think about the different scenarios that are possible and how to deal with them. It forces the product owner to describe the interaction with the users in detail.  Use cases provide a lot of context in which and how a product is used. This is indispensable when designing the system behavior, especially if there is human interaction (think human machine interface (HMI)) involved.


Subsequently, the functional and non-functional requirements need to be specified (requirements). Functional requirements say something about what the product must functionally do, and non-functional requirements specify what other aspects the product should meet. Properly recording requirements is absolutely necessary. And these requirements must be of good quality. It is a pitfall to want to specify 'everything': that is an unattainable goal. The quality of the requirements is more important. With good requirements, engineers will create a design that meets expectations. Based on good requirements, it is also possible to demonstrate that the design meets the requirements (verification).

Good requirements meet at least the following points:

  • There is never a solution in a requirement. It says what the product should do or what it should comply with, never how it should do it.
  • Requirements are not ambiguous. In other words, they are concrete and specific. Avoid possibilities for interpretation and assumptions in the requirement. Implicit assumptions are a major source of project failure!
  • For each requirement, it should be recorded how this requirement will be tested (verified). An additional advantage of recording a test per requirement is that it prevents possible assumptions about the requirement. So the requirement becomes even more concrete.
  • A requirement is one requirement. If there are two in one sentence, make it two requirements.

Capturing good requirements is not an easy task and it requires the attention of both product owners and engineers. There are a number of pitfalls and misconceptions when it comes to requirements, such as:

  • Product owners sometimes think too much in terms of solutions, rather than requirements. This does not result in good requirements and limits the creativity of engineers.
  • Requirements are sometimes approached as static and unalterable. This approach makes capturing requirements even more difficult, if not impossible. The same applies if requirements are the basis for commercial agreements. Requirements can change during the project, as long as this is done through a good change procedure.


The last tip: work together! This sounds obvious, but in practice it turns out not to be. Strong collaboration has a major influence on the success of the definition phase and therefore the success of the entire project. A development project often involves people with different backgrounds and expertise. Especially in the definition phase, these people will have to work well together. After all, the goal is to transfer the information from the market- and customer-oriented stakeholders to the engineering team.

The differences in background, expertise and experience also means that those involved look at the world in different ways. This is the strength of the multidisciplinary team, but also the danger because it makes communication difficult. In order for good collaboration during the definition phase to be possible, there must be a clear common goal and a high level of trust within the team. This applies to teams composed of different departments within a company, but certainly also to teams in which a customer-supplier relationship exists. In the latter case, it is important that this relationship does not stand in the way of cooperation. Here too, it is the task of the project manager to achieve good cooperation in the team. 

In short, a well-thought-out definition is the foundation for a successful product. This is a major responsibility for the project manager, and off course of the entire team!

In the second part of this blog series, we will take a closer look at the process and the do's and don'ts during the hardware development process.

Read our other blogs
Expand your knowledge