We have what we’d like to think is a pretty badass product development process at New Haircut—and we keep it that way through constant and obsessive tweaking and tuning. I’ve talked a lot about our reliance on design sprints, but the question we get most from the product teams we work with is, “What happens after the sprint?”
A design sprint is a design-thinking tool to help teams test big, important ideas before starting to build. We create prototypes within the sprint and attempt to validate them with targeted customers. Assuming we do collect the validation we need, the next challenge is connecting the insights uncovered during the sprint to effectively and efficiently build solutions—or in a word, execution.
“A question we get a lot from clients: ‘What happens after the sprint?’ ”
So what our clients are really asking us is, “How do we get from validation to execution? How do we take what we’ve learned in the design sprint and code it into digital existence?”
Here’s how we solved that challenge and how your team might think about approaching your product development process.
Rethinking sprints for product development
In order to explain how we got to the point of successfully marrying our design sprints to product development, it’s important to understand why and how we adopted design sprints in the first place.
For the past 3 years we’ve been 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 relied on the teams who hired us or third party UX/research firms to seed us with all the upfront research, validation, and roadmapping.
The problem with this dynamic is that it’s nearly impossible—and in the best case scenario extremely inefficient—for 1 team to research and validate problem solutions, and then have another team design and build those solutions.
“It’s inefficient to have one team research and validate and another design and build.”
So about a 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 had yet to be launched).
Don’t miss: Bringing design sprints inside your company
My first reaction was to doubt that anything worthwhile could be accomplished in 5 days.
Thinking it over, though, if we could successfully implement sprints into our maturing design thinking and innovation practices, we’d gain the ability to conduct that missing upfront research and validation, and it would enable us to follow the life of a product from start to finish. We could deliver better, more viable user-centered products for our clients.
After successfully adopting 5-day designs prints into our product development process, here’s 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 that design sprint.
The 4 steps to move from sprint to execution
When you exit your 5-day design sprint, you should hopefully have validation of your sprint challenge and feel confident moving into product development.
We’ve implemented 4 steps to take all the insights gathered during the design sprint and jump into the actual execution of product development:
- Post-sprint
- Build
- Advance
- Scale
1. Post-sprint
During the week immediately following our design sprint, we run a follow-up workshop. There are a few goals:
To capture and share the big ideas that came out of the sprint—we do this with a document we call a Replay, which summarizes key findings, recommendations, and a re-assessment of our DVF criteria
DVF for uncovering innovation opportunities, courtesy of IDEO
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
2. Build
One thing I see is that lot of companies start here. They skip the sprint and they skip that first post-sprint step.
We’ve all been there—wanting to jump into building solutions before we know enough 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, 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 (yes, another sprint—bear with us!) to allow these folks on your team to research, develop, and test candidates for your product’s architecture, infrastructure, frameworks, and libraries.
3. Advance
During your sprint, you probably spent time defining the metrics that will matter most—follow these like a compass to ensure the solutions you delivered are providing the business returns your stakeholders care about.
Within this Advance phase, we’re capturing, measuring, and iterating on our solutions based on what we’re hearing and seeing from customers in a production environment.
4. Scale.
One of the biggest misconceptions we run into as we talk to teams and executives about design sprints is that sprints are completed as standalone projects.
“Sprints aren’t standalone projects. They need to be baked into the company culture.”
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 : enrolling others by showcasing the success of this project, training them, and then carrying that momentum into future initiatives.
Wrapping up
Design sprints have provided us with a super-efficient tool for validating big ideas before plowing head-first into product development. Hopefully New Haircut’s tale of conceptualizing and implementing this process can provide 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.
In a later piece, we’ll discuss the steps you should take prior to a design sprint to ensure your sprint aligns well with the business priorities and has the best chance of solving the right problems your customers care about.
by Jay Melone
Jay Melone is a Partner at New Haircut, a product strategy and training group based in NJ. They help product teams fall in love with the digital solutions they make, and how they make them. They offer design sprints, problem framing, and outcome-based roadmaps as part of their 4-week Product Transformation Program.
