The Fundamental Approach to Effective Product Creation: A Comprehensive Explanation

Have you ever wondered if there’s a secret sauce behind all successful and effective product creation projects?

Well, guess what? There is, and I’m about to explain it right here in this article. Feel free to absorb this information and apply it to your own projects.

It is the sequence of:

1. Definition
2. Creation
3. Validation
4. Implementation

Countless theories and methods exist in product development. No matter which one you choose, in each, you will find this common approach, either implicitly or explicitly.

It serves as the nucleus of effective project management.

It enables the efficient execution of projects and the achievement of goals with minimal costs and resources.

Moreover, the underlying philosophy also applies generally to all phases of product development.

In this article, I will detail these four steps. They form a foundation upon which I can repeatedly refer in subsequent articles.

The Product Creation Workflow — DCVI

Product creation needs to follow a methodical approach to ensure effectiveness, efficiency and success.

In many ways, product development is like creating a work of art. It requires not only creativity, skill, and inspiration, but also a methodical approach and meticulous craftsmanship.

I see this methodical approach as a product creation workflow that is part of every project manager’s toolkit. It serves as the backbone of both, traditional waterfall projects and agile development.

It works at a high level, covering the entire development, and at the level of subtasks or project iterations. Often, it is broken down into smaller blocks or represented by milestones or agile artifacts. That’s why you have to look carefully to recognize the pattern.

Adhering to this methodology enhances project efficiency, expedites timelines, and elevates the product’s quality.

Yet, in practical application, I’ve frequently encountered instances where the sequence was disrupted or steps were inadequately executed. The result was a bumpy, problematic project.

To mitigate such risks, I advocate for an intensely focused and comprehensive approach to each stage, progressing to the subsequent phase only when the output of the preceding one meets rigorous quality standards.

Let’s take a look at all 4 steps in detail.

---

At the outset of each development activity, it’s crucial to establish and agree upon the goals for every aspect of the activity.

I’m totally in love with the old saying:

Make a plan and stick to it.

I view an activity without a plan not as a project, but as an adventure.

Adventures are characterized by being risky, the appearance of surprises, and unknown outcomes. However, in the context of product creation projects, we seek the antithesis of adventure. Here, security, calculated risks, and predictable outcomes are desperately desired.

For this reason, we need to plan.

But plans can also lead to bureaucracy and inefficiency. If too much attention is paid to planning and too little to the execution of the plan, then we have an implementation problem.

Let us have a look at what aspects need to be planned.

Defining The Requirements

Requirements describe which demands a product or a system has to fulfill. The purpose of every product creation project is a change in a selected set of requirements.

Defining requirements can be difficult and often tends to be missed or cut short. It can be perceived as cumbersome or bureaucratic, and people tend to prioritize immediate execution in order to meet deadlines.

However, this backfires. It leads to development loops and duplication of work, which ultimately causes stress, inefficiency, and delays in the course of the activity. In the worst case, this can even lead to the failure of the project.

Why do I sometimes say “activity”?

Now, in an agile project, the final result of the overall project is not defined and therefore a requirements analysis at the project level can be difficult. Nevertheless, the requirements analysis must be run through for each iteration. That is why “activity” is synonymous with project or project iteration.

So what exactly needs to be done?

Because products and organizations are becoming increasingly complex, managing the requirements for each development scope requires know-how, effort, and special tools. Every product development project needs to foresee time and resources for this task.

A clear understanding of each participant’s role in contributing to the overall product function is essential to ensure the delivery of a successful product with the desired properties by the project’s conclusion.

In the first step, all requirements for the product to be developed need to be collected and documented. This includes not only the customer requirements, but also requirements for serviceability, manufacturability, sustainability, modularity, and cost efficiency.

After establishing the overall requirements, the product needs to be broken down into development scopes to create a well-organized work structure.

The product must be viewed as a system comprised of subsystems, modules, components, and parts. This structure needs to be defined and performance targets have to be broken down to every level.

Next, each development scope must be assigned to a responsible individual or group to take ownership.

