“What happens after a design sprint?”

During a design sprint you validate a big, important idea that you’ve previously researched by building a realistic, customer-testable prototype. But then what?

New Haircut’s story with design sprints

We’ve now been hired to manage lots of sprints and workshops for products teams around the world. The top question we receive during the sales process as well as toward the end of the 5th day is — “What happens after the sprint?” To answer this question, I need to tell you a story about why we adopted design sprints to begin with.

One of New Haircut’s inaugural sprints in late 2015.

Our vision has always been to evolve New Haircut into the top 1% of software design & engineering service providers across the globe. That’s meant painstakingly reviewing project management practices, recruiting the best people, and ensuring our product development process was as efficient, reliable and value-driven as possible. I’d say the first 2 on that list are pretty solid. But that last one — our product development process — is one we’re constantly, obsessively tuning and tweaking. I always tell people that each time we think we find the newest, best kickoff to creating products, as we dig into that process / tool / framework, a new starting point emerges.

We’re a 7 year old company. For the past 3 years we stood supremely confident in our ability to execute our core UX/UI design and software engineering services. If we knew what we were building and why, we could create some of the most killer digital products on the market. However, we were also heavily reliant upon the teams hiring us or third party UX/ research firms to seed us with the all of the upfront research, validation, and roadmapping.

The problem with this dynamic is that it’s nearly impossible (best case: extremely inefficient) for 1 set of people to research & validate solutions to a problem, and then have another set design and build those solutions.

So about 1 year ago, the mastermind operator behind New Haircut and my co-founder, John Vetan, sent me a link to GV’s website about design sprints. The Sprint book was yet to be launched. My first reaction was to doubt that anything worthwhile could be accomplished in 5 days. However, if we could successfully implement sprints into our maturing design thinking and innovation practices, it would not only fill in some critical missing pieces of those upfront missing capabilities, but it would enable us to follow the life of a product from start to finish — greatly improving our ability to deliver better, more viable, user-centered products for our clients.

A snapshot of one of our early design thinking workshops in Berlin.

So today I want to share with you the approach we’ve taken to marry design sprints with the core steps required to build, advance, and scale the solutions you’ve validated within your design sprint.

Build, Advance, Scale

When you exit the 5-day design sprint, you’re hoping to have validation of your sprint challenge to feel confident moving into product development. Once you’ve obtained that validation, we’ve implemented 4 steps that allows us to take all of the insights gathered during the design sprint into the actual execution performed during product development:

1. Post-sprint
2. Build
3. Advance
4. Scale

Post-sprint. During the week immediately following our design sprint, we run a follow-up workshop. There are a few goals:

• To capture & share the big ideas that came out of the sprint — we do this with a document we call a Replay that summarizes key findings, recommendations, and a re-assessment of our DVF criteria

IDEO’s representation of DVF for uncovering innovation opportunities

• To tease out all of the remaining Customer Journeys — go back to your personas and connect your validated solution to the Job Stories your product will fulfill
• To create a detailed plan of who, when, how the solution will be built. We like to use the GO Product Roadmap by Roman Pichler.

UPDATE: We no longer recommend such roadmaps that are feature-driven. Instead, we’re busy working on evolving roadmaps to be outcome-driven. Contact us if you’re interested in learning more.

Build. This is still where many begin. We all want to jump into building solutions before we know a thing about our business priorities or the customers we’re serving. But if you’ve gotten to the point where you’ve run a successful sprint and completed some of the post-sprint steps, you’re now ready to plan your infrastructure, wireframe, design (UX / UI), code, test, and launch.

One of the key activities we perform during our Build process is something we designed called a Code Sprint. This happens right before you enter into full-blown product development where your application architects, data scientists, engineers and product managers will probably need to clarify exactly how your product will be constructed. We developed a 5-day Code Sprint (sorry to persist with the use of sprint!) to allow these folks on your team to research, develop and test candidates for your product’s architecture, infrastructure, frameworks and libraries. You can learn more about our code sprints here.

New Haircut Code Sprints — something we pioneered during our days of a software studio.

Advance. During your sprint you should have spent time defining the metrics that will matter most — these are your compass to ensure the solutions you delivered are providing the business returns your stakeholders care about. Within Advance, we’re capturing, measuring, and iterating our solutions based on what we’re hearing & seeing from customers in a production environment.

Scale. One of the biggest misconceptions we run into as we talk to teams and executives about design sprints is that they’re something that are completed as standalone projects. However if design sprints are going to provide sustained value, they, and all of the related design thinking practices, tools, and processes need to be baked into the company culture. This is the main goal during our Scale step — to enroll others by showcasing the success of this project, training them, and then carrying that momentum into future initiatives.

Wrapping up

Design sprints have provided a super efficient tool for validating big ideas before plowing head-first into product development. Hopefully this post has provided your team with some clues about how to transition from your design sprints into the actual building, testing, and scaling of your products and services.

Next up: What happens before a design sprint?