Design interval training
Sprint
In 2016 the tech world seemed abuzz about a “Design Sprint” process detailed in the book Sprint by Jake Knapp and other Google Ventures employees. The premise was that a new area of opportunity for product could be tackled by a dedicated small team in just five working days, at least conceptually. The authors had honed the process during real company visits.
Plenty of readers latched on to the idea and tried it at their own companies. On the flipside, there was a backlash, with some feeling like a thoughtful ideation phase could not possibly be completed in a week, or that blocking out several busy calendars for a week was just not feasible.
Somewhere in-between, I feel there are emphases from the Sprint process that are important to cover, even if they are not all possible within the same week. By tackling these key areas intermittently over a longer period of time, you can cover some vital stages of the ideation process with more room to think and fit in other demands. Tackling these steps in a more protracted way can mean you get all the bases covered at a more manageable pace.
Focus on the Problem
The start of the Sprint week is spent learning all you can about the problem space being tackled, something which is all too commonly skipped over in the rush to get things done. “Ask the experts” the Sprint book advises; get a thorough understanding of the subject matter at hand. Getting deep into the problem is an important fundamental to tackle before working out any solutions. Talk to those affected, particularly those suffering from the problem, to learn more. You do not necessarily need to schedule all your interviews in one afternoon though. Take your time to dwell on the problem; who is affected and why does it matter to them? When does it impact their lives? How widespread is the problem? Who is not affected? Your understanding of the problem will inform all your later work, so you need to make sure the problem is as complete as possible before you move on to solutions…
More is more
Being set up with a thorough understanding of the problem at hand, your team is then in a great position to work on solving it. There is usually more than one solution to a problem, and you do not always get things right the first time; continuous improvement and failing fast are popular tech concepts. Sprint advocates aiming for multiple solutions right away; iterating on sketches until you come up with the most compelling variant. Try spending more time in-between to allow your ideas to marinate, and one day whilst tackling something else you may get that brain-wave that adds the missing piece you’ve been looking for.
Prototype
Waiting until engineering resources can be scheduled to undertake your new idea can be costly in terms of both time and money. Prototyping allows you to validate the way ideas fit together, both in your own mind and others, without the heavy upfront costs. Linking together a few mock-ups without code or a back-end allows viewers to visualise your product before you set about building it. Coming up with a believable prototype in one day when sprinting can be a challenge though, and is certainly rushed. Spending a bit longer allows you to cover up the seams and ensure that your prototype does a convincing job. Then you can use the prototype for validating the idea in question, rather than answering questions about whether the finished version would be full colour.
Try it out
The earlier you can get feedback, the earlier you can learn. The earlier you can learn, the earlier you can shape your solution to be more in-line with what’s required, or learn from your mistakes and start over. It’s like the virtuous feedback loop detailed in the well-known Lean Startup book by Eric Ries, except starting it before you build puts you even further upstream in terms of learning. That’s why Sprint crams Friday feedback into that week as the final key requirement; without the knowledge gained from the feedback sessions, you just have nicely presented assumptions, and risk proceeding towards outputs over outcomes.
Commencing the feedback gathering promptly but spreading it over a slightly longer period, say one session every day or two, can be more practical though. That way you do not have to try and slot in five people to help you out in one day; you can accommodate their schedules. You can spend more time discussing the area at hand with your participants both before and after the prototype test to get deeper into the issues without hurrying them through your script and revolving door. If something goes wrong, as it always can, and you discover a gaping prototype flaw during the first session that threatens to compromise all your feedback, you can realistically correct it for the later tests.
That isn’t to say you need more than five tests to see the trends though; the Sprint book very helpfully references a study showing the diminishing returns you get after the fifth session, and other similar studies reinforce the finding. It just means you can spend more time gathering, organising and analysing your feedback before taking action, soaking up all the value your in-person tests will give.
More haste, less speed
I would encourage you to read the Sprint book in detail for great insights in the areas mentioned. By all means try a Design Sprint at your company if you feel you can be accommodating enough to make it work. Life can get in the way though, so rather than taking an all-or-nothing approach, why not deconstruct the Design Sprint and tackle the key stages along a timeline that works for your situation? That may be a more realistic way for you to cover the important analysis steps that can put your product on the right track.
