About michelada.io

By joining forces with your team, we can help with your Ruby on Rails and Javascript work. Or, if it works better for you, we can even become your team! From e-Commerce to Fintech, for years we have helped turning our clients’ great ideas into successful business.

Go to our website for more info.


The michelada guide to delimit, solve and validate solutions.

31st January 2020

Or how a Product Design Sprint could help streamline your business.

It happens to all of us, it doesn't matter how many processes and years we've been doing something, there is always something that can be improved. It doesn't matter if you're a giant, like Amazon (with its Fire smartphone, which only lasted a year in the market) or Microsoft (remember Zune? Don't worry, neither do we).

Such was the case of one of our clients, a clothing company - so important, that you probably have at least a pair of their signature items in your closet - that when they developed one of their processes for nothing more and nothing less than receiving purchase orders to stock to its brick-and-mortar third-party retailers, they started with something to barely do the work. Several years and growth later, that process stopped being a small rock in the shoe to become a kidney stone: painful, annoying and with the potential to incapacitate if not taken care of, but not necessarily fatal. (I come from a family of doctors, the medical analogy was inevitable)

After they presented their problem, we used a methodology called Product Design Sprint. Why? Well, problems may have more than one solution and this methodology allows to define the problem, understand their cause, their consequences and validate the proposed solution with potential users from the hand of the stakeholders, allowing to have a basis to avoid deviating from the business goals in the creative process (which happens more frequently than we would like to admit) or avoid the omission of small logistical details that could be omitted due to assumptions during the planning of the project.

But what is a Product Design Sprint?

A Product Design Sprint (PDS), is a five-day process to assess ideas and solve challenges through rapid prototyping and user testing. This methodology is based on the book "Sprint: The method to solve problems and try new ideas in just 5 days" by Jake Knapp which in turn, is inspired by Knapp's work in Google Ventures.

While the goal of a Design Sprint is to streamline processes we know that for various professional reasons, it is difficult to take five days from our agenda to dedicate them to a small part of our business, which although critical, remains only one. Conveniently, there is a four-day version 2.0 where you only need the entire team (i.e. stakeholders, creative minds, technical minds ...) for two days, so instead of a whole week, you only have to make space for two days .

The creation of the solution

During the first two days, our PDS team composed of three product designers, a software engineer, a quality control engineer, a content specialist and three stakeholders, had an interview where they presented their current situation and we determined the critical area of ​​action that helped us to identify the actors involved and their stage of interaction, we sketched a solution and carried out usability tests to the proposal that followed an interview script to avoid variations in the testing environment so that we could assign real monetary value as well as of project length should the client choose to bring the prototype solution to a real execution. Much better than trying to fix a problem and then realize that you need more resources than you had originally allocated (another of the most common negative experiences when developing software). In this particular case, users showed a positive predisposition to adapt the solution in real scenarios and ease to complete the tasks.

Now, the PDS does not promise to be a definitive or long-term solution, not because it lacks the ability to, but because it's ability to will directly rely on the nature of each case for which it is being implemented. What it can promise is to give us enough information to know if it is worth investing resources to execute our solution, help us to define a problem and have better tools to execute a solution, and avoid the dread of investing in something that'll cost us more than it helps us.

View Comments