Imagine you are about to launch a new feature or product. It’s a world changing new widget that will be a complete game changer in your industry. It’s a unique and innovative idea. You have a great business case. Management and investors are on-board. Your talented team are super excited. Your pitch deck is a work of art. So why is there that niggling fear in the back of your mind that everything will go pear shaped?
No matter how well planned the project is there will always be some risk involved. In my opinion and experience the biggest risk is apathy. The very real possibility that your baby won’t be loved or worse, ignored, or even worse, completely rejected out in the wild. Until our product is out there we are working with assumptions. The longer our assumptions remain untested, the greater the risk.
Fortunately, the culture of creating products has increasingly been leaning towards movements like lean startup, agile methodologies and design thinking. These methods and frameworks are shifting product development towards a more user centered, iterative approach that helps us to “fail fast, fail cheap”. There is now a focus on validation with data from real users. The speed at which we get this data from real users can be the key to our success.
We were lucky enough to recently spend a day training with Jake Knapp, author of “Sprint” and pioneer of the design sprint process. Jake is a self confessed process nerd and is obsessed with his mission of making good use of time. His sprint process was inspired by IDEO, hackathon culture, lean startup and design thinking with liberal sprinkles of behavioural science. It was honed during his time at Google and Google Ventures.
His process is used as a way of helping teams to quickly solve some of their biggest challenges. More importantly it helps to de-risk projects through rapidly gathering data from real users. We learned some of the finer details of the sprint process directly from Jake. We heard first hand some of his insights from running design sprints with with companies like Blue Bottle Coffee, Slack and Nest, as well as sprints he has led for Google on products such as Gmail and Google Hangouts.
If you ask anyone what a successful software project looks like they are likely to say that it’s one that is on time and on budget. This is important of course but as we all know a project that is on time and on budget that does not gain traction with users definitely can’t be deemed a success.
To be truly successful it needs to resonate with users. It needs to relieve their pains. It needs to meet their needs. It needs to bring real value to their lives. They don’t really want your product. They want the outcomes your product can produce for them.
To build something great we need to know who we are building it for. There are several research methods that we can utilise, each with their individual strengths and weaknesses. Ideally we would carry out ethnographic studies, observation and contextual enquiry to gain a deep understanding of our users’ needs. This is not always possible.
Why don’t we just ask our customers what they want or how they will behave? Because this is risky. As the famous social anthropologist Margaret Mead said,
“What people say, what people do, and what they say they do are entirely different things.”
In an effort to move quickly it can be tempting for us to assume that we know what our customers need. We put ourselves in their shoes and reason that what will work for us will also work for them. This opens us up to a great deal of risk.
Take a simple example like a car. Close your eyes and imagine your perfect car. Cars all perform the task of getting drivers and passengers from A to B. If this is a such a homogeneous task then why are there so many makes and models? Is it purely utility that makes people chose one vehicle over another?
A parent who needs to easily get a bunch of kids in and out of a car several times a day might need a people carrier with plenty of seats and storage for buggies and shopping. Someone going through a midlife crisis may ‘need’ a convertible sports car. A builder may need a van to store and transport tools and equipment. Your perfect car may be something completely different. These examples all share the same basic DNA but are drastically different solutions.
How do we make sure our ideas are a hit with our customers? How can we quickly test our assumptions? How can we be confident we are not building a sports car when our customer really needs a van? What if there was some way of magically fast forwarding into the future to make sure our understanding of our customers’ needs is in line with reality? Design sprints may be our DeLorean.
Design sprints were created to work in fast paced, engineering led companies like Google. The term “design sprint” can be misleading and perhaps a little off-putting to those who don’t see themselves as designers.
Design is often confused with artistic or creative ability. I don’t believe this to be the case. Some of the best designers are terrible at drawing! My favourite definition of design comes from Herbert Simon. He says,
“To design is to devise courses of action aimed at changing existing situations into preferred ones.”
By that definition, anyone involved in a software project is also involved in design.
The aim of a design sprint is to make decisions with key decision makers and get real data on our ideas and assumptions quickly. We use real customers to increase our odds of success.
Essentially a design sprint allows the whole project team to:
We assemble the real team including all key decision makers, product owners, engineers, marketing, customer insights etc. in an environment with few distractions. Of course, it may not be practical to have everybody present all the time but we make sure to have key people present at the relevant times.
This is broadly how the sprint week is divided;
Einstein is often attributed with saying,
“If I had only one hour to save the world, I would spend fifty-five minutes defining the problem, and only five minutes finding the solution.”
Through collaboration and sharing knowledge in a structured efficient way we gain a laser-like focus on our most important problems, most dangerous assumptions and biggest risks.
While the sprint process functions like a recipe book or a set of instructions that can be followed by anybody there are certain practical and logistical challenges that arise.
The goal of the sprint is to have a realistic prototype that is tested with real users. Creating something with this level of fidelity can be tricky and requires UI skills to reach the necessary standard. Luckily here at Marino we have a skilled team to quickly produce realistic looking and functioning prototypes ready to be tested with customers.
Recruiting, scheduling and interviewing customers can also be a challenge. Our team have experience and training in observing users, interview skills, and in scheduling and recruiting test participants. We also have the technical setup, including cameras and software, for capturing and reporting on these tests.
Sprints require a dedicated collaboration area with ample whiteboard space. We have access to excellent collaborative spaces where you can assemble your team away from the distractions of your everyday work.
Starting a project with a sprint removes the need for countless hours of meetings, debates and misunderstandings. Team members become aligned and focused, each having the opportunity to contribute and apply their strengths. The process allows us to systematically surface important information that otherwise might lay buried in team members heads until it is too late. The burden is taken away from the team who are then free to focus on generating ideas and making decisions.
It allows us to go beyond the first idea that might solve the problem and explore multiple solutions that may set your product apart from the competition. Most importantly it allows us to verify that we are solving for our customers’ real pains and not wasting time building software nobody wants to use.
Think a Design Sprint might help your business to tackle big challenges? Find out more about our Design Sprint package.
We’re ready to start the conversation however best suits you - on the phone at
+353 (0)1 833 7392 or by email
