Paradoxes of Product Development

A paradox is an often exaggerated, absurd and seemingly contradictory statement. However, this contradictory statement can lead to new insights. I believe that we should consider a few interesting paradoxes in embedded product development.

Is the Obvious Thing always the Right Thing to do?

There are these few ideas in product development, especially in software development, which turn into their opposite when examined closely:

How these contradictions occur in practice and how they can be resolved, you can read here:

Paradox 1: If you want to Develop Faster, take More Time

...more time for specification and finding the appropriate technical solution (the "architecture").

A Short Story

which illustrates this. "Help, the standard comes into force at the end of the year.... And none of our 12 control systems meet the new requirements." We then invested a total of four (4) months in specification, the first two months until we had an optimal technical solution and four control variants remaining. Then another month each with product management to dump one control variant each.

During this time, very clear and detailed specifications and a clear architecture were created, which documented the consensus with product management, mechanics and production. We were then able to bring the remaining two variants to production maturity within six (6) months, on schedule by the end of the year. And by the way: the controllers are still being produced today, after thirteen years, without any significant changes.

What Happens when one Starts Fast?

If you start with a product development based on unclear requirements, in embedded development this has the disadvantage that the developers have to make assumptions when selecting the processor, the operating system, the interfaces, etc. If these then turn out to be wrong in the course of clarifying the requirements, e.g. the processor is too weak, the result is a huge effort for redesign or for development around "bad technical decisions".

And What about Agile?

The agile processes and work methods of generating specifications during the project usually do not solve the problems and can increase the risks.

Conclusion

Fast and smooth development must be bought with early clarification of the requirements.

Paradox 2: If you want to Develop Cheaper, take the Higher Hourly Rate

...just as your high-quality products are not the cheapest, high-quality engineers are not the cheapest.

A Short Story

A customer contracted the software for a graphical user interface as a near-shoring project in an iterative/"agile" way. Except for the visual design, the software had exactly the same features as the user interface we developed for another platform at a fixed price. This near-shoring development was initially estimated to be massively cheaper.

Two years after the start of production, the customer's CTO said: "A graphical user interface costs the same everywhere". The costs for both developments were the same after all changes in the near-shoring project. And not even just the same: our development additionally included the entire electronics and sequence control, the graphical user interface accounted for only 60% of the "same" development costs.

What happens if one Only Looks at the Hourly Rate?

For a first iteration a simple case is estimated, out of ignorance or to show low effort, so that one can start with the development. Then the immature requirements are assigned to inexperienced developers, who fulfill the requirements to the best of their knowledge. The subsequent iterative changes and elimination of misunderstandings eat up the entire cost advantage again.

Conclusion

The savings that result trough development and over the whole product lifetime stemming from the experience of the engineers, from clear, lived processes and from continuous training must be bought with an increased hourly rate.

Paradox 3: When it Works, Only Then does the Work Begin

...because then the non-functional requirements and regulations come your way.

A Short Story

A research team had spent years developing a sensor until it worked accurately. The excitation, control and readout was based either on a rack full of sources and measurement devices or then on an integrated device, which on the one hand was outdated and not powerful enough, and on the other hand did not offer up-to-date interfaces to the outside.

In a startup, the sensor was then to be commercialized for the process industry. Since it was "already running", no significant budget was planned for the development of a control system that met the requirements of an industrial environment in terms of reliability, safety and interfaces. Instead of hitting the market, it took several years to win a few customers in a few industries.

If a device works, then the effort only begins, especially if functional safety (e.g. the machine directive) still has to be considered: Innovation Pareto hits.

Conclusion

To save redesign effort, you need to consider customer requirements (interfaces, operation, environmental conditions...) and regulations early in the innovation process.

To get a clear picture of the remaining effort after "it works", the development must be realistically planned for customer requirements and laws and standards (safety, functional safety, data security...).

 

Do you still have questions about these paradoxes and contradictions? Do you have a different opinion? If so, contact us directly or comment your thoughts below!

Are your ready for a contradiction-free development? Contact me!

Keywords/ Tags

Questions & Comments

No Comments

Do You have Additional Questions?

* These fields are required

Let us discuss your idea/ your project