Solve Big Problems & Test New Ideas In Just 5 Days

Head here for the full archive of my latest tech insights

This blog will teach you the process of running a "design sprint" – a method developed by Jake Knapp, a partner at Google Ventures – to solve big problems and test new ideas in just five days.

Most teams often invest months, even years, in developing a product or service -- only to discover they've built something that no one wants.

Jake developed a method that helps teams make better use of time and resources by simulating the entire product development process in just five days.

A design sprint helps teams filter ideas and gain clarity as to which of them are best to pursue.

Let's dive in and see what that process looks like at a high level, and how to implement it.

For more a more detailed, step-by-step process, check out Jake's book.

Preparing for the Sprint

To kick-off a design sprint, your goal is to assemble a diverse team from within your company of five to eight experts in different areas of the business.

Jake notes that the sweet spot here is seven people -- any more will only "create drag."

An ideal team involves representation from the engineering, sales, customer support and marketing departments, as well as, critically, "the Decision Maker."

Each person brings a key understanding to the process: engineering understands product capabilities, sales understands customer preferences, customer support sees customer challenges, and marketing holds key insights that tie it all together.

Over the course of the next five days, the team will develop and test a number of different things. You can run sprints on key features (What should my landing page look like? How should we price it?), product variations (Do people prefer this type of product or something else?), or entirely new businesses (Does this business solve a key problem for a customer? Are they willing to pay for this product?).

Here's how the five key days play out...

Day 1: Monday -- Map and Define the Problem

Day 1 is about defining the problem you want to solve.

The decision maker in the group should facilitate the agreement around a long-term goal. What the company or product should achieve in, say, eight months' time. Make sure everyone is aligned and excited about this goal, write it down and post it on the wall.

Then, map out a series of difficult questions, potential barriers to achieving that goal:

  • What are the technical and market risks?
  • What if people don’t care about it?
  • What if they won’t use it?
  • What might they not trust?

After you've mapped out the questions, spend time trying to answer the most important of them based on the information you know.

Next, brainstorm and list as many different types of customers (demographics) that you believe have the problem you are trying to solve. Now pick one (either the one you best understand or the largest cohort). This is the customer for whom you are going to be (designing) running the design sprint.

Based on this understanding, one team member is next assigned to recruit five real potential customers who fit these characteristics from outside the company. These five people will be asked to physically show up on Friday to test the product you're designing.

Why five? Back in the 90s, Jakob Nielsen did a study to answer this question: "How many interviews does it take to spot the most important patterns?"

It turns out that 85 percent of the problems were observed after just FIVE people reviewed a product!

Additionally, the deadline of actual customers coming in five days creates an added incentive to have a workable product finished by then.

The team's last task for Day 1 is to Ask the Experts. Somebody out in the world knows "the most" about your customers; somebody knows the most about the technology, the marketing channels, the business, and so on. Your goal is to find them and pick their brains.

This is usually where people find the most exciting ideas.

Day 2: Tuesday -- Create Solutions

Jake compares ideas in product design to LEGO bricks: they can be combined and recombined in new ways to create something better.

On Day 2, the team first sketches (literally, on large sticky notes) competitors' solutions and puts them up on the wall for everyone to see.

Next, each team member sketches new solutions that combine these "LEGO bricks" to address the problem identified on Day 1.

Each person does their sketching on their own and submits their sketches anonymously. Each member can submit one, two or even three solutions.

This individual process prevents the groupthink that occurs with traditional brainstorming.

The goal is for each individual to create fully fleshed out ideas, empowering introverted team members to contribute equally.

Note: You need to be quite thorough with these sketches -- they should illustrate how the solution would work for the target customer, what the customer sees going through the app or website, and so on... They can be rough, but they should be very detailed and precise.

Day 3: Wednesday -- Downselect

Suspense is high coming in on Wednesday morning. The team tapes up sketches and everyone marks their favorite ideas with a dot.

The team engages in a timed critique of each concept. Interestingly, the person who sketched it isn't allowed to speak until the end. This minimizes bias and ensures the process is truly meritocratic, allowing people to be as honest as possible with their critique.

