Launch better products in 5 days: Part 2 of 4
In the first article of this series we introduced the framework for running design sprints — a 5-day process for rapidly creating and testing prototypes with your customers.
When people think about design sprints, they may imagine these are practices only large, profitable enterprises make use of. However in this article, we’re going to profile a startup called Zubia that we supported, to demonstrate how startups can also take advantage of sprints.
Background on Zubia
Zubia has been working on solving a problem they spotted— there are communities that exist around certain healthcare related topics; e.g. autism, cancer.
Within these communities there are generally two types of people: those challenged by those topics (we’ll call them consumers) and those offering expertise and/or solutions to those topics (we’ll call them creators). What Zubia realized is that these consumers and creators had little means of meeting to learn from and support one another.
A couple years ago, based on what they knew, Zubia spent several months and a decent chunk of cash to launch a web-based platform to help bring these communities together. However the reactions they received from potential customers and investors indicated they’d gone down the wrong path. Zubia would need to throw away most of what they’d built and start over. This was when we became introduced to their founding team.
Running blind vs. running smart
When we first met the team at Zubia, they were gearing up for their next, and likely final, attempt to launch a viable solution. The founders were meeting with app developers to determine technology budgets of a new solution they had in mind. This approach, however, was flawed from the outset.
The idea of building a lean startup, on your own, or within a corporate, is typically associated with running lean by building MVPs. With this approach, you build based off of your team’s ideas and assumptions with the plan to test with your customers in a production environment. However, most MVPs require several weeks + the associated cash spend. That means, by using your MVP to learn and pivot, you’re accumulating a ton of debt on a problem that may not even be worth solving. No wonder angels and seed investors are wary.
So we pushed back on Zubia’s request for a proposal because it was based on speculation and guesswork. Instead, we suggested a design sprint.
In the span of 5 days, both teams would be able to learn together, while validating (or invalidating) our team-wide hypotheses. In addition, it would also provide us with the info needed to, not only define a Product Roadmap (including budgets + timelines) for the Zubia team, but confidently begin to tackle all of the work that follows a design sprint.
Zubia agreed to the approach. In 1 week, they would have a team that was educated around the problem and empowered to make decisions about the solution. They would also have their proposal, except this one would be rock solid.
Realistic logistics of a sprint
As it turns out, not everyone that will be part of your sprint will live and work in the same building, city, or country. For example, the Zubia sprint was going to take place in Manhattan however the people participating were coming from Europe, Florida, and New Jersey. Travel and accommodations needed to be planned and paid for well in advance.
Meeting locale
We decided to meet in NYC. We chose WeWork. We reserved 1 of their 10-person conference rooms from 8am — 6pm for an entire week. We made sure the room came with at least 1 whiteboard.
We Work was accommodating but having a dedicated space for the entire day allows you to work outside of the core sprint hours (when necessary), as well as not having to worry that another team would erase / disrupt all of your thoughts, sketches, notes, etc.
Supplies + fuel
We stocked up on the supplies we’d need. We also coordinated our breakfast and lunch schedules for the entire week, in advance.
The less we had to think administrative items, the more we could concentrate on the sprint. And when all else failed, WeWork has a small kitchen stocked with drinks, healthy-ish snacks and caffeine (and beer).
Running the Zubia sprint
We followed the 5-day blueprint for running the Zubia design sprint.
Day one: Prior to, the challenge we selected asked the question “How might healthcare communities come together to discuss important topics?” We then unpacked our understanding of this challenge by mapping out the journey of those people impacted by such a challenge.
Day two: Building on Monday’s session and a brief round of lightning demos, we sketched solutions. We heard the usual concerns from founders, like “But we’re not designers.” We assured them that the point of the exercise was to get visual ideas down on paper that could then facilitate discussion.
Day three: We started by voting on our favorite solutions. Afterward, we took the most up-voted solution and added in details that were overlooked, fuzzy or missing altogether to create a storyboard.
Day four: We turned our storyboard into a prototype — a mobile app consisting of nearly 30 screens.
We used Sketch to create the mocked up screens and then stitched it together into a navigable prototype using Marvel. (Note: during later refinements of the prototypes we’d port the app into our design collaboration tool of choice, InVision).
Day five: When it comes to customer testing, it’s ideal to do the interviews in-person. But it doesn’t always work out that way. In the case of Zubia we used Hangouts and Skype.
We lined up several customers from each of our consumer and creator groups and spent the day questioning, observing, and capturing. Our prototype received the validation needed to confirm the Zubia solution we next intended to take to market.
Design sprint ROI
We understand that sound cash management is rule #1 in every startup. That’s why one of our immediate goals when kicking off with a startup is to prove the outright value of the sprint. With Zubia, the ROI came on day one…
The Zubia team had always assumed that the practical and socially responsible avenue for making money would be to charge the creators a subscription fee. However, in the opening hours of our sprint, we discovered one undeniable obstacle with that monetization approach — the addressable market of creators is far smaller than those of the consumers. Instead, we agreed upon testing a hybrid payment solution.
Spotting this problem on day one enabled us to include it in our sketches, prototype and customer interviews with both user groups. The feedback received was ultimately critical in helping us decide upon the actual payment options the actual Zubia app would offer.
What next?
After one jam-packed week, we were able to help Zubia put a 12-month product roadmap together. This roadmap provided them with all of the user stories (features), budgets, and timelines in order to bring their validated MVP to market. Armed with this information, the founders were able to green light the development of their MVP which we’re now all busy working to launch.
Reactions from the founders
“The design sprint which New Haircut orchestrated helped to translate the ideas of our application into an actual prototype, which they are now developing into our MVP. We were exceptionally impressed with the approach and the fast pace at which we worked together to maximize the elements of the sprint and the delivery of the finished product.”
In the next article in this series, we’re going to focus on team dynamics within design sprints. We’ll start by providing you with options to excite and engage your existing team about running a design sprint. Then we’ll help you gather the team players required to run an effective sprint.
