November 2, 2017


If you are like most of the companies we work with, your mandate to get decent software out the door and into the market consumes every working hour each week. Now it’s Saturday morning and you are knocking out work that you wanted – needed – to get done days earlier. You know that just getting the software in your development backlog completed is not enough. If you are going to be competitive over the long term, you must innovate. You don’t have the luxury of allocating 20% of your team’s work week to develop new ideas. So how do you systematically innovate outcomes that drive revenues and business growth?  

It is possible to rapidly and systematically move from business challenge to prototyped solution using Design Sprint methodologies. The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. Small multidisciplinary teams can develop working prototypes quickly, test with end users, and iterate based on learning – all within one week. 

Design Sprints are a faster, more productive development path to create software that is relevant to real business problems and designed with end user input and participation. Prototypes can bring business strategy, innovation, behaviour science, and market potential into much greater focus. The power of Design Sprints is that the process can closely approximate the work that took teams weeks to complete with previous development models.

“The sprint gives you a superpower: You can fast-forward into the future to see your finished product and customer reactions, before making any expensive commitments.”


Design Sprints are modelled after the design thinking framework practiced by the design firm IDEO and began at Google, where they were used to create some of Google’s well-known products. A powerful principle of Design Sprints is that prototyping a rough solution and testing it with as few as 5 users can produce adequate learning on the central questions of the product. Consider that few, if any business decisions are made with complete information.  Product decisions can be effective by developing only to a point where there is enough resolution to learn enough from user interaction to determine how and where to iterate next.


Consider how much of our software is built today. Modular architecture is common and containerisation of software as a development practice has proliferated rapidly over the past five years.  Each approach isolates code so that changes to it don’t affect the entire application. An outcome is that developers can modify code and try things without risking the operability of the entire application. So in this respect, containerisation enables Design Sprint methodologies to be more readily applied to software. 

Software modules enable a powerful characteristic of Design Sprints: the rapid construction of prototypes that approximate a market ready solution and enable teams to experiment towards the best combination of solutions.


Agile Development Sprints are a method to quickly develop solutions to the existing product backlog. It’s a way to get something done quickly that can then be iterated and made into offerable product. The practice helps software development teams tackle a specific problem and rapidly move from product spec to working, deployable code in a window of time.  Agile sprints are characterised by the outcome of deployable solutions as the end result.

In the software development community, there is a pre-sprint before an Agile Sprint. Sprint 0 is similar to Design Sprints in that the objective is to learn and iterate to a next step rather than a finished product. Design Sprints and Sprint 0 are complementary to Agile Sprints as they help teams ensure they are solving the right problems relative to business strategy, market potential, and user acceptance.  My experience is that teams that first conduct a Design Sprint are better focused and better able to transition from a prototype into saleable product using Agile Sprints.


I think perhaps the most powerful aspect of Design Sprints is that it helps teams keep the business case and business model at the core of the problem.  Using the process helps teams keep focus on both business and technical outcome throughout the process.  Those of us who have worked in software for our careers each have our own stories of how projects got off track to where the developed solution deviated from the product requirements and didn’t solve the real problem.


It’s one thing to read the book and set off alone on your first Design Sprint and another to work with people who are well-versed in the application of the process to problems.  Getting expert help speeds the process, greatly increases the potential for success, and helps build long term competence around sound practice and process.  Be it Consulteer or another expert resource, we urge our clients not to go it alone.

As an outside catalyst that can help companies execute early projects, string together a series of successful projects, and develop a long-term capability with integrated Design and Agile Sprint techniques, Consulteer can help you develop a systematic capability to innovate while delivering outcomes that drive revenue growth going forward. We work at the intersection of business strategy and software development.