Various tools are available to support this procedure.

The functional dependencies between all systems and components must be analyzed and input and output parameters at the interfaces of the systems and components must be defined and integrated. At the same time, the performance contribution of every development scope needs to be assigned and agreed on with the responsible project members.

As these values depend heavily on the design of the subsystems, modules, components, and parts, the result of this first iteration of the requirements definition must be reviewed and adjusted during the project. However, the basic structure of the requirements and the initial values must be defined right at the start of development.

In software development, it is not possible to use hardware elements such as components and parts as the basis for the product structure. In this case, a software architecture is defined in which the software is broken down into software components.

Here too, the interfaces and functionalities of each software component must be defined in great detail.

Requirements can be derived from features. Features are customer-experienced functions that can also be used to organize and structure development.

What I’ve just outlined briefly is a distinct specialized field known as “systems engineering”, which undoubtedly warrants deeper exploration.

Defining The Development Scope

With a comprehensive understandig of the requirements, the general product concept and the development scope need to be worked out.

Now, the targets are known and transparent, but we still don’t know what it takes to fulfill them.

It’s necessary to outline the product’s general appearance and determine which systems, subsystems, components, and parts will be impacted by this development effort, as well as the degree of impact. We must decide if it constitutes a minor modification or an entirely new design.

Therefore a concept study is required.

This concept is still very superficial and not very concrete at this stage. It needs to be just detailed enough to provide orientation and enable planning of the necessary resources and work packages.

However, it must also be secure enough that it can be maintained throughout the project. Otherwise, there is a risk of expensive and time-critical project loops.

Defining The Work Plan

The work tasks and the required resources must be identified, documented and communicated to ensure that all prerequisites are available at the required point in time.

There are two fundamentally different approaches to planning. Project planning according to the waterfall principle and the agile project philosophy.

I will briefly address both, as they are both relevant.

Gantt Chart.

The waterfall approach uses Gantt Charts to display the project plan.

A Gantt Chart lists the work activities, each assigned a line indicating the start time and duration, along with the responsible team member or project role. Dependencies among the activities are shown through links between the lines.

Critical project dates are represented by milestones. Quality gates define consolidation points at which the project status is assessed and a decision is made on how to proceed.

The strength of this planning method lies in the display of dependencies between the tasks. It is therefore particularly suitable for major critical activities that extend over long periods and whose sequence is critical for achieving the project objectives.

These plans are very high-maintenance. Their shortcoming is the lack of transparency in the status of task completion.

Delays in individual tasks lead to a rescheduling of the entire project plan. It forces us to deal with the consequences of schedule deviations in detail. The resources needed for rescheduling a project are often taken from the substantive work, which can lead to increased inefficiency during already stressful times.

The chain of activities that determine the project timeline is referred to as the “critical path”. Having this critical path transparent is a big help for the project manager.

Agile Board

The agile dashboard borrows its structure from the Kanban board.

The tasks are documented in a backlog that includes all essential tasks. The required resources and the associated effort are evaluated and made transparent.

According to a defined priority, the tasks are dragged into the “in progress” and “completed” columns.

The strength of this planning method lies in the high transparency of the processing status of the tasks. It is therefore suitable for short-cycle control of progress.

It fosters the alignment and collaboration of the project members, especially if the goals of every activity are explicitly negotiated, based on a pull- principle.

Tasks may be added or modified in response to the project’s progression.

The primary drawback is the opacity regarding the interdependencies among tasks and the unpredictability of the overall timeline.

Although it is very hands-on and promotes efficient work, it cannot predict the duration of a sequence of activities, and thus, it also cannot forecast the completion time of large projects.

Multilevel Plan

I have worked on large, long-term, and complex product development projects, usually managed using the Gantt chart method.

This brought me to the understanding that using both techniques in combination can be beneficial.

The Gantt chart provides an overview of the overall project schedule, especially for the critical path, while the agile board is excellent for managing short-term activities and results.

Acceptance Criteria and Definitions of Done

