post

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Can product operations and innovation be friends?

Why can’t we get accessibility right? Claire Bauden (SVP Global Product Design, Global Payments Inc.)

Ditch the PRD template and embrace the PRD checklist

How to price your subscription product: insights and examples

International strategy with a 360 view by Chris Butler

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Sunday Rewind: The good, bad, and ugly of OKRs by Jenny Herald

Product Management

C. Todd Lombardo

I recently had the pleasure of taking part in an Ask Me Anything (AMA) discussion in the <a href="https://www.mindtheproduct.com/slack">Mind the Product Slack community</a>, where we talked about Design Sprints, how I take my coffee (a cortado), and my favorite board game (Chutes &#8216;N Ladders!). I&#8217;ve pulled together the Design Sprints bit of the conversation, as I imagine that will be the most interesting to the most people, and I hope you find some of it useful!
<h2>Let&#8217;s Start With What Design Sprints Actually are</h2>
<blockquote>It&#8217;s design while wearing running shoes and a track suit!</blockquote>
But seriously, a Design Sprint is a time-boxed problem-solving format that is part design process, part scientific method and part agile mindset. That&#8217;s a lot of buzzwords, I know. So let me break that down.
It’s usually five days, one phase/day, though I’ve seen and done many iterations
<ol>
<li style="font-weight: 400;">Understand &#8211; dig into the problem, its context, and your assumptions around it</li>
<li style="font-weight: 400;">Diverge &#8211; generate solutions for the problem</li>
<li style="font-weight: 400;">Converge &#8211; Select which solutions to prototype and test</li>
<li style="font-weight: 400;">Prototype &#8211; Build the one or two solution concepts to test</li>
<li style="font-weight: 400;">Test &#8211; Get the prototype in front of those who will use/buy/interact to observe them and gauge their feedback</li>
</ol>
Why and when would you use a Design Sprint? And where would you not use them?
Don&#8217;t use it to do something simple, like &#8220;Where should we add this form?&#8221; That likely doesn&#8217;t need a Design Sprint. It&#8217;s better for when you have a big problem to solve and you don&#8217;t have lots of answers. Or there are a lot of assumptions and the team&#8217;s unsure of which direction to go.
They&#8217;re great when exploring new product areas or product redesigns.
<h2>On Understanding Design Sprints</h2>
What would be the key distinctions between Design Sprints and Lean UX?
So many similarities! Sometimes I think they&#8217;re different sides of the same coin. Both are very experimental in nature (hence the science + design overlap)
<ul>
<li>Design Sprints: I think of it as a time-boxed one-week focused activity</li>
<li>Lean UX: approaches could take days or even months depending on what the experiment requires, not quite as structured (for activities) either.</li>
</ul>
Do you encounter objections in taking engineers away from productive work for five days in order to deliver &#8220;just one day of code&#8221;?
All the time. The framework encourages, almost by force, a collaborative decision process. This helps the team come to an agreement during the sprint.
My colleague Jill Starret always says:
<blockquote>If your job can survive a week’s vacation, it’ll thrive after a week&#8217;s Design Sprint</blockquote>
Are there any technical prerequisites to having an effective Design Sprint and prototypes to test?
Some ideas and prototypes may require live data to test effectively &#8211; what we&#8217;ve done in those situation is mock it up. For one sprint, we knew who the test participants were and we mocked up six different prototypes with data appropriate to them in order to reduce distraction and increase relevance. Some of the newer prototyping tools allow for these type of data-intensive prototypes.
Remember:
<blockquote>You&#8217;re not building to build, you&#8217;re building to answer. The prototype is thrown away after a sprint 99% of the time.</blockquote>
Do you find that the solution that comes out of a Design Sprint is a <a href="http://svpg.com/visiontyping-and-the-hands-on-executive/">visiontype</a>, or have you figured out a way to make it a narrow enough scope to complete in a single epic?
That all depends on how you define and narrow the problem on the first day. Sometimes the problem is clear and the range varies greatly. But this would be / should be identified on the first day, and maybe by the second you&#8217;ll start to gauge how the solutions you&#8217;re generating can be implemented. That&#8217;ll also help day three conversations when you select the concepts to build and test.
Could you recommend five prototyping tools to help make the sprint flow smoothly?
In no particular order:
<ul>
<li style="font-weight: 400;">Sketch + InVision or Adobe XD (similar IMHO)</li>
<li style="font-weight: 400;">HTML/CSS /JS if you can code it up quick</li>
<li style="font-weight: 400;">Paper prototyping</li>
<li style="font-weight: 400;">Axure</li>
<li style="font-weight: 400;">Keynote</li>
</ul>
The GV Design Sprints put the prototype in front of five users. Is five enough?
&#8220;Five on Friday&#8221; is a great alliteration &#8211; <a href="https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/">Nielson says so</a> (I usually book seven to nine to allow for no-shows)
<h2>On Pitching Design Sprints</h2>
What&#8217;s the most successful Design Sprint you&#8217;ve been a part of?
That depends on your definition of success. I did one with a large pharma company (18 people in the room!) and when we asked how long it would have taken them to get where we ended up without a Design Sprint their response was &#8220;years!&#8221;
As someone that works with clients, do you often come up against them being uncomfortable with ambiguity? And how do you help them understand that uncertainty about the final result is okay?
All the time. You have to manage expectations up front in the sales process (even if just “selling” internally). Many people conflate output and outcome, and it’s always wise to separate the two. While you do create a prototype, the Design Sprint really gets you answers and clarity. Yes, they are intangible, though often far more valuable.
<h2>On Facilitation</h2>
Who does <a href="https://www.freshtilledsoil.com/">Freshly Tilled Soil</a> bring to the table when doing a Design Sprint for a client?
We bring a strategist (who&#8217;s the facilitator) and a designer, at a minimum. For some bigger sprints we&#8217;ve brought a second designer and sometimes a project manager.
The project manager helps photograph and codify all the activities into a Google Spreadsheet (yes, they transcribe all the Post-It notes, etc &#8211; super helpful post-sprint) &#8211; a good project manager does wonders.
What advice do you have on an adequate amount of prep work before starting a Design Sprint?
I&#8217;m glad you realize the need for prep work! Showing up on day one and saying &#8220;Let&#8217;s do this&#8221; is not very wise. Having general direction, team, materials and space are important. Inputs might be UX research, stakeholder interviews, market data, etc.
Have you ever started a Design Sprint and, while running it, realized that it might be not helpful at all? How did you proceed?
Oh hell yes.
Just stop, and realize it&#8217;s not the right tool for the job. We did this one where the solution was fairly baked and, two days in, the executive came in and asked what the team was doing since the problem was effectively solved &#8211; it just hadn&#8217;t been implemented in the project.
The hard part is realizing it.
Which teams do you involved in prototyping? Is it solely down to a UX team, or do you involve other teams that may have feedback as well?
A cross-functional team is best. It’s always helpful to have a designer involved from the beginning of the sprint so they can be well informed and build the prototype quickly. However we have brought in designers just for the third-day sketching sessions so they aren’t completely blind. That’s worked OK, but not quite as well as when they have the full context.
When in the converging phase, I&#8217;m finding that there can still be a lot people sticking to their original ideas &#8211; are there any techniques you could recommend for helping the team be more open to exploring together?
This is where the approach of identifying the critical assumptions (on day one) for the sprint help. This is also where we differ from the GV approach. Your assumptions become a guide for selecting which ideas to move forward. You wind up removing some of that (sticking to ideas) due to these previously identified assumptions.
If someone wants to become a great Sprint facilitator, what skills or attributes do they need to cultivate?
Just being a good designer, product manager or dev doesn&#8217;t make you a good sprint facilitator. You need to learn how to facilitate a group, which is a whole other skillset of listening, guiding, and learning how to lower, or admit, your bias. As a facilitator, you need to listen not to just what&#8217;s being said, but also what&#8217;s not being said and by whom &#8211; pay attention to body language.
For those reading, Dan Brown&#8217;s book &#8211; <a href="https://www.amazon.com/Designing-Together-collaboration-management-professionals/dp/0321918630">Designing Together</a> &#8211; is highly recommended if you’re learning about being an effective contributor. And Michael Wilkinson’s <a href="https://www.amazon.com/Secrets-Facilitation-Getting-Results-Groups/dp/1118206134/ref=sr_1_1">Secrets of Facilitation</a> is probably my favorite on facilitation. Other than that:
<ul>
<li style="font-weight: 400;">Being able to gauge a group &#8211; so &#8220;listening with your eyes&#8221; is important.</li>
<li style="font-weight: 400;">Commanding attention not demanding attention.</li>
<li style="font-weight: 400;">Let the team bungee jump: they can fall, but don&#8217;t let &#8217;em hit the ground!</li>
</ul>
How do you collect your Friday testers, and how many days in advance?
This is always a challenge with any team I’ve worked with. While sometimes it’s difficult to arrange ahead of day one, it’s sometimes possible. I’m wary of going straight to Craigslist or similar open forums even with a solid screener, as some people participate only for the money. 70% of my experience with Design Sprints is B2B, so most often the sponsor/client can make arrangements ahead of (or during) the sprint. Usually by day three we’ve locked down the majority of test interviews and Thursday is confirmation and finalizing.
If you need prospects, call the sales team (if there is one) and get them to give you 10 prospects. If you need current customers, get marketing to surrender a similar set of 10 customers that fit the persona you seek to test with.
A colleague recently went to the Boston Public Library and did guerrilla testing and it did not go so well, so I’d use caution with that kind of random-test approach.
I&#8217;ve seen an attitude of boxing the &#8220;innovation&#8221; into the Design Sprint, and then considering it over afterwards while the “real work” continues. Are there ways to fix that?
Yeah &#8211; I&#8217;ve experienced that also. Before you even start the sprint, you need to think about what happens next. And then, during the sprint debrief, you can determine next steps. There are typically three outcomes:
<ol>
<li style="font-weight: 400;">You got answers and everything was validated</li>
<li style="font-weight: 400;">Nothing worked.</li>
<li style="font-weight: 400;">It kind of worked &lt;— this is most common</li>
</ol>
You need to determine how to address this during the day five retro and debrief. Or yes, it will just die on the vine.
Any recommendations about running sprints with the same groups over and over again? How do you keep your team from burning out on the process?
That&#8217;ll actually help you in the long run, as your team will have experience and you won&#8217;t have to explain each part of the process over and over. That said, you could look for ways to slightly change exercises. For example &#8211; change Goals and Anti-Goals to Hopes and Fears. While I&#8217;ve run over 100 sprints myself, I&#8217;ve rarely seen two run the same way!
<h2>Ask Me Anything!</h2>
I had a great time discussing Design Sprints and chatting with product people. If you want, <a href="https://twitter.com/iamctodd">you can always find me on twitter</a> to ask me questions, and I&#8217;ll answer as best I can in 140 characters!
<div class="g g-21"><div class="g-single a-170"><a class="gofollow" data-track="MTcwLDIxLDEsNjA=" href="https://www.pendo.io/pendomonium/"><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2024/06/MTP-Footer_ad.png" /></a></div></div>

Getting into Design Sprints – an AMA Interview

C. Todd Lombardo

Comments

Read next