“Week-long Design Sprints might work in a startup where the team is small and focused on one big project. Sprints don’t work in larger companies because the product teams have too many competing priorities.”

This is a real quote from a product leader. It’s also the mindset of many PMs and Product Designers. When you dig in, you learn that it’s not because they’re anti-sprints. Their frustration stems from the fact that their culture and processes make it nearly impossible to sprint – that is, to focus on 1 thing for a few days (let alone an entire week).

Don’t take my word for it. Here’s a few related questions I fielded during one of our Reframed Sprints training workshops earlier this week. The team was excited to learn about facilitating sprints, but skeptical it would stick because of their limited bandwidth.

These are completely legitimate questions and concerns. I faced the exact same when I was getting started.

In reality, human beings have been struggling to remain focused for thousands of years. We believe it’s false beliefs that technology and social media are to blame for our multitasking mania. We’re quick to blame new rungs of company leadership that constantly reprioritize, forcing us to shift our product strategy and roadmaps. But leaders have been changing their minds and callously rushing their teams along since the dawn of time – I do it almost religiously. So let’s not count on that changing soon.

And yet, many groups have figured out how to successfully run week-long or, even, multi-week sprints. What you should recognize (and lighten up about) is that everything won’t shift overnight. That’s actually a good thing.

Try this

If you’ve been pushing for sprints or, simply, more time for customer discovery, here’s one approach you can take to get your team from 0 to 1. You should expect to see a sharp improvement between sprints 1 and 2 – and certainly between sprints 1 and 10.

First, stop overthinking it and run a sprint. Use a framework to get the gist of sprinting – the app is due for an update but it will do the the job. Whatever you do, don’t compare your process or tools to Google’s, Bornate’s, or anyone’s. No matter, in time you’ll be running your own flavor of sprints that work best for your group and the products you create.

Choose a moderately important project to run your sprint on – something that’s a 5 in terms of priority and complexity. If there’s research to back it, great. It’s more ideal if you can run it in 5 consecutive days. If you spread it out over 2 or 3 weeks, that’s fine too. Don’t let it run longer than that – not yet. Whatever timeline you agree to, don’t budge once people have committed the time. You’ll never get out of the gate if you start moving the dates around before you get started.

Set the expectation – upfront, loud & clear – that this first sprint will be infamously imperfect. This is your design sprint prototype. Still, there will be backlash from leaders and peers. No surprises there. Change is scary. Use the outbursts and anxious sidebars as a barometer – those who lose their shit the most are most in need of a shift. It will just take them longer to get there. Don’t let that sway you – expect it.

The single most important step of your first sprint will be a retrospective. Hold it on the afternoon of the last day of the sprint, right after you wrap up testing and make some decisions about next steps. Don’t leave time in between. Do it while things are hot and fresh. I know you’ll be tired – persist.

Ask yourselves, honestly, what worked well? What surprised you? What needs more exploration? What do you want to try differently next sprint? 

Resist blackballing parts and people at this stage. Your customer interviews may have been utterly useless because you picked a poorly framed problem to solve. Your facilitator probably bombed because they have another full-time job and only agreed to facilitate because nobody else would. Next sprint, make some agreed upon adjustments and reflect once more.

If it sounds like you’re taking the same iterative approach you use for designing new products, it is! Running sprints is an experience you’re prototyping and testing. If you approach sprints with the same curious, iterative, empathic principles they’re built on, you’ll learn faster, sprint better, and have much more fun along the way.