Are you building products without knowing if anyone will use it? Are you finding it takes forever to do market validation? 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 to see if they would make great products.
At Retina, we developed and tested a new design sprint framework that would:
“Effectively validate our product ideas in the most efficient and expedientway possible”
And thus the 3 day Tech Sprint was born!
For those in a hurry, here is what we did, so you can do it 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, as outlined in the book Sprint by Jake Knapp. Knapp created a strategy to go from an idea to a validated prototype in one work week. 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.
A speed run does not mean a drop in quality. 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.” Here is the basic outline:
- Tiny sticker
- Big stickers
- Facilitator: Manages time, conversations, and overall sprint process
- Decider: Someone who will have the final say on every decision. They make sure 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 the process laid out by Knapp. We also wanted to adapt it to better fit our team and time constraints.
Reasons for adapting:
- Knapp’s Sprint is built upon the assumption that the participants of the sprint do not know each other or know the problem space well. We are Retina knew each other and space relatively well, so we could skip these sections.
- Doing this in 3 days ensured that we could focus on the Sprint material. At a Startup, it is easy to context switch to put out the immediate fires, but if we made this change, we could carve out enough time to stay focused.
- We also worried that 5 full workdays on a problem might actually cause too much fatigue amongst the group. We believed that in 5 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
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. For 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” brainstorm. During the interviews with experts, whenever you identify a problem — whether an expert mentions a customer pain point or you notice a potential shortcoming of your product— reframe with problem as an opportunity, with 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.
The afternoon sessions are about creating potential solutions that emerge from the problem space
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. Spend 1 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
First, have everyone brainstorm on 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.
The afternoon is then spent building the darn thing as quickly as possible.
Also 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. 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 Knapps. In no particular order, here are a few lessons that come to mind:
Pro: Our Framework really did validate our ideas in 3 days
We were able to take our learnings from just 3 days of work and build a product that we were confidentour 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 with 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 — 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 really great. It helps facilitate productive discussion quickly, and surfaces important information. 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
One thing we saw was that even for our small Sprint group (3 people) we struggled to fit voting within the time constraints of what the book outlined. We found that during the voting session, everyone wanted to voice their opinion on every prototype. If we had had 7 people discussing 7 prototypes, that would have meant 49 combinations, which could take a lot of time.
Con: Business focus is not baked into original framework
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: Comradery was at an all time high
I think the most important lesson was that the 3 day Sprint built a powerful comradery between those involved in the Sprint Team. 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.
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]