At U-Hopper , we have been providing tailor-made big data analytics solutions to businesses for quite a few years. Our ‘typical’ customers are corporations, that are willing to use data in order to either optimise their internal processes or to provide new value-added services to their clients, but that lack the expertise and know-how to do it internally. That is where we jump in: we provide data science and specialised software development capabilities to make sure that our customers get the most relevant insight out of data, and use it to create value for their business.
Early on, one of the limiting factors we bumped into was related to the fact that in most cases the project requested by the customer was presenting high levels of uncertainty. Uncertainty at different levels: in the use case definition (What is the exact problem you want to solve? What are the relevant business KPIs? What are your constraints in terms of the solution we are going to develop for you?), in terms of data (How much historical data do you have available? Is it enough to train a predictor? Is the data clean enough or are there inconsistencies? Where is the data stored and how can we access it? Are APIs available?) and in terms of innovation (Who is going to use the solution? Who is going to be affected by the introduction of the solution? Does the introduction of the solution require changes in processes/procedures? Does it call for an internal reorganisation of the company structure?). Mind that, at the same time, customers were reasonably asking for a quote.
And we had no choice but to factor this uncertainty in the quotation. Which meant - in concrete terms - to add some extra time (to make sure we would have had enough time to sort out problems encountered on the way) and some extra budget (to make sure we would have had enough resources to cater for unexpected problems.
The net results were proposals for rather expensive and long projects, which were putting our customers in a difficult position. With proposal acceptance rate stagnating, we were facing a problem that was putting our business model at risk. What to do? We discussed the issue at length with people in our league: innovators, entrepreneurs in the ICT field and digital transformation consultants. Many of them suggested us to look at design thinking approaches . And so we did.
Roughly speaking (sorry for oversimplifying it!), design thinking can be understood as a principled approach to design proposals for new products or services. The Interaction Design Foundation describes it as a “design methodology that provides a solution-based approach to solving problems. It’s extremely useful in tackling complex problems that are ill-defined or unknown, by understanding the human needs involved, by re-framing the problem in human-centric ways, by creating many ideas in brainstorming sessions, and by adopting a hands-on approach in prototyping and testing” ( 5 Stages in the Design Thinking Process ).
Out of the whole field of design thinking, in particular, we decided to try out the design sprint approach as a way to tackle our problem. Originally developed at Google Ventures (the corporate VC of Google - now Alphabet), it is described as “a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.” ( It is structured around five phases (understand/sketch/decide/prototype/validate), and is meant to simulate how a solution may feel (not just look!) like, how it can be used and which impacts it may bring about. (If you want to dive deeper on design sprints, we fondly suggest this book ).
We actually decided to make our own ‘design sprint’ recipe. While the design sprint methodology has proven to work extremely well, we thought the ‘standard’ version did not really meet our needs. To us, design sprint workshops were a means to harness uncertainty on the customers' problem, and reduce associated risks on our side. We shortened the design sprint to 1.5 days and to cut off the last two phases (prototyping and validation). Why so? Well, we decided to shorten because we knew that it would have been basically impossible to get the right people from our customers to spend five days (!) with us. Just too busy to do it. The idea of leaving out the last two phases was based on the fact that for us it was important to get to a point where we could have a solid and bullet-proof project plan for delivering a reliable offer. Building prototypes and testing them, we think it is something that - in our specific case - should be carried out during the project itself.
Oh yes, and of course we started asking the customer to pay for such design sprint! No big money, but enough to cover the time our personnel spend at their premises running the sprint.If you want, see it is a form of commitment from their side, testifying that they are seriously interested in the project and are not just scratching for random quotes.
So far, so good, we have been running quite a few design sprints with customers, and we must say that the approach has shown to work pretty well. Since we introduced it, our proposal acceptance rate has increased significantly. But what is the benefit for customers? They have an easy (and cheap) way to test our professionalism and to test our skills and competences in action. And of course, they get lower quotes for the project (as through design sprint we reduce uncertainty and we do not need to factor in extra time/effort) and shorter time-to-delivery. We estimated that, thanks to design sprint workshops, we have been able to lower quotes by more than 20% and to reduce the expected time-to-delivery by almost 30%!
In doing so, we also learned some lessons, that we are glad to share. The first one relates to the importance (and difficulty!) of getting the right customer’s staff members to join the sprint. It is often hard to convince them to bring on board people from different departments. And it is hard for the sprint lead to convince executives to keep focused solely on the sprint for 1.5 days (no email, no phone). Furthermore, getting the ultimate decision-makers to participate at least to the final debrief and presentation of outcomes, can make the follow-up project negotiation much smoother and faster. The second one relates to the fact that many of our customers had already experienced some kind of design thinking workshop (typically provided by specialised consultants) and were not completely satisfied with the extremely theoretical approach of the activity. But when they understand that during the sprint we are actually able to devise a software architecture for their problem, to define API specifications and to provide insight into which ML algorithm is most suited to their data and needs, that is really a game changer, because they can get a glance on our operating methods and check how fast we are at moving forward.
So… long life to design sprints!