Tech Sprints Speed Runs: How to Validate your Ideas as Fast as Humanly Possible

Are you building products without knowing if anyone will use them?  Does market validation seem to take forever? If so, then this post about how we did a Tech Sprint Speed Run at Retina is for you.  But first…

“I feel the need… The need for speed.”

– Peter “Maverick” Mitchell, Top Gun 1986

– Me, 2 weeks ago during our Design Sprint

What is a Tech Sprint Speed Run?  It’s a framework for rapidly and efficiently testing new ideas in order to see if they would make great products.

At Retina, we developed and tested a new design sprint framework so that we could:

“Effectively validate our product ideas in the most efficient and expedient way possible”

And thus the 3 day Tech Sprint was born!

For those in a hurry, here is what we did because we want to make it easy for you to try, too.

We will cover:

  • The original framework
  • Retina’s Tech Sprint Speed Run
  • Lessons Learned – Pros and Cons

Speed is King

We based our sprint on Google’s format, which Jake Knapp outlines in his book, Sprint. Simply put, Knapp created a strategy to go from an idea to a validated prototype in one work week.  What’s more, he designed this to be applicable in virtually every business or vertical.

We decided to run Knapp’s 5-day sprint… in 3 days.

At a startup, we all know that speed is king. We put this to the test, and sprinted through a Sprint framework.  We lovingly dubbed this a Tech Sprint Speed Run.

Tech Sprint A set period of time during which specific work has to be completed and made ready for review.

Speed Run: From gaming: a session of play in which the goal is to finish the game or level as quickly as possible.

To be clear, a speed run does not mean work quality will drop.  Instead, we focus on getting the most valuable takeaways from the experience in a fraction of the time.

The Tech Sprint

Knapp says the goal of a Tech Sprint is to solve big problems and test new ideas in just five days.

What You’ll Need

The Supplies

  • Whiteboards
  • Paper
  • Pens
  • Tiny sticker
  • Big stickers
  • Food
  • Timer

The Cast

  • Facilitator: Manages time, conversations, and overall sprint process
  • Decider: Someone who will have the final say on every decision and ensures the Sprint keeps moving forward
  • No more than 7 people total

Monday: Goal Setting

Objective: End the day with a unified vision of what is the objective of the sprint

Tuesday: Brainstorming
Objective: Come up with potential prototypes to build

Wednesday: Deciding
Objective: Pick a Prototype

Thursday: Prototyping
Objective: Build a Prototype

Friday: Testing
Objective: Market Test Prototype

The book covers all of these activities in more detail.  It’s well written, and we recommend you give it a read.

The Speed Run

When we found this Sprint, we really liked the idea and process Knapp laid out. We also wanted to adapt it to better fit our team and time constraints.

Briefly, our reasons for adapting were:

  1. Knapp build his Sprint upon the assumption that the participants of the sprint do not know each other or the problem space well. We are Retina know each other and space relatively well, so we could skip these sections.
  2. Doing this in three days ensured that we could focus on the Sprint material. At a Startup, it is easy to context switch to put out immediate fires that may arise. But, we decided we could carve out three days to stay focused.
  3. We also worried that five full workdays on a problem might actually cause too much fatigue amongst the group. We believed that in five days things would move too slowly, and we would lose momentum by Thursday or Friday.

Here are the changes we made to the original Sprint:

Day 1: Map & Sketch

Objective: Learn about the problem space and sketch out solutions

Initially, the first morning’s sessions are about getting everyone on the same page about the problem space.

Start the day with introductions and a brief explanation of what the sprint entails. Afterwards, have a brainstorming session about where we hope this project will go in a year. By contrast, also define how this project might fail.

Talk with experts in the next session.  Let them define exactly how customers interact with your product and update your goals/fears accordingly.

Next is the key How Might We (HMW) brainstorm. During the interviews with experts, you’ll likely identify some possible problems. For example, an expert might mention a customer pain point or you might notice a potential shortcoming of your product. When this happens, reframe with problem as an opportunity, using the preamble: “How Might We…” Right before lunch, the team votes. and the Decider decides which HMW card will be the focus of the sprint moving forward

You should also schedule interviews with relevant users for the last day of the sprint. Aim for 5 users in total.

Day 1: Afternoon

The afternoon sessions are about creating potential solutions that emerge from the problem space.

In order to get a complete picture, start with getting a short demo of all solutions within your area of interest, including your own. Afterwards, decide which part of your map you will address in your sprint. Collect your thoughts and iterate through a few versions of potential prototypes. The process for this is laid out as follows:

  1. Spend 20 minutes silently collecting your thoughts based on what you’ve learned
  2. Spend 20 minutes privately jotting down some rough ideas
  3. Choose the best from above
  4. Fold a sheet of paper to create 8 frames. Sketch your best idea from above as a user story, spending one minute per sketch
  5. Spend up to 90 minutes creating a storyboard of your best user-story. It should be self-explanatory

Day 2: Vote & Build

Objective: Pick a prototype and build it

The Day 2 morning session is when the team votes on a prototype to build.

Initially, have everyone brainstorm prototype proposals which could implement the story from Day 1.  The group then votes on aspects of each prototype they like, creating a heat map of good ideas across all prototypes. After voting on aspects, the pros and cons of each prototype proposal are discussed, and everyone in the room then picks their favorite. In the end, the Decider takes in all the votes and picks the prototype to move forwards with.

After the prototype is chosen, create a storyboard describing the prototype to build.

Then, spend the afternoon building the darn thing as quickly as possible.

Finally, be sure to write an interview script for Day 3 interviews with users.

Day 3: Test & Validate

Objective: Market Test Prototype

Day 3 is about getting feedback on your prototype.

Conduct each of the 5 scheduled interviews with users, showcasing your prototype.  Collect your notes and look for patterns in the responses. For example, do they all like a certain aspect? Do they ask the same clarifying questions?  Make sure to use open-ended questions, and to allow the user to explore the prototype on their own.

After all this, you will know if your idea—manifested in your prototype—is worth pushing forward on!

Lessons Learned

There were plenty of Pro and Cons to both our Tech Sprint Speed Run and Knapp’s. In no particular order, here are a few lessons that come to mind:

Pro: Our Framework really did validate our ideas in three days.

We were able to take our learnings from just three days of work and build a product that we were confident our customers would use. We got everything we wanted out of a Sprint in a fraction of the time!

Con: Keeping up the Speed Run pace requires additional work and coordination

The pace of a 3 day tech sprint is exactly what you would expect— REALLY FAST. Every day was chock-full of activities and brainstorming sessions. As Facilitator, I had to fight to keep us moving along at the outlined pace.

Pro: The last day is incredibly rewarding and informative

I really enjoyed Friday. I think it was amazing to see which parts of the prototype resonated and which did not. There was no guessing or gut-feelings about what would work— we were seeing what people would absolutely use. Our validation question was not “Would you use this product?” — because most users try to be nice and say they might. Instead, we asked “Would you pay for this product when we finish building it in a month?” If they said yes, we were sure we had product-market fit. If they wavered or said no, we knew we missed the mark.

Con: Building a realistic prototype is hard to speed up

We struggled to build a realistic prototype within in the two hours specified in Knapp’s Sprint.  We were trying to prototype a new product, and it might have made sense to try to focus on smaller features of an existing product.

Pro: The voting process facilitates high quality discussion

The voting process outlined in the book and used in our sprint is great because it facilitates productive discussion quickly and surfaces important information. Furthermore, the heat map voting helps people articulate their likes and dislikes about specific ideas, and visualizes how the room is feeling.

Con: Voting process may not scale to a larger team

Even for our small Sprint group (3 people) we struggled to fit voting within the time constraints of what the book outlined because everyone wanted to voice their opinion on every prototype.  Hence, if we had had 7 people discussing 7 prototypes, that would have meant 49 combinations, which could take a lot of time.

Con: The original framework does not include business focus

One shortcoming we found in the Sprint was the lack of business focus.  When brainstorming, not all of the ideas were aligned with company strategy.  Technical feasibility was also not considered, which could lead to impractical product ideas.

Pro: Camaraderie was at an all time high

I think the most important lesson was that the three day Sprint built a powerful camaraderie between those involved in the Sprint Team.  That’s because the focus of working intensely for several days on a single project really helped the team come together, and pushed everyone to be their best.  I found it similar in effect to a Hackathon, one of my favorite activities.

Conclusions

Ultimately, the Tech Sprint Speed Run was an adrenaline rush of productization, iteration, and conversation. Despite the insane pace, it was very enjoyable to do so with compatriots, and the capabilities of this framework (both Knapp’s and Retina’s) to produce validated MVPs is phenomenal.

If you are interested in talking more about this sprint drop me a line at [email protected]