One approach that has proven extremely useful in this context is the “agile method”
When developing a physical or hardware product it is very common, indeed recommended, to screen alternative hypotheses.
We think in this sense of things close to us, such as making a custom kitchen.
Even starting from existing forms, this activity requires the development and evaluation of alternative solutions.
Each solution has advantages and disadvantages, different costs and, often, different procurement or construction times.
This approach can be described with the evolutionary pattern of alternative cups.

In this diagram there are 3 alternatives of designing a cup.
Since we do not know which will be preferred by the client they are presented to him in the first instance or iteration:
- soluzioni di tazze tondeggianti
- conical cup solutions
- pedestal cup solutions
As in real life, an initial selection is made after which the development of approved solutions continues.
This is followed by the second iteration, which will produce a further selection.
Each solution is evaluated from the perspective of functionality taking into account the Design for X perspectives, as I described in my previous article.
This approach allows us to be effective and thus come up with a product that satisfies the customer more.
It also constitutes a way to mitigate risk.
When faced with any reconsideration by the client, we do not go back to the beginning but only to one of the previous steps.
How do we know how many iterations it will take? … We don’t.
How do we plan for this development of alternative solutions?
We certainly cannot employ waterfall planning represented by a Gantt chart.
Yet this approach, which is called Development for Concurrent Solution Sets or Set Based Concurrent Engineering, were being proposed to me long before I discovered agility.
I was never able up to that point to do any real planning of the activities to be done.
What if we used the classic adaptive Agile approach instead?
The Agile approach iteratively manages modification as much as developed, and incrementally manages the addition of new product elements (design or physical).
In this way, such a complex process as developing competing alternative solutions can be effectively managed.
The solution is successful because it focuses the team on presenting solutions, developed “just enough “for the team to make an evaluation together with the stakeholders and the customer.
During subsequent iterations, approved solutions are further developed until they converge on an agreed-upon solution.
With my product development teams and those of the companies I follow, we have continuously applied this approach in all the products we have developed. The approach Agile has finally given, to me and my teams, the possibilities to manage the development of alternative solutions Taking into account the multiple perspectives of Design for X.