In a group of seven sprint participants, there may be anywhere from seven to 15 proposed storyboard solutions.

The team votes on the solutions they believe in and are most excited about testing.

The clincher, however, is that The Decision Maker casts "super-votes," which supersede all other votes, choosing up to three solutions to test fully on Friday. Ideally, though, you pick the best single prototype to answer the question you defined at the beginning of the week.

Next, create a storyboard. The team should flesh out the top idea(s), detailing everything from discovery (i.e. how a user comes across the product for the first time -- for example, on a store shelf, via a web search or news article) to every other part of the user experience.

In other words, this storyboard needs to be able to stand alone without a verbal explanation, so it may be evaluated in an unbiased manner, on their merits alone, not based on who created the storyboard.

The next step is to take the idea beyond the storyboard and transform it into a high-resolution mockup that looks and feels like an actual product.

Day 4: Thursday -- Put It All Together & Build the Mockup

Once the team has an idea of how everything will look and feel, they assign tasks to different team members to build a prototype.

A good rule of thumb is: Build just enough to learn, but not more...

These prototypes don't have to be fully functional, but they should look like they are. Buttons might not fully work, but when pressed should drive the customer down a different path...

Jake calls this "Goldilocks Quality" – the prototype should have just enough quality to evoke honest reactions from customers.

After team members build their mockup, the team regroups to connect the pieces and flesh out the full experience they want to put their five clients through tomorrow. They need to assure everything appears realistic and cohesive.

Day 5: Friday -- Observe Customer Reactions (and Learn!)

Day 5 is when the real fun begins – you get detailed and authentic feedback from real customers.

The five people you recruited on Day 1 have shown up to test the product/prototype.

It's best to bring them in face-to-face to test the product in person if possible, though videoconferencing can suffice in some cases.

Identify "The Interviewer" on your team – this person will interact one-on-one with your customer, who is testing the product.

The rest of your design team observes customer reactions via live video in a separate room.

The Interviewer asks the customer different questions (you should write a script):

  • What do you think about what just happened?
  • How would you compare the different options?
  • What worked?
  • What didn’t?
  • Would you buy this?

CRITICALLY -- The team observes customer reactions, rather than listens to feedback.

This ensures that the insights they glean are as honest as possible.

By the end of this observation, you should be able to see patterns.

You'll know what's working well and resonating, and what's confusing and what people don't care about.

These insights answer some of the larger questions posed at the beginning of the sprint and inform the direction that the team will head in next.

This knowledge is extremely valuable and gathering it now will save you an incredible amount of time and money later.

What does this mean for you?

Design sprints are an essential tool that entrepreneurs can use to fail fast, rapidly iterate and grow quickly.

For me it's part of my year-long exploration of how to best 'experiment' in building my businesses, products and services.

Working in a group environment successfully is difficult and, as Jake mentioned, A crucial, but overlooked, part of the design process is designing the way in which we work together.

The structured design sprint process enables teams to operate in ways that are effective in gleaning real, actionable insights about what works and what doesn't.

It empowers individuals with crazy ideas and also squashes ideas that aren't validated by customers.

If your team is grappling with whether to launch a new feature or product, it's worth giving a design sprint a try.

You'll be amazed by the results.

Join Me

This is the sort of conversation we explore at my 250-person executive mastermind group called Abundance 360.

The program is highly selective. If you'd like to be considered, apply here.

Share this with your friends, especially if they are interested in any of the areas outlined above.

This blog is part of a series I am doing on "Hiring, Culture, and Experimentation." If you have questions or comments about these topics, tweet at me @peterdiamandis and @codyrapp, and we'll incorporate them into our research.

P.S. Every week I send out a "Tech Blog" like this one. If you want to sign up, click here to sign up for this and Abundance Insider.

P.P.S. My dear friend Dan Sullivan and I have a podcast called Exponential Wisdom. Our conversations focus on the exponential technologies creating abundance, the human-technology collaboration, and entrepreneurship. Head here to listen and subscribe: a360.com/podcast

Head here for the full archive of my latest tech insights