Delivery vs. Innovation: How We’ve Used One-Day Design Sprints to Improve Setapp
Release day. The most exciting part of any new venture. The day when all that hard work is realized.
The scope is defined and product roadmap prioritized. The development team is firing on all cylinders, and the marketing is on point. Everyone from the admin assistant to the stakeholders believes in the plan. For you, as Product Manager, this is your big moment — a chance to bask in your glory.
But then the release happens… And nothing. No rush of new customers, no new leads, no viral social media response. Nothing.
Customers you spent months interviewing are no longer interested in your product. And the numbers don’t lie: your funnel is a failure. Reality does not match up to expectations. The whole thing is a flop.
In my experience as product manager for Setapp, the first release never goes according to plan. Something always goes wrong. The reason? I call it the “planning trap.”
Instead of being focused on reaching goals, you get stuck on the first plan and ensuring everyone sticks to it to push through delivery. The problem is, the first plan is rarely ever right. Like Ernest Hemingway said: “The first draft of anything is sh*t.”
If the plan is weak from the get-go, the product you develop isn’t going to be right for the customers, resulting in failure that costs your business more money in the long-run.
As a product manager, it’s my job to meet goals and ensure the team is aligned to do the same. Because product management isn’t just about delivering features, it’s about reaching set goals. And doing so as a team.
At MacPaw, we’ve been able to shift the team’s mentality more towards innovation and reaching business goals; minimizing potentially costly redesigns without completely losing sight of delivery. We’ve achieved this by introducing design sprints.
A design sprint is a framework offered by Google Ventures that helps businesses reach goals and increase learning, quickly. The process promotes innovation, user-centered thinking, and brings teams together with the same vision.
By implementing design sprints in your own organization, you’ll be able to:
- Shift the focus of your team from “what we do” to “what we want to achieve and what is the fastest way to get there?”
- Find it easier to deal with uncertainty. You’re not the person with all answers, but you do know what problems need to be solved
- Find a place for innovation and creativity in a delivery-focused environment
At MacPaw, we’ve always dedicated every second Friday of the month to learning something new, working on pet projects, and solving real product challenges.
More recently, though, we’ve taken one of these Friday’s and turned it into a design sprint named “Setapp Labs Day.”
Now, the problem with the Google Ventures framework is that design sprints are designed to run over five days. We only have one. So we’ve modified the framework to suit, allowing us to still reap the benefits of the process without committing a full working week.
Design sprint expectations
When implementing design sprints, there are a few things we wanted to get out of the process:
- We wanted the team to re-focus on problems that were out of the scope, but were critical to a product’s success
- Recently, we had some organizational changes. Design sprints allowed us to create cross-functional teams, bringing together different minds from different functions to work on solutions
- We wanted the team to get closer to our customers. Before Setapp Labs Day, only people directly related to the product team seen the people paying for it.
In putting together design sprints of your own, it’s important to define what you want to gain from the process before implementation.
Creating the right environment
We understood early on that if we wanted the team to come up with new and innovative ideas, we had to create the right environment.
This was done with the introduction of the following five rules:
- Only one interesting problem for the day. We believe that you can only be effective if you are focusing on one thing at a time. Although time is limited, multitasking hinders performance, so we set out to avoid it.
- The team for each problem should be as diverse as possible. Ideally, we wanted our team members to work with those they have never worked with before.
- The schedule should be tough and prototypes should rough. No time for coding. No time for designing.
- Customers should be involved. We wanted our team to collaborate on solving real-life customers problems.
- Demo at the end of the day. Each team has to showcase their work, regardless of how advanced or polished it is.Recipe for success
To make maximum use of the limited time available, we worked to ensure design sprints were a truly collaborative process from the outset:
- We asked the team to share problems they thought were critical to the success of Setapp, with one condition: solve problems that are not currently in the backlog.
- Problems are evaluated, analyzed with data, and narrowed down to a list of three. These are then pitched to the team by the product team
- People from other products are invited to participate in the day to bring a fresh outlook and new ideas
- Participants are asked to choose the problem they want to solve. No pressure — just whatever they feel is important
- Customers from all around the world are invited to participate in the day via Skype
- Customer interviews are regarded as a mandatory part of the day
How a Setapp Labs Day looks
As you can imagine, modifying a five-day process to fit into a typical working day isn’t easy, and the schedule for design sprints doesn’t leave time for procrastination.
- 10:30 a.m. Participants come to the office. Enjoy a much-needed morning coffee and make any last minute preparations
- 11:00 a.m. Kick-off talk. Reminders are issued and conditions of the day clarified. Teamwork begins
- 1:00 p.m. First customers are introduced to the day via Skype. Teams test prototypes with them
- 2:00 p.m. Setapp Labs Day status meeting. Teams gather to share concerns and challenges. This is a quick-fire discussion before teamwork gets back underway
- 4:00 p.m. Second group of customers are brought in on via Skype. Teams test their ideas again
- 5:30 p.m. DEMO time. Teams share learnings, new ideas, and showcase prototypes
Setapp Labs Day was, and continues to be, a success. The inaugural design sprint resulted in:
- Two bold product ideas being added to the backlog
- Customer communication tone of voice was reviewed and a new look and feel of transactional emails introduced
- Team morale was through the roof! “Why don’t we work like this every day?” was a common theme amongst participants
- An “Experience team” for one of the core experiences inside the product was created as a test. This team is a small group of cross-functional professionals with the authority to maintain experience gained during Setapp Labs Day
What we learned
Nothing groundbreaking was learned during Setapp Labs Day; however, the day provided a stark reminder of how goals are important, and how collaboration is key is creating positive results.
Some things we’ve taken away from design sprints:
- To make sure that your team invests their efforts in the best way possible, they must be clear on what is the priority. Tell them what problem to solve
- Product management is not all your own responsibility. Don’t tell teams how to do things, focus instead solving problems.
- Process and schedule matters. Polishing is too expensive. Promote the problem, not the solution
- Communicate results. Tell team members what happens to their ideas. Don’t rely on them checking a Confluence page.
- The process of how you build things is just as important as the thing you are building. Experiment with it.
Design sprints have helped us to create better solutions, faster than ever before. Solutions that are used, valued and promoted by the people that matter most: customers. Use our experience as the catalyst to create a “Labs Day” of your own and build a more successful business.