A design sprint is a framework perfect for helping startups answer business questions. It’s a process that spans five days. In that time, you brainstorm, prototype and test ideas with real customers.
First developed inside Google Ventures to test products and services before bringing them to market, the design sprint is a time-constrained process that requires you to set clearly defined goals and answer specific questions before starting any product development. The whole process is very similar to the sprints developers have in the agile software development process, including the iterative nature of the whole approach.
This process was explained by Jake Knapp in his book Design Sprint after working for 10 years in Google and Google Ventures. In the book, he offers a formula of the process. Once this process becomes a habit, you don’t have to worry about running into the same problems over and over again. Even your biggest problems can be broken down into small steps that can be tested one by one. With the design sprint, you don’t have to wait for the perfect moment with the perfect set of features — you just need to get started.
Let’s see what this five-day process look like in closer detail. I’ll use a time tracking app that my team is building as an example — after all, one of the reasons my team started building this app was creating a startup that we can write about. Unlike the projects I worked on in the last 15 years, there are no outside stakeholders and no NDA.
Monday: Understand the Problem
When you have an idea for a product, you need to understand your audience, the problem you are solving, and the value you are going to provide before you take further action.
So first, write down your assumptions, no matter how arbitrary they might be.
For my app, my assumption is that my audience is software development teams, and the value of the app is in providing a simple way to track time with a clear UI and integrations with the most popular software developers are using. The main question that I want to answer is this: Do software development teams really track time, and will they be willing to use an app like the one I want to build?
The biggest risk in this case is that the app won’t be interesting to my audience; I launch the marketing campaign, the click-through rate for the app is low, few people visit the landing page and none of those who do even want to try out the app.
Tuesday: Look for Solutions
The best thing about the design sprint is that there’s no time for overthinking. There’s just one day to identify the problem at hand. On the next day, you need to start looking for a creative way to answer this question as quickly as possible.
It’s important to list all of the solutions that come to mind, no matter how unrealistic they may be. For a new product like mine, I can visit the offices of development teams to talk to them and observe how they approach time management (if they even do). I can run a focus group with developers. Or I can build the app and start marketing it.
Don’t just think about the solution on your own. Invite other people who have experience launching products to work with you on this phase. The more people you work with, the wider your range will be of possible ways for reaching your goal.
Wednesday: Storyboard
It’s time to put all of the ideas on the board to see which you can realistically bring to life in just one day. The time constraints of a sprint force you to focus and prevent perfectionism.
I can’t realistically visit many development team offices in just one day. I won’t be able to create a decent prototype of a time-tracking app in a day, either. I could do a focus group, but they seem to be quite expensive, and I don’t know enough about them to get one right the first time.
So I have to focus on doing a marketing experiment. In one day, I could easily create an ad and a landing page to send people to. I could use some semi-random name to keep the brand in secrecy for now. Once people would sign up, I’d offer them to join the waitlist and be notified once the app is released.
This is the least I can do in just one day to answer my question — if development teams would want to use the time tracking app I’m building. This experiment won’t tell me anything about pricing or a feature set. It will just show me if there’s a demand, which is perfectly fine. I can run another experiment to answer other questions I have.
Thursday: Build
With just one day to build something, perfectionism is not an option. I don’t have a lot of time to read about how to build the perfect landing page or ad — I just have to use whatever I have at hand. Luckily, there are plenty of templates and examples both for successful ads and landing pages.
Will the ad and landing page work long-term? Probably not. The CTR wouldn’t be great, and landing page conversion wouldn’t be perfect either. But if I’ll get at least some people to sign up for the waitlist, it’ll be something. I’ll see that there is a demand, and I’ll be able to tweak everything else later.
Friday: Test
The moment of truth! No matter how scared you are, you have to actually run a test with real people. Even if the result isn’t great, it’s still a result, part of the learning process.
In my case, I got some pretty interesting results. Even though an ad had the copy targeted at project managers working with development teams, most of the people who signed up were freelancers from other professions — marketers, designers and content creators.
I still need to re-evaluate the results of my design sprint and run another one. But I’ve learned a lot so far through the process.
Have you used the design sprint (or a similar approach)? What do you think about the concept?
Originally published on Medium
