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
- Tiny sticker
- Big stickers
- 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
Objective: Come up with potential prototypes to build
Objective: Pick a Prototype
Objective: Build a Prototype
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:
- 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.
- 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.
- 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:
- Spend 20 minutes silently collecting your thoughts based on what you’ve learned
- Spend 20 minutes privately jotting down some rough ideas
- Choose the best from above
- Fold a sheet of paper to create 8 frames. Sketch your best idea from above as a user story, spending one minute per sketch
- 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!
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.
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]