Chances are you have participated in a design sprint, or have a colleague who has. We're talking about the time-boxed event that takes a group of people from a broad challenge through a classical design process, to executing an experiment and gathering evidence to show if the idea worked. They are extremely useful because they focus on getting new data fast rather than analytically doing desk research. They work because they assemble broad expertise, are particular about assumptions to test, and are facilitated. Many variations of design sprints exist, although the Google Ventures kind is probably best known. Maybe you have rolled your own. We all owe everything to IDEO and Stanford d.school, anyway.
But the biggest issue today with design sprints, regardless of flavour, is what happens when it's over. During a classic five-day sprint, a team of approximately 10 people will explore the problem space, get inspiration from domain experts in various fields, ideate on problems worth solving, and design and execute an experiment. It's not a cheap exercise. With preparation and facilitation, it's easily totals 500 hours of work. So what happens on day 6?
All too often, we at Unlikly see a succesful design sprint in misalignment with the business processes that surround it, and the great momentum that's been built grinds to a halt - sometimes for months, which usually means it won't be picked up again. So even though we're seeing businesses becoming great at executing sprints as interventions in the business, those interventions don't lead to change. In the agile community, this is an anti-pattern called inspection without adaption. Between innovation professionals, it's called The Monday Morning Problem.
Ask yourself: If a design sprint is the answer, what is the problem - and who owns it? If the problem isn't rooted in the business somewhere with a sponsor who is keen to de-risk a decision to move ahead, you are probably wasting your time. Put differently, if your challenge is an orphan when it enters your sprint, your solution is likely to be an orphan too when leaving it. So you have to consider the internal ecosystem of your organisation and prepare your stakeholders for what 's coming. This is a critical element of preparing for a design sprint that is too often missed.
First connecting a design sprint to an existing business can be an uphill battle the first couple of times you do it because most people in highly practiced environments are subject matter experts supposed to have the answers. The very idea that problems exist which we can't solve ourselves by analysis and categorisation can be uncomfortable. That's why your best initial tactic is to find sponsors who trust the nature of an empirical process (follow the evidence wherever it leads) and also have no problem articulating that they don't have all the answers. That's the ideal "receiving end" for a design sprint.
Next you need your sponsor to make a pledge, and it is this: If you manage to find evidence in your design sprint to assert a critical assumption on which a key decision rests, your sponsor will promise to make that decision. That seems to be a fair quid-pro-quo. Occasionally, this happens by default if the sponsor is actually funding the sprint, but that is usually not the case - it's more of a slate-funding situation with people taking out time from their "day jobs" around the company.
Last you need to bridge the gap between the outcomes of the sprint itself - what you have learned - with the external business process - what needs to be decided. The gap is best filled with the same kind of facilitation, and ideally the same group of people, as the design sprint itself. This approach maximises knowledge sharing and puts the sponsor on the spot, which is what a sponsor should expect from time to time.
While we can learn a whole lot from a design sprint, one single sprint is rarely enough to attack a problem from different angles. Succesful innovations have iterated over the same challenge up to 10 times - yes, that means 10 individual sprints looking at the same challenge through different design lenses. It's all a continuous process to de-risk new initiatives by slowly stabilising a new business model and gradually increasing investment. No big bangs!
Therefore, as you grow your design sprint activities, you can also begin the corporate journey from interventions to corporate culture: Creating a steady pace of design sprints to involve everyone over time, and building a backlog of challenges from business owners that represent the most critical and strategic questions. That will ultimately grow to be the most valuable laundry list of the company's future.
As a final note, if you're operating in an agile organisation, you will have a head start. Design sprints align perfectly with agile frameworks such as Scrum, because they share a common approach - the empirical, after-the-fact approach. If you're a product owner, you will have a real opportunity to add speculative content to your product backlog and have the existing, cross-functional team figure out how to design experiments.
• Thanks for your interest.