The town I grew up in, Snohomish, was a pretty beautiful rural area with a-lot of mountains, farmland, rivers and lakes. It was famous for being a great place for both skydiving and hot-air balloons and many of my friends during the summer would often work for several of the companies around the area that did this during the summer. As I have been recently reading Design Sprint: A Practical Guidebook for Building Great Digital Products by: Todd Lombardo, Richard Banfield, and Trace Wax, in a way I started to see correlations between Design Sprints and the Balloons I used to see in Snohomish.
One of the things I have consistently noted in this book is how often the author exhorts the design teams to come back and re-examine the problem after each exercise to make sure that it is on track. It reminds me of the hot-air balloons I used to watch get set up as a kid in my hometown. By this I mean that these design teams are trying to get this idea off the ground, much like the people setting up the hot-air balloon. But much like the balloon, design sprints are constantly tethering back their ideas to the problem so that their ideas do not take off too early.
The authors start by establishing a set of guidelines that seem to encourage teamwork mentioning:
"Our goal with these guidelines is to get the team to fall in love with solving the problem and not one of their own subjective solutions.
They then run through the problem to get everyone on the same page and work together to establish goals and anti-goals, separate facts and assumptions. After all this they come back together to define the problem once more, reframing in other ways and running it through challenge maps. This seems to again be tethering/grounding everyone firmly to the problem at hand before ideas really start to take off.
Seeing how an entire day can be spent really just unpacking the problem before even ideating reminded of how as UX designers, our designs really need to be a result of the problem. If the problem assumed is not correct then the ideas that come from it will in all likelihood not be correct. I think it is very easy to go off and come up with a-lot of cool ideas, but often I find that unless I am constantly tethering my ideas to the problem statement I will end up getting further away from the problem and more tied to my own ideas.
Coming back to the quote "Our goal with these guidelines is to get the team to fall in love with solving the problem and not one of their own subjective solutions." I think one thing that can be dangerous for designers in particular is falling in love with their solutions rather than the problem statement. It seems that unless you spend almost as much time and energy into defining the problem, then you will again and again fall into the hole of being consumed by your solution rather than actually solving the problem.
In my mind it comes back to the hot-air balloon, our ideas really need to be tied and grounded to the problem before we allow them to really take off. Allow that to be the point of reference rather than being so attached to the idea itself.