Tag! Your Product’s Design is now Frozen

The Importance of Design Freeze in Product Design

Wade G. Cunningham
Glassboard Blog

--

Remember the recess game freeze tag? For those of you that don’t, (really? No freeze tag experience?) it’s the game where one person is “IT”, and the players they tag are frozen until an unfrozen player tags them or everyone is frozen. If you ever played, didn’t it irk you when you tagged everyone but one person, then he or she started unfreezing everyone and before you knew it you were winded, gasping for breath and everyone was unfrozen and running around? You were also probably deflated because after all that work, you were basically starting over.

Product development can sometimes be like this. A new product is designed, developed and prototyped, and eventually your company is on a path to produce enough for the customers that will want it, and then there is a change, or two, or three, based on any number of factors (to reduce cost, add features, meet regulations to name a few). Your team then tells you if you change a feature, then another component will need to change, and then the software will need to change, and then on and on…. Pretty soon you’re scratching your head, baffled because you have done all this work (or paid to have it done), and now it seems, you are starting over.

What to do? Here are some guiding principles that we have found useful.

Clear Requirements, Documented up Front

Step back and think about the product you are trying to create, and spend some time on the most important features. In freeze tag, one semi-effective strategy is to try and tag the fastest person first, then tag each subsequently slower player. Can this strategy work in product development? It may pay to try and conquer the “thorniest” issue with your product first, commonly identified and ranked on a feature evaluation matrix. This issue likely impacts everything else, and there is no sense in working on the less important peripheral (or slower) items.

By tackling the more difficult features first, this should reduce risk and also product change as time goes on. The important features should remain consistent. In electrical design we have found that at early stages, issues like thermal management (getting the heat out), energy management (ensuring sufficient battery size and packaging), and EMC requirements to be the thorniest issues. The required product tear-up to fix these issues later in the development cycle may not lend themselves to elegant or simple solutions.

But what if you do not know what your riskiest feature is? Another freeze-tag strategy is to tag whoever is closest then play defense and work outwards. If you know of a couple of features that are very important, then firm up these product fundamentals, and let the other less important details be malleable. Interfaces fall into this category, and defining and maintaining consistent interfaces between different parts of the product may limit the need for cascading changes later on.

Regardless of if the requirements stay the same throughout the entire project, there simply must be written documentation capturing them. This is either a list of product features, a detailed product description, or an engineering specification. Transient verbal descriptions are not enough, and have a way of morphing over time. A Discovery Phase for your project will help to identify and establish these product requirements.

Have a Change Evaluation Process

An unrelenting fact in product development is that things are going to change. Build in a process from the start (or at least a rough idea) of how you will evaluate any change and decide whether to implement it or not. This evaluation should be a trade-off assessment to lay out clearly what the proposed change is, and all steps that will need to be done or repeated if the change is implemented. Already implemented features have priority — since it is already exists there is no need to spend additional resources on it.

The new feature always has to buy itself in.

In the game freeze tag observers have a different perspective than someone actively playing. When you are in the middle of the game you are running and concentrating on the people running by and around you. You can’t step back — you’re busy tagging people! If you were to take a step back and look at the whole picture, you can see how a plan might help. An observer perspective will allow for a more targeted strategy to be planned, and lead to implementing productive changes.

Think about the steps that need to happen to implement a change to make sure that things don’t get overlooked. In this change process, evaluate the effect of the change on the agreed upon requirements. If there is an additional component added, how does this affect the battery size, which affects the product size, which affects the enclosure, which affects the cost. If components change enough, will testing and validation need to be repeated? Evaluations can be performed against the original requirements to define the tear-up needed.

Try to keep some resemblance of a process — there are good reasons for this.

Having a product change is not the end of the world, and this is what product development is — changing what is available. Change is happening around all the time, need to harness this and implement positive changes and features that make your product better.

Relentlessly combat feature creep

Feature creep is not only represented by obsolete parts in a drawer, but by material impacts to the timeline and budget of a project

Features are great, and there are so many more things that your product could do. Freeze tag gets harder the more non-frozen players you add. One player is easy, two not too bad, but when you get to 10, 20, 50? Now you need to add to your team just to keep track.

In your product, it is important to understand that every resistor, capacitor, screw, or washer is connected to everything else. Since everything is connected, when one component changes, yes, everything about your product changes in some small way. True, some things are more connected than others, but simple changes can have cascading effects on the rest of your product. For instance, increasing the size of the power supply may affect all of the thorniest issues — adding heat to an already small enclosure, draining the battery faster, and enabling higher currents that cause additonal EMC issues.

If there are infrequently used features of your product that affect the cost and performance of the highly used features, they may be more trouble that they are worth. At a minimum the tradeoff may not be clear.

All features add to the functionality of your product, and customers may like each of them. However, there are constraints in implementing them. Have a process where you force rank features, where only one can be the most important. This forces decisions between the features relative to importance. So when a decision has to be made about adding features to a product, make sure you implement the most important one.

Establish Realistic Freeze Dates — Plan for Incremental Releases

Designers and engineers will continually tinker with and optimize your product if you give them the chance. You have to make them put down their pencils. The design freeze date, reasonably set, can force your team to realize that it is time to finish. In freeze tag, the teacher blows the whistle to end recess and you will have another chance to play next recess. Ambiguous end times make for frustration and delays in development.

The product should freeze well before production to ensure time for testing. In production, the cost of a change can spiral up very quickly. If a design flaw is not caught, you can manufacture many bad products very quickly during a production run. It is rather trivial to fix a resistor on a prototype, but what if now you have to fix that same component on some 300,000 units? What if half are already in customer hands?

Software development teams are able to release “bug fixes” or software “updates.” In the hardware world, we refer to these as recalls…

In the game freeze tag, you only win when everyone freezes. In product development, the definition of a win is not as straightforward. It could be when the product is developed efficiently on time and on budget, with little rework and redesigns. It may be when the product looks and operates like it customers expect, and customers feel as if it were specifically designed for them. Or it is when you ask customers what they would change about your product, and they say “nothing”. It is a high bar, but in truth, your product will likely never be completely frozen.

In product development, just like freeze tag, as soon as everyone is frozen, you start again, just with different players and different rules.

Wade Cunningham is the Program Manager at Glassboard, a hardware focused product development company.

--

--

Programs Manager at Glassboard Product Development. One time Champion of the World. @glassboard