Effective planning involves not just allocating time and resources but also defining the desired outcomes.

For task management, it’s crucial that all employees involved have a clear understanding of what is required at a given time to maintain a seamless workflow without expending unnecessary effort.

Coordinating plans collectively enhances the efficiency of collaboration and prevents delays by ensuring that the correct results and information are accessible when needed.

Avoiding iterative loops during the later stages of validation is crucial, as they can drastically affect the overall project schedule.

It is therefore essential that the design specifications and the acceptance criteria for validation are aligned right at the start of the project.

This increases the probability that the tests will be passed at the first attempt.

This may sound trivial, but unfortunately, it is not. I have often observed that test engineers only think about the acceptance criteria once the design has already been completed and the test samples have already been procured. In such a case, it can happen that the design criteria do not correspond to the test criteria and therefore the test goes wrong and the design has to be revised or the test has to be repeated using different acceptance criteria. Both is not desirable, as it consumes additional time an ressources.

---

In the creation phase, objectives are transformed into a product.

The specified tasks are being carried out, consequently shaping the product. This is the time for creativity and a very intense and well-organized collaboration of all project members.

This phase is about unleashing the creativity, experience, and expertise of numerous employees and business partners.

But it is also about using technologies that make the design and development of highly complex products possible in the first place. The abbreviations CAD (Computer Aided Design) and CAE (Computer Aided Engineering) cover a wide range of highly sophisticated IT tools, that need to be used during this phase.

Finally, collaboration among individuals is also essential for securing successful outcomes.

This is when the magic happens in software development. This is the time for serious programming.

It would go far beyond the scope of this article to cover all the tools and processes used in the creation phase. I would therefore like to focus on just 3 key aspects of the process during the creative phase

Now is the time when the responsibilities assigned in the definition phase come into play. It is time for individuals to assume accountability for overseeing the process and ensuring that necessary product decisions are made.

Here, too, we are dealing with a repetitive structured loop of three consecutive steps.

Individual Work

Individual work allows for focused dedication, leading to the efficient generation of initial results.

For humans, we call the processing of information “thinking”.

Yes, even in the age of artificial intelligence and enormous computer power, using the human brain is anything but old-fashioned. On the other hand, IT technology offers enormous potential for modeling, simulation, and visualization of the future product.

However, these activities still require time, the appropriate resources, and a suitable working environment. All of this must be carefully planned and provided.

It requires considerable discipline to enter this mode of work, but once you do, you will appreciate the focus and flow that can arise.

The importance of this working style for the overall efficiency of the project cannot be overestimated.

It’s concerning to see that this aspect of the work receives insufficient attention due to the extensive time spent in meetings and reviews. Trust me, meticulous individual work can significantly enhance the quality and efficiency of both the product and the project.

Team Work

Complex products require interdisciplinary collaboration within an team environment.

After the individual work has produced preliminary outcomes, it is time to apply swarm intelligence and collective experience to improve the result.

It’s time now to negotiate compromises.

At this stage, it is necessary to assemble teams from various functional divisions to craft the most intelligent compromises for the product’s final design.

Furthermore, a range of personalities, each with unique ideas and priorities, more accurately represents the diversity of customer preferences than a single individual can.

Diverse teams with different perspectives are very helpful for this way of working.

The work can be structured as either a workshop or a traditional meeting. It is crucial to establish a detailed agenda, define a clear goal for the event, and ensure that participants are adequately prepared.

Distributing the results of the individual work in advance can improve the preparation of the individual team members, but is not obligatory. In some cases, spontaneous workshops can lead to better results and greater efficiency. It depends on the particular situation.

Review Events

Review meetings are required to compare the status of work with the development goals.

Review meetings are essential for verifying work results, correcting deviations, and making or agreeing on decisions.

These meetings must be precisely timed. If the frequency is too high, it is inefficient; if the frequency is too low, deviations are recognized and corrected too late.

