The founders and designers we work with in the Google Ventures portfolio have a lot of important questions. Is there a market for my product? Will my product help people solve their problems? What should I build? The answers to these questions just raise more questions: Do people understand my product? Will people find my product useful? Can people use my product? And so it continues. As we build our businesses, each answer reveals new unknowns.
User research is a fast, reliable way to answer important questions like these. It’s the best way to test assumptions without the time or expense of launching. It reduces risk and helps your team work more quickly and more confidently.
And best of all, you can start doing user research in just a few days. We’ll show you how. (You can also jump straight to the day-by-day guide here.)
Research makes great design possible
At Google Ventures, we help startup teams use design to answer questions and make important decisions about their businesses and products. We like to use design sprints, our own battle-tested process for prototyping and testing ideas rapidly. But design sprints depend on research, so we’ve optimized a research process that provides maximum learning as quickly as possible.
It’s called a research sprint, and we’ve helped more than 100 startups use this process to learn more, make better decisions, and move faster. We’ve optimized mobile-app registration, improved e-commerce conversion rates, made dense medical data clear, explained new products, and much more.
In the next four articles, we’ll provide a complete guide to running your own research sprints.
Why research sprints are so important
Most startups know that they don’t have all the answers, so they rush to launch things and see how they perform in the real world. This is a very high-fidelity way to answer questions, but it’s hard and slow.
Here’s the ideal “launch and iterate” model that’s popular in Silicon Valley:
But in practice, it’s a tough way to operate. You may start with a bad idea (obviously you don’t know it’s bad yet). Building it takes longer than expected — it’s tough to fix all the bugs, make sure it works in production, and get the details right. It’s difficult to “un-launch” a feature, especially once you have people using it. Real-world results are rarely as clear as you hope. And there’s always the temptation to move on to the next shiny object instead of diligently iterating on the original idea.
At Google Ventures, we use design sprints to invent and prototype ideas. Research sprints are an essential part of this process — it’s how we test our ideas without the time or expense of launching.
In the time it takes to build and launch a new product or feature, you can run several research sprints and improve your prototype after each one. Instead of launching something that might not work, you’ll have confidence in the solution you’ve refined through research.
Then you can invest the time to build and launch your product or feature the right way. It’ll reduce risk and save time in the long run.
What can you learn from research sprints?
Research sprints are not a panacea. They won’t help you learn how many people clicked a button, where your website traffic is coming from, or how to structure your database. But research sprints can help you answer some of the toughest, most important questions that startups face:
- What problems, needs, and motivations do people have?
- How do people evaluate and adopt products?
- Do people understand your product’s value proposition?
- Which messages are most effective at explaining your product?
- Can people figure out how to use your product?
- Why do people stop using your product?
- Why don’t people adopt new features when you launch them?
There are many more questions we can answer with research sprints, but I don’t want you to get bored and leave.
Components of a research sprint
There are five essential components of a research sprint.
1. A set of questions and assumptions. Without these, you’re not making the most of your effort. Before starting the sprint, everyone on the team should agree on the questions you plan to answer and the assumptions you plan to test.
2. Intentional and selective recruiting. You’ll need to carefully recruit people based on your goals: existing customers, prospective customers, representative customers, etc. In other words: Unless you’re building a product for Starbucks customers, you shouldn’t randomly conduct interviews with people at Starbucks.
3. A realistic prototype you can test. You can learn a lot by listening to people, but you can learn way more by seeing how they react to a realistic prototype. The more realistic, the better — you want people’s real reactions to what you’re building, not their abstract thoughts or smart-sounding feedback. (Check out some real prototypes we built in one day each.)
4. Five 1-on-1 interviews combining broad discovery questions with task-based evaluation of a prototype. 1-on-1 interviews (in person or remotely) are the best-bang-for-your-buck type of qualitative research. You’ll learn from facial expressions, gut reactions, and body language. You can ask follow-up questions and follow interesting tangents. Why five? It’s easy to spot patterns, and you can do five 60-minute interviews in one day. (Plus, Jakob Nielsen approves.) We’ll help you write an interview guide that keeps you on track during the interviews.
5. Real-time summarization of findings. One thing that slows down many forms of research is the analysis — it can take days or weeks to extract findings from the data. In a research sprint, the entire team watches the interviews, takes notes, summarizes the findings, and decides on next steps before heading home for the day.
The four days
As promised, a research sprint takes just four days. We’ve written up a complete, detailed guide to each day.
Let’s go!
In the next four articles, we’ll explain in detail how to recruit and schedule research participants, create an interview guide, set up a lightweight research lab, and interview customers. You’ll be running your own research sprint in no time. Let’s get started with day one.