When we are in a product development lifecycle, we often face a situation when we have to make a design decision upon multiple viable options. Down the line our choice may not turn out to be the best one, or in worst case we may face firefighting and rework situations. So are we able to take a different approach, e.g. preserving multiple options beyond the design phase before we lock in the final solution? Yes, there is an approach called Set-Based Design (SBD). We’ll talk about this design practice in this article.
Concept
Set-Based Design is a design practice that keeps multiple design options for as long as possible during the development lifecycle. We’ll talk about how long is enough in the later section. But the idea is to not choose a single-point solution upfront.
Along the development lifecycle, we often go through analysis, design, build, test and release phases. A common approach is to select a final design before moving to the build phase. If everything goes well, we’ll convert the design to an implemented solution and release it to production. However, due to limited information collected in early phases, we may have to make assumptions and it can lead to incorrect outcomes. We’ll then have to go back to the design phase to pick another option, and rework through the build and subsequent phases again.
The approach from the SBD is to carry multiple design options beyond the design phase. As the lifecycle advances, we will narrow down the options gradually. In some cases, we may carry multiple options into the build, test or even the release phases. Let’s take a look at these scenarios.
How Far?
Let’s use the diagram below to present a few scenarios on how far we can carry multiple design options along the development lifecycle. We can narrow down to the final solution in the design phase, or anywhere before the test phase, or even carry alternatives to production to offer customer multiple product options. The longer we carry the options, the more capacity and resources are required.
Let’s assume capacity and resource are sufficient (even it’s rarely the case). Is it always “the longer we carry multiple options the better”? In D. N. Ford and D. K. Sobek II’s “Adapting Real Options to New Product Development by Modelling the Second Toyota Paradox” article, they mapped the Convergence Initiation Time (i.e. when the final design option is selected) and the Quality at Project End, based on 100 simulations of a project length of 900 days. The result is like below.
The overall diagram aligns to the benefit that SBD can bring to the final outcome: “As teams wait longer to start eliminating design alternatives, they gain access to more and more accurate quality information and, therefore, make wiser choices, on average“. However, the diagram also indicates that the quality doesn’t improve after certain point of time.
So one conclusion we can at least make is that it’s not “the further the better”. Then the next question is when is the optimal time for the convergence? The diagram may indicate the middle point of the project is the optimal point. But different industries and different projects have their own nature and conditions. The pace of teams gaining access to supporting information and evidence to make the convergence will vary too. For example, the pace of provisioning, testing and deploying cloud-based infrastructure is way higher than the on-prem. So the optimal convergence point should move towards left in the public cloud use cases.
How Many?
From the starting point when we have multiple options in hand, to the convergence point when we select the final option, we can anchor two milestone flags, Shortlisting and Finalisation.
People may argue that the whole journey is about shortlisting, if there is a milestone called shortlisting, where do we put it. Well, in most cases, the candidate options can be grouped into weak options and strong options. To ensure we have the time/money well spent, we should aggressively eliminate week options at early stage and concentrate our resource on the strong ones. And we can put this first milestone flag against the point when the weak ones are eliminated.
For the remaining strong options, how many should we keep in our pocket? The safest answer is “it depends”. But hey, let’s think outside the circle. Remember when an old king wants to challenge his sons with intellective questions to decide whom he should pass his throne to? He always has three sons, isn’t it. So let’s go with three as well.
Ok, before you move your cursor to the cross button of this article, let me explain.
Remember there are always costs behind each additional option we are trying to hold. If we can get to the smallest plural number, i.e. two, that’s great. If not, we shouldn’t keep more than three in parallel. And it’s also common that some of these candidates may evolve out another sibling options down the line. If we can’t even choose three or less to move on, it’ll be challenging to choose the final one later as well.
And for the second milestone, the Finalisation, we can follow the SBD principles below to reach the final point.
Principles
In D. K. Sobek, A. C. Ward and J. K. Liker’s “Toyota’s principles of set-based concurrent engineering“, they summarised the following principles for SBD:
- Map the design space :
- Define feasible regions
- Explore trade-offs by designing multiple alternatives
- Communicate sets of possibilities
- Integrate by intersection:
- Look for intersection of feasible sets
- Impose minimum constraint
- Seek conceptual robustness
- Establish feasibility before commitment:
- Narrow sets gradually while increasing detail
- Stay within sets once committed
- Control by managing uncertainty at process gates
Among all the principles, the communication point is worth being highlighted a bit more. Firstly, the communication between the development team and product owner plays an important role in budgeting the set-based design, as well as road mapping the milestones mentioned in the earlier section. Otherwise, the development team can quickly burn out the unprepared budget and the project may go south.
Secondly, the communication between development teams also holds a critical role, especially when multiple teams are working together to build a microservice-based solution. Each team may hold a number of alternatives. With clear communications, teams can effectively working on their own sets of alternatives without blocking the other teams’ progress.
Another best practice that’s not specifically mentioned above is to use a design canvas to visualise the design options. As teams gain additional validation and understandings of candidate options, they can remove the eliminated items from the canvas till the last standing one on the canvas. It’s also a good practice to keep the snapshot of the canvas to provide reference and lesson learnt information to future projects.
By following above principles and best practices, we will be able to effectively reach the Finalisation milestone and deliver a successful product/solution.
Summary
Set-Based Design aligns well with SAFe’s Lean-Agile principle, i.e. “Assume variability; preserve options” and it’s one of the best practices in the Lean product development. However, it may not be suitable for every product development cases, especially for the ones that don’t have friendly funding and less space for the learning-as-you-go practice. On the other side, for situations like projects with requirement for innovation and adopting new technologies, SBD can provide economic efficiency and high-quality outcomes.
