5 reasons I love design sprints
This story is for everybody interested in lean product development practices and design sprints. It doesn’t specifically explain the methodology but I’m planning to write about it in the future.
There is no product that is perfectly complete and solves the right problems in the right way. As Mark Manson elegantly writes in his brilliant book The Subtle Art of Not Giving a Fuck , everything will be disproven and wrong in the long term. Improvements come from failures and you should get used to being wrong. However, when you keep iterating your product based on user feedback, eventually, you will be less wrong.
After an exhausting five-day design sprint in eAgronom, I felt ecstatic for having had the sprint processes guide us through the uncertainties. Instead of group brainstorming and arguing over who believes in what, we were doing the thinking individually, sharing ideas to the group, stealing each other’s ideas, and dot voting. We arrived at a prototype and it was tested on five users on Friday.
Our journey to sprints
We’ve always built eAgronom based on user needs and feedback. From day one, we have tested prototypes before single line of code was written. We started using design sprints when the jobs the users were asking us to do required more brain power than just the designer’s. When even your users don’t know what they want, your best hope is to come up with a prototype and learn from it together with your users.
Our initial playbook for design sprint was the book “Design Sprint: A Practical Guidebook for Building Great Digital Products”. It has exercises for each day of the design sprint, approximate time schedule for each task, specific guidelines and tips, etc. — all very helpful for a starting design sprint facilitator.
As the book was hard to follow during the sprint itself, we started using the online Google design sprint kit to have quick a overview of the tasks we need to do at each step. Only later did I learn that these steps were based on the initial Google design sprint playbook Sprint by Jake Knapp. The flow of exercises made more sense to us than the order of exercises in the Design Sprint.
The current sprint we’re running is based on a combination of exercises from all the resources. While we’ve mostly run 5-day sprints, given the complexity of the problem, you could do it in 3–4 days as well. After three years of running sprints, I’m eager to share why I believe design sprint is one of the best tools in a product manager’s toolbox.
1. Farmers first
The sprint focuses on the user (in our case, the farmer). The week begins with writing down the sprint goal and exploring the problem space through the eyes of the farmer. We write down the jobs, get input from experts, read user feedback and requests, study existing solutions, etc. Our focus is to find the best solution not how we are going to achieve it.
Once we’ve identified the main jobs we have to do for the farmers and narrowed down the goal of the sprint, we use sprint exercises to find solutions to the jobs. During the sprint, everybody is reminded to let go of their own ideas and beliefs. On Friday, we invite five farmers to the office and put the prototype to the test.
2. Iterate
In farming, there are as many solutions to business needs as there are farmers. Moreover, their practices are often not the best ones, so there is a lot of confusion and conflicting input. Sometimes the projects stay in research phase for months. The endless analysis that comes with modelling real life needs is paralyzing. In the complex maze of needs, coming up with a prototype is often a surmountable problem for a single researcher.
During the sprint, the complex domain is analysed by a lot of diverse brain power. Developers are great at detecting patterns and defining problems. The decisions are made without arguing and the hypothesis about the world are written down. The uncertainties are handled by the setup of the design sprint and you can always trust the process to give you answers by Friday evening.
In one week, you will have a working prototype that is tested on real customers, the whole team is on the same page, and you’ve saved weeks of arguing over what is wrong and what isn’t.
Sometimes the users completely destroy the ideas you have prototyped. Surprisingly, that’s actually a positive result: you have learned what not to do, saved hundreds of dev hours and a lot of unnecessary cost. More often, though, you’ll get both — some positive feedback as well as constructive criticism — which then kickstarts the iterative process of the following weeks. Sometimes the hardest part of a project is the beginning. Once the lean design process is rolling, you’ll arrive at the initial development version within weeks.
3. Focus
On a usual workday, I have several meetings, a lot of pinging in Slack, hustling, prototyping and even coding. The whole sprint week, however, focuses on a single project. There is no context switching. No devices, no meetings.
If you’re used to flexible working hours then working from 10–17 might seem intimidating at first. On Friday, however, Monday seems weeks ago. You’ve learned a lot and it’s always been worth it. The six hour daily schedule for a week on a single project not only makes everybody feel accomplished but also gets your project started without falling into analysis paralysis.
4. Whole team in the process
We hire only developers, designers and researchers who are driven by our mission, seek freedom and responsibility, and yarn for a better version of their professional selves. Everybody must know why they are doing something and are pushed to come up with the best solution in their area of expertise. For example, developers are allowed push back prototypes that haven’t been tested on users and shouldn’t write a line of code without knowing the problem setup behind the solution.
The design sprint is matching this pattern perfectly. We run design sprints with all the people who are going to be part of the project. This usually involves 3–4 developers, a designer, researcher and product manager. On Monday, the whole team gets on the same page with the research input and the problem setup. On Tuesday, the problem space is defined and explored further and initial ideas written down. Ideas are sketched and prototyped with the whole team in the middle of the week. On Friday, while the farmer and the interviewer are in one room, the rest of the team is watching the process and taking notes in another room via intercom.
Here are some of the reasons why it is great to have the whole team in the sprint:
- Increased motivation as everybody knows the user needs and why we do the project
- Speeds up development processes as you don’t have to explain the project to the team anymore
- More ideas to work with during the design phase
- Engineers knows the big picture and can start thinking about the architecture way ahead to avoid going to the wrong direction
5. Team building
We’ve run the design sprints in the office, in somebody’s home and at rented cottage house. The main idea is to be in one room with the whole team. Uninterrupted, present, timely and focused. It’s not often that the whole team is working together like that. During the exercises and daily retros, you will discover each other’s strengths and weaknesses. Include the working on the common goal, lunches, and beers in the evening (sometimes even sauna), you’re gonna have a week-long team building event.
eAgronom has three cornerstones: farmers first, iterate and focus, and be frank. Design sprint represents the things we love about our culture: user-focused, iterative, and focused.
If you liked what you read, please leave a clap!
