4 Days to Design a Product People Will Actually Use
“It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.”
— Steve Jobs”
Like any good Product Manager or business executive, you probably have no shortage of ideas on what features and functions you could build into your product next to meet your user’s needs. On the other hand, I have also spent large amounts of time and money on building features and enhancements into my products that ended up dramatically missing the mark for my users.
Have you ever experienced something similar? For me, it meant weeks of meetings, months of engineering work, hours upon hours of product requirement gathering - only to have the product killed by a lack of use and missed expectations.
I'm Not a Mind Reader
The frustration of building things that end up never seeing the light of day causes me to dream of “mind reading” super powers. If only I could step into the user’s head and see exactly what they want!
A better checkout experience? You got it!
Clearer navigation instructions? Done!
Automated workflows? Here you go.
Steve Jobs cunningly observed the conundrum we often experience in trying to read the user's mind. What if the user doesn’t even know what they want? In the movie Jobs (2013), Wozniak lashes at Steve saying, “Nobody wants to buy a computer. Nobody!” To which Steve Jobs famously responds, “How can somebody know what they want if they’ve never seen it?” As a user, I’ve found this to be true! I once was convinced that the iPad was ridiculous in nature. It was an accessory bigger, more fragile, and less connected than my iPhone. As a computer, it was slow, limited, and difficult to use. Why would anyone buy this?? Yet here I am, typing this very blog on an iPad. I am not using my iPhone to compose a long form blog entry! Too small of a screen, and I need multiple windows open. I of course could have pulled my Macbook out, but I left it at home. Why haul that around when I just need my iPad?
I would have never wanted an iPad, until I saw it, held it, used it. Now I couldn’t imagine my life without this beautiful piece of screen.
How does the average product manager like myself become more like the all knowing, all seeing product manager god, Steve Jobs?
Design Sprints
I need to share with you all something that has literally changed my life.
Common sense says not to build things that won’t be used.
Agile and Scrum says, build nothing but what the user wants.
Steve Jobs says, the user doesn’t always know what they want!
Jake Knapp, author of Sprint: How to solve big problems and test new ideas in just five days, says, Design Sprint.
Design Sprints are a step by step process for solving big problems and validating ideas in just 4 days. You don’t need pages of product requirements, a team of expensive engineers, hours of meetings and discussions with no alignment. You just need two days with a few decision makers in your organization, a Design Sprint Facilitator, and 5 test users. That’s it! In 4 days you’ll know whether you should build or pivot, I guarantee it.
Relatable Problems
Design Sprints are a 4-day process for rapidly solving big challenges, creating new products, or improving existing ones. In 4 days, design sprint participants can save months of work!
How many of us have struggled aligning cross functional teams with common business objectives?
Who has ever been on a team that showed up day after day to work on a project with unclear goals and changing project scopes?
The lack of real data on which to base vital business decisions has become too common amongst teams. Instead of having something concrete, teams that I’ve worked with in the past have had to rely on endless internal discussions with zero resolve.
In today’s economy, product teams must be innovative to survive, yet the quickest way to kill morale is to apply that type of pressure on a team who doesn’t even know how to start.
Or how many times have we in the product world set out to build something in a month, only to have it stretch 2 more weeks, and then 2 more weeks, and then 2 more weeks, and then 2 more weeks, and then 2 more weeks, and on, and on, and on? The simple fact is that the traditional product development cycles run too long, causing teams to lose enthusiasm and focus.
As a product manager, I have time and time again been confronted with these all too familiar problems.
Ideation. Validation. Repeat.
At the core of Design Sprints is bypassing the build and launch stage of a product, and skip from the ideation stage straight to the validation/data stage. If the idea is validated, then you build, but don’t waste time and money building something that hasn’t been validated.
Let’s break this down into what the Design Sprint actually looks like.
Monday
Monday your team will define the challenge and produce a mess of solutions. I cannot tell you how many sprints I’ve facilitated in which the team enters the week with an idea of what the problem is and how to solve it, only to get to Monday and find they were dramatically wrong. The challenge ends up being more complex (or even more simple) than what was originally thought, or the path to a solution tends to be much more crowded.
Tuesday
As a Design Sprint Facilitator, Tuesday is my favorite day. It is when the team curates and votes on the best solutions to Monday’s challenges. Before everyone heads home for the day, the team will have a defined prototype storyboarded out in front of them. At this point in the game, the stakeholders in the sprint begin to see a viable path to success and are confident knowing the prototype came out of a playing field of real challenges and legitimately possible solutions.
Wednesday
Wednesday is usually left to the designers and the Sprint Facilitator. The stakeholders and decision makers from Monday and Tuesday get to return to normal work, while a high fidelity prototype gets built. This prototype will be as close to the “real deal” as time allows. The best prototypes look, feel, and act in exactly the way you’d imagine a fully engineered product to look, feel, and act.
While the designers are hard at work, other members of the design sprint team will be recruiting and scheduling user tests. These user tests will happen on Thursday and provide the data needed for the survival of ideas.
Thursday
It’s showtime. By Thursday, the challenge has been defined, a solution has been produced, a high fidelity prototype has been built, and it is now time to test the idea in front of real users. The data gathered on Thursday is most exciting for the product manager and business stakeholders. Without spending a dime on engineering, without having experienced a single moment of useless meetings and endless discussions, and before the CEO has even had a chance to do a status check in, the product team has designed a legitimate solution to a real problem. The users will tell you if it is worth building and investing in.
Wrapping It Up
I’ve been involved in design sprints that end with users positively validating ideas, as well as users rejecting ideas. The amazing thing - both outcomes encourage, uplift, and motivate the team! Nothing has been wasted, and every ounce of feedback (both positive and negative) has provided invaluable data to the stakeholders. I’ve had teams run a follow up sprint to iterate on the first sprint, and I’ve had teams jump straight into building their newfound, validated solutions.
I firmly believe Steve Jobs, were he alive today, would find immense value in the Design Sprint process. It emulates his philosophy of showing users what they want, before they may even know what they actually want. Moreover, it mitigates the risk of spending high development costs without any data validation.
Do you have any experience with Design Sprints? I’d love to hear from you!
