Learnings from 'Sprint' by Jake Knapp
6 minute read
Andy Shanks profile photo
Andy Shanks
Test it before you fall in love with it

We’re constantly refining our product development process, so when we saw Google Ventures were releasing a book about how to run product design sprints we immediately pre-ordered several copies.

The best thing about Sprint is the real world examples of digital product businesses you know well, the sprint process they went through and how it worked for them (e.g. Slack). The book also gives the reader a very thorough workshop structure to follow to emulate the process, what pitfalls to avoid ,and how to prepare to get the most out of each day.

We’ve used the process since and gained valuable insight into how to progress our next internal product but found some challenges along the way. In my opinion Google Ventures use this sprint process to send a team into a startup they have invested in to help them improve their product and continue to do so. However I question how realistic the process is to emulate for everyone and especially teams that are in the early stage of product development.

To adopt this process to the letter you need a product with real customers and a week where your entire key team are available to be uninterrupted 9-5. This feels achievable in a situation where the problem you are trying to solve is significant to the business, and justifies allocating significant resource. However, most teams would surely struggle do it for minor updates, or for  every new feature, unless they had a dedicated sprint team - a luxury in a startup.

We often meet excited early stage entrepreneurs with big ideas who need help bringing their product to life. The process we are currently working on improving most is this initial product kick off phase - starting with just an idea and working out the best way to execute it. The first step on the product roadmap; arguably the most important. Sprint has given us some useful tools to help this process but not all the answers. For example, if you haven’t heard of the 'crazy 8' rapid UX technique this alone is a reason to read the book, a hugely useful technique in any workshop.

As well as the inspiring examples and insights into the crazy world of start ups the most useful out-take from Sprint is the core message to test early. The Sprint team's years of experience here is a great reminder for all product developers to test before you fall in love with your idea. You need to ensure that what you build is what people want, and not what you think people will want. They’re not always the same thing.

"The sprint gives startups a super power; they can fast forward into the future to see their finished product and customer reactions before making any expensive commitments".

There’s a great Mark Twain quote that sums this up well;

"What gets us into trouble is not what we don’t know. It’s what we know for sure that just ain’t so".

Ultimately the message here is to test if customers understand what your product does and the problems it solves, and to see how much they actually care before you invest time and money into developing it. We’ve met several startups recently where we have advised them not to develop anything yet - not always easy for a business selling product development services!

There are many ways you can run a sensible low cost checkpoint to validate if you are on the right lines. The payoff here can be success as well as failure - both valuable gains in our book. If your potential customers don’t get it or don’t like it you need to re-design or re-explain what you are offering. If they love it you know you are good to continue as planned. If they quite like it you’ll get some great insight into some of the minor details you can improve, and priority of features to build and perhaps some insights into the ideal customer profile.

Here’s a very basic overview of the process

Set the stage

The right challenge

The right team

Location, time and preparation


Identify customer problems

Pick the core problem to focus on


Review existing solutions

Sketch competing solutions


Pick the best solution

Define a testable hypothesis


Prototype the solution


Test with real customers

Review feedback

Evaluate against hypothesis

So we continue to search for more inspiration and in the process continuing to develop our own process inspired by Sprint as well as the other many great resources out there like Strategyser, Lean Canvas Happy Startup School, and many more.