Before we dive into the specifics of the topic, it’s important to understand the difference between a rule and a principle.

A rule is an explicit instruction on what one can or cannot do in a given situation. It requires a set of criteria to be met for it to be applicable. This is why rules can be beaten. I’m sure you’ve seen your fair share of lawyer movies in which they skillfully work around certain rules by reframing the situation. This is the reason why most rules become outdated and need to be changed, or need more and more rules to complement them over time.

A principle is a universal truth. It can be applied to a multitude of situations, leaving room for ones’ logic, knowledge, common sense, and wisdom to decide what is the best course of action.

In conclusion, a few principles can often be a substitute for a thick rule book and provide clarity in grey areas where it’s uncertain how some rules might apply.

If rules can guide a blindfolded man through an obstacle course, principles help take the blindfold off.

With this in mind, let’s look at some of the principles behind the Design Sprint.

When discussing a problem, ideally everyone is given a chance to be heard and understood, and each idea is given enough time to be considered, analyzed and decided on. In reality, the dynamics of human interaction in a group make this a lot harder. Naturally, some members of the group who are more vocal, or who have more experience in the topic being discussed will polarize the discussion. Unfortunately, that doesn’t mean they’ll always have the best solutions. Sometimes the best ideas come from the most unexpected places — team members that have never worked on the problem before or don’t have a relevant background.

How do you make sure everyone has had the chance to present their idea? Here are some ideas that might help:

• Avoid open group discussions. Clearly define the problem, communicate it to everyone, and let them work on it individually before presenting their ideas to the rest of the team.
• Give everyone a crash course into how to ideate fast and avoid getting lost in the details.
• Create a relaxed atmosphere and assure everyone they won’t be judged. Sometimes initial ideas that don’t work can light the creative spark and generate other ideas that will.
• Have each team member present their idea while everyone else takes note of the pros and cons of each. In the end, compare notes, remove duplicate pros or cons, and decide on a solution.

Verbal communication is fairly low-bandwidth. We often need a lot of words to describe what we’re thinking accurately enough. This is why well-written contracts and legal documents are overly descriptive and specific (think wording like “including, but not limited to…”). That’s also why there’s the saying “A picture is worth a thousand words”. Human sight is much higher bandwidth than hearing. We can process a level of detail about things we see that would take us a long time to describe verbally, even if the individual has the best vocabulary to do so. Why am I mentioning this? In the world of IM chat and acronyms(IMHO?…), we tend to try to convey our thoughts in as few words as possible, and we assume that our listeners quickly understand and contextualize what we’re talking about. That never happens.

When simply talking about solutions it often doesn’t work great. Words are misinterpreted, patience starts wearing thin, and frustration builds shortly after. This all can be avoided by using visual means of communication. Give concrete examples — images, prototypes, napkin sketches, etc. The closer to your vision and the less explaining, the better. Do not assume others understand what you’re referring to, even if they say so. You may be thinking of similar yet different things. It’s always better if you can point to something concrete and say “There. I want that.”

Testing early and often will help your product stay on track and avoid endless debates. No amount of expertise or ideation can replace direct customer feedback. A few reasons teams are reluctant to test could be: the design is not refined enough, it’s expensive, it’s time-consuming, or not knowing who the target user is and how to find them. These might sound like valid concerns, but the good news is all these issues can be addressed with little to no financial investments and a reasonable time commitment, while the upside is considerable. Jules Cheung goes in-depth on this topic in her article How to do user testing on a budget. Go check it out.

It’s worth also mentioning an unexpected side-effect of long, heated debates, which unfortunately is sometimes overlooked by team managers: the negative impact on team morale and the state of “flow”. What do I mean by this? A good team works like a well-oiled machine — there’s good team chemistry, everyone is doing their thing and respecting each other, and tasks are getting done. Disagreement about product decisions that happen publicly (eg: in a brainstorming meeting) is like throwing sand in that metaphorical machine. The effects might not be obvious instantly, but you’ll notice things slowing down… suddenly there’s more friction between team members, they’re less involved, they start simply “doing their job”, and not thinking about the bigger picture and the good of the company.

In a perfect world, every team member would agree with everyone else, whether we’re talking about process or product decisions. In reality that rarely happens especially when it comes to large teams. It’s not uncommon for teams to get frustrated and confused because there’s no clear decision-maker for every aspect of the production process. In my experience so far, this seems to be missing in a lot of companies, especially startups, or even established companies in which the founders are actively involved in the product design process. The truth is people will not always agree, and when it’s crunch time, the ONLY way things will move forward efficiently is to have a decision-maker. In a lot of startups, the issue will often end up being elevated to the C-level, where the founders or managers debate and decide the solution, which not might be ideal for a bunch of reasons we won’t get into now.

What can companies do? It’s vital to have decision-makers with clearly-defined areas of responsibility and trust them to make the right decisions. When everyone understands what’s expected of them, and have ownership over their piece of the system, things will run a lot smoother — team members will be aware of their responsibilities and their boundaries, stay in their lane and be focused on making sure their part is done well. This is not to say that collaboration should be discouraged. On the contrary, I’d argue that in such an environment collaboration will run smoother because teammates are not stepping on each others’ toes.

Avoid group brainstorming and instead, devise a solution where everyone can work on the problem individually and later present and discuss their solution. Create a safe space and take time to consider the merits of every idea. When presenting a solution, show something concrete and give as much context as possible. When your team will inevitably be locked in a long debate whether a solution is good or not, find a way to test it quickly and cheaply (there’s always a way). Finally, when results are in, to avoid endless opinionated debates, make sure there’s a decision-maker that can move things forward.