In the context of hardware products, the term “Digital Mock Up” (DMU) is commonly used to refer to the digital version of the product during this phase. It is crucial for me that the DMU is not merely stored on a computer but is actively included in the review process.

If deviations are identified, there is often a tendency to seek a solution to the problem on the spot.

It takes an experienced facilitator to recognize this situation and to know whether it is more efficient to intervene or to allow the discussion to continue.

At the end of the creation phase, after numerous iterations of the above-mentioned cycle, the product is completed. However, it is still unclear whether all the initial assumptions are valid.

---

It is essential to ensure that a product fulfills its requirements before delivery; not doing so can result in financial losses and harm the brand’s reputation.

It is now time to test the product. We need to obtain evidence that it fulfills all specified performance and quality objectives.

To do this, we need the product itself and we need suitable test methods.

When a test or measurement meets the acceptance criteria, the corresponding requirement may be considered complete. Conversely, those that do not meet the criteria indicate areas where product improvements are necessary.

The validation phase also includes the correction of all errors and shortcomings, which is why design activities and programming also take place. You could call it “bug fixing”, but the definition of what is a “bug” and what is a major problem is somewhat controversial.

As we progress, it’s crucial to prioritize stability over creativity. We should only allow essential changes to the product to prevent the introduction of new errors.

Prototyping

In order to test the product, representative test samples must be provided.

Given the still-existing risk of nonperformance and the necessity for change, producing these samples at minimum costs is essential.

While in customer-intended production, the production method needs to be highly efficient in terms of manufacturing cost and time consumption, for the test samples the cost for changes of manufacturing tools and dies needs to be minimized.

Therefore, we need to be vigilant about this when selecting a prototyping method.

Let’s take a brief look at the various alternatives for producing prototype parts.

Virtual Prototype

A virtual prototype is a mathematical model in a virtual environment, that represents the physical product.

The most flexible and inexpensive prototyping method is virtual prototyping.

The product is completely modeled in a virtual environment and analyzed by virtual validation methods.

In many cases, the production method itself is disregarded and the focus is purely on the product’s design.

However, there exist possibilities to simulate the impact of the production method on the product’s properties. Simulating the production process, such as “mold flow analysis”, can yield insights into how the production process influences the product’s characteristics.

The significant advantage of a virtual prototype is that it allows for a detailed investigation and understanding of data and potential failure modes, which aids in resolving failures effectively.

Because of this, virtual prototypes are often used in parallel to hardware prototypes. (virtual twin)

Handmade Prototype

Handmade prototypes are manufactured without dedicated tools or dies.

Expert craftsmen employ versatile machines to create prototypes. Common processes include the turning and milling of metal parts from large metal blocks.

Sometimes even the material selection is altered to accommodate the nature of the test. Just think of the designers’ clay model. In this case, the shape of the product is validated, while the properties of the prototype are heavily compromised in favor of easy modification.

Often handmade prototypes compromise the material properties.

Handmade prototypes can be real-size or scaled.

Rapid Prototype

Rapid prototypes are manufatured using addidive manufacturing or by using addidive manufaturing for the cast models or molds.

Rapid prototyping manufactures the prototype directly from design data.

Materials can range widely from prototype-specific materials in Stereolithography to production materials in rapid casting.

Rapid prototypes can also be real-size or scaled.

Prototype Tooling

If a real production-representative prototype is desired, typically prototype tools are employed.

Essentially, these tools resemble those used in actual production; however, they are not as durable as those designed for mass production. Instead, they are “soft,” which means they can be readily adjusted should there be a need for modifications to the product.

Production Tooling

Using real production tool for prototype production provides the most representative test result.

Some parts require real production tools to manufacture even the prototype.

While this prototype offers the best comparability with the series part, the tool production time is often a major challenge.

In these instances, semi-complete production tools are employed to fabricate the prototype. This entails omitting certain individual production steps or preparations for mass production during the creation of the prototype.

However, if changes to the tool become necessary, it can become quite costly!

Prototype Software

When testing software, the running environment is often the challenge.

Prototyping for software is usually not a problem, no tooling or manufacturing is needed.

But the test environment of the software can become critical.

If hardware and software are developed together, then the software must be based on the requirements of the hardware prototyping. In these cases, the question arises as to which processors and control units are available in hardware.

When prototype software is deployed in a production environment, it should be isolated in a separate space. This is often referred to as a “Beta version”, which is made available in a distinct space for customers who opt to participate in testing.

Lets now have a look at the validation activities.

Performance Testing

Performance testing confirms that the functions and properties of the product meet the required performance criteria.

To give you some examples, just let’s assume the performance testing of a car. Here we look at things like:

For validating the performance we can divide into objective and subjective testing.

Objective Testing

In objective testing, measurements are recorded and the data are compared with the predefined target values.

Taking measurements requires the installation of measurement equipment on the product.

Although objective tests provide accurate measurements, the interpretation and evaluation of the test results may require expert knowledge.

Subjective Testing

Subjective testing looks at product properties, which can not be measured by measurement equipment or which don’t have hard numbers as goals.

Acceptance criteria are often described as:

Skilled, specially trained testing personnel conduct subjective evaluations. Often, this involves assessing a broad range of individual criteria to arrive at an overall judgment of a specific performance aspect of a product.

Involving end users in subjective testing of product performance yields valuable insights into customer acceptance. However, it requires specialized procedures and setups to prevent bias or unintentional misinterpretation.

Durability Testing

Durability testing verifies the product’s expected lifespan within an accelerated testing period.

Assessing a product’s durability is challenging due to the influence of time as a factor.

Durability is a major quality aspect of hardware products. They are intended to be used over a long time, for many products we talk about several years of operation.

Over time, damage accumulates in a product until it reaches a threshold, leading to the product’s failure.

A typical failure scenario is the bathtub curve. In the beginning, we see a high number of failures caused by production influences. This is followed by a long period with lower failure rates until the failures due to wear and tear increase towards the end of the projected service life.

We can not wait years until we receive a testing result, therefore we need test procedures, which accelerate wear and tear in a meaningful and reproducible manner.

Reliability Testing

Reliability testing evaluates the consistency with which a product performs its intended functions.

Statistical methods are required to determine whether the specified reliability targets have been achieved. And, as usual, statistics require a sufficient number of representative test results.

In an ideal world, product reliability would hit 100%, with every item consistently performing as expected. While this goal is unattainable, aiming for near-perfect reliability is standard practice. It is essential for most products to operate without fault.

This presents a challenge for statistically validated reliability testing, as it requires a substantial number of data points to be collected to provide the necessary proof.

---

Preparing products for customers on a large scale requires special attention.

Once the validation is complete and development is finished, there remains one final step.

The manufacturing of the product must be scaled up to ensure delivery to the customer under real-world circumstances:

• in time,
• in quality
• and in cost

Scaling up a project may involve increasing production volume or investment, depending on the project’s nature.

Try Out

Confirming the readyness for mass production is called “production try-out”

Before the product can be manufactured in big numbers, it must be assured, that the processes for manufacturing and logistics are all in place and work smoothly.

The best way to get confirmation is to try it out, that is where the name of this phase originates from.

Ramp up

A stepwise increase of the production volume is called “Production ramp-up”.

For products, that are produced in high numbers, all the processes need to be accelerated to full speed.

Similar to a car’s acceleration from 0 to full speed, there is an acceleration in production volume. Beginning from zero, the order intake, logistics, production, and delivery must be deliberately accelerated to reach the desired production volume.

In this phase, the project team must be equipped to swiftly address unexpected issues and mitigate disruptions. Conducting daily reviews and holding meetings to resolve problems are considered best practices.

Concluding remarks

It’s evident that my expertise lies in the automotive industry, which is reflected in the DCVI description within this article, leaning heavily towards automotive applications. Nevertheless, it’s important to note that this principle is universally applicable across various sectors.

I invite you to share your experiences and give examples of how you’ve implemented these concepts within your industry in the comments below. Your contributions and insights are highly valued.