Recently, I was part of a large project with colleagues from different areas of the organization. I remember sitting there in that first meeting as we all started to piece together what we needed to do, wondering exactly how we would pull it off. 

Whenever there’s a problem that makes most of us see double, I turn to friend and former colleague C. Todd Lombardo. See, C. Todd wrote a book called Design Sprint — which is a method that can be used by any size company that encourages you to figure out your assumptions, question what you think you know and create lightweight tests to ensure you methodically arrive at a solution that is worth building. After discussing it with him, I knew it was exactly what we were looking for.

And so it began: a week-long journey where we took what we thought we knew, ripped it apart, put it back together — all with a goal to hitting the ground running on our new project. Here’s how it works and what results you can expect using a similar process:

Prepare

During the first phase, we knew it was important to bring in stakeholders from across the organization to get enough perspectives. This can often be a challenge with a lot of schedules, but the key to a good design sprint is focused attention. Think of being sequestered; it’s kind of like that.

Understand

Second, we identified and clarified the problem that our product would ultimately be fixing. We took time to share research we had done, including any work previously done on the topic, and then set ourselves up to start to create a solution.

Diverge

We all approach a project thinking we know the answer. Your brain naturally makes assumptions you don’t even know you’re making. But when you “diverge” you are collaboratively brainstorming and exploring a range of possibilities to solve the problem that you may not have thought of.

You don’t need to be a big company to bring Design Sprints into how you think about validating ideas, and that’s the beauty of it.

We kicked off our brain-bending day with a nine dot exercise. We were asked to connect nine dots with four straight lines. We couldn’t lift our pen once we began, and we could not reverse to cover where we had already drawn. (You can do the exercise in the above link — just don’t advance to slide two before you think long and hard about it.) We sat racking our brains, but in the end we couldn’t figure it out.

The exercise illustrated something very important: We naturally made assumptions that we didn’t need to make. So once we realized how differently we needed to think, we sat in the room thinking of all the ways our project could be approached. Had we not permitted ourselves to “diverge” from our assumptions, we would have likely spent a lot of time and money building something that would only half solve our problem.

Converge

One of the hardest parts of starting any big initiative is knowing where to start. The day after Diverge, you Converge, where you match up assumptions with what you can actually test. It’s a challenge and requires discipline to take all the great ideas and really focus on what type of test will really get your assumptions validated. In our day of convergence, we had to push ourselves to identify which type of customer we wanted to focus on. Was it prospects? Was it current triallers? Was it converted customers? Figuring out the most valuable place to test, and outlining a very specific test, is key to getting enough information to validate that we are on the right path.

Validate

There are many different ways to validate (for our tests we used GoToMeeting and a few willing test subjects who were carefully picked during our converge day), but you must go into this day with the willingness to accept that you could be wrong. It’s harder than it sounds to have that level of humility. Our guts are very powerful things. (And our egos don’t like being bruised either.)

It’s also important to frame the questions in a non-leading way. For example, if I want to know what is important to a potential customer, the question to ask wouldn’t be “what could we build that would make you more successful.” Instead, it should be framed as, “tell me about other products you have used that you’ve achieved success with.” It’s not up to the customer to create the solution for you; that’s your job. What you need from them is validation that your solution could work for them.

The real question is, can you afford not to partake in this type of process? I asked C . Todd why every company should go through similar steps, even if they aren’t spoiled with resources or time. C. Todd told me, “You may have your direction, and you may want something to be true, but your idea has to be validated first. Life is too short to build something nobody wants.”

And there it is. We were all part of a large and complex project, but before we requested resources and thought about scaling or creating models, we had to first accept that we could be wrong — the key to great product design.