Product design sprints: a methodology for champions or do they leave you out of puff?

Bringing the latest tech to the legal sector.

Product design sprints: a methodology for champions or do they leave you out of puff?

Developing a new idea from scratch is always a challenge, be it an idea for a whole product or for a major new feature. Is your idea any good? Is it possible? How long will it take? How much will it cost? All of these are valid questions to be asking.

A popular and effective methodology for answering all of these questions quickly is the Design Sprint methodology, invented at Google by Jake Knapp and used at Google Ventures with over 150 startups. The principle is simple: allow yourself and your team five days to solve problems and test your ideas.

Fortunately for us all, Knapp, along with Zeratsky and Jowitz in his GV team, has published a book about the methodology, Sprint, which I strongly believe should be compulsory reading for anyone with a role or interest in developing products.

The main idea: get all of your key stakeholders in a room for five consecutive days to come up with an idea, refine it, decide on key features, design, prototype, and test it. Sound intense? That’s because it is. However, its effectiveness is undeniable.

Although the book seems to state the obvious at times, it also makes you realise that product development so rarely happens in this ‘seemingly-obvious’ way. The two key roles for the sprint are:

  • A designated decision-maker (so that if there are disagreements, the ‘decider’ can make the bigger calls)
  • A sprint lead (usually the Product Manager, takes an important and neutral role in the sprint. They run the sprint but make sure not to give their opinions, instead steering conversation and asking probing questions).

Having been the sprint lead myself a number of times, it’s fair to say that this is a very demanding position which determines the effectiveness of the sprint. There is a lot of prep work to be done ahead of the sprint, including logistics, organising equipment, and having testers lined up and ready-to-go. All of that before you even start planning the sprint’s activities! Furthermore, during the sprint it is your responsibility to use your common sense and judge what is working in the room. If you think you’ve already covered an aspect of the book in another activity, then judge when an activity is not required. This will help to keep your stakeholders engaged and momentum high.

The book recommends that a sprint comprises of a small, key group of ‘sprinters’ – I could not agree more. To maintain momentum and keep things lean, 4-6 people plus the sprint lead is more than enough. Usually this is your Project Lead (who is normally the decision-maker), CTO/senior developer, Team Member for the product who knows the nitty-gritty details that the Project Lead may not, business stakeholder (eg: do you have written content? If so, having a content writer in the room may be handy) and your Product Manager running the sprint.

Do bear in mind, though, that your Project Lead may not be the best decision-maker for the sprint. If you are designing a content tool, your decision-maker should probably be your content editor who will be using it every day. Remember: organisational seniority should not always determine decision-making in Design Sprints.

The biggest problem that the Design Sprint faces is that of effectiveness perception. Those running the business will inevitably think that taking up to 7 people from the team off their jobs for 5 consecutive days is a huge cost to the business. However, that mentality of starting in the negative is unhelpful. Instead, design sprints should be seen by leadership as a way of really refining a broad idea before you start extensive (and expensive) development work and end up going in the wrong direction. They prevent a lot of mistakes too, as your key decision-makers are all involved and on the same page by the end of the sprint. 35 employee days that a 7-person design sprint takes is far better than a team of 10 developers blindly building something for 4 months, isn’t it?

(That being said, I have run 3-day design sprints before which are very tiring but doable, if stakeholder commitments are an issue.)

The rapid prototype produced on days 3 and 4 is where it really starts to get interesting. You don’t need a designer or a developer for this. Programmes such as InVision are great to make clickable, basic wireframe prototypes, with no coding or design required. They don’t need to be pretty – they need to set out the core user journeys, which you will have established and defined as a group in the previous days of the sprint.

Testing the prototype with 4 to 5 users is key. If this is an internal product, that’s easier – get 4 or 5 members of staff who have not been involved in the sprint to do a structured user testing session. If you need external users, pay them to come in! You won’t get valuable feedback unless you give the users some cash to give their honest opinion – noone does anything for free, after all. There are great agencies out there who can source suitable users for you and this is the sprint lead’s homework to organise ahead of time. The investment is worth it.

Once you have tested, the sprint group reflects on the results on the final day of the sprint. Here you ask: what worked? What didn’t work? And most importantly, is this idea still viable and something that we as a business want to pursue? If it’s not, that’s okay! Finding that out at this stage is far more helpful than trying to flog a dead horse out in the marketplace.

An effective design sprint requires just two things:

  1. Buy-in from all those involved
  2. Preparedness from the project lead

With these two elements, you will find that you can get an MVP product established far more quickly than you would expect.

Post-sprint, the PM should always ask for honest feedback about what went well and what didn’t. Don’t take this personally. Instead, see it as a learning that can be improved upon next time.

I appreciate that the Design Sprint is a very different way of working for most people, so they can take some time to get used to. However, once engaged, all participants end up seeing the value in the process.

And hey, GV use it and they seem to be doing pretty well… Heard of Uber, Medium, Slack or Stripe? They are just some of the names to come out of GV’s portfolio having used this methodology, so do give the book a read and try a design sprint.


Emily Shaw

Emily Shaw

Project Manager

Emily initially worked as the Product Manager for Basement Crowd’s product, FromCounsel, before getting big corporate experience and moving to Penguin Random House. After being a Product Manager at Penguin and working across multiple B2C projects for some of the world’s most well-known authors, Emily returned to Basement Crowd to work on Juriosity from a strategic and BD perspective. She enjoys the overlap of product and strategy, with a sharp consumer focus. Emily holds a degree in Politics from the University of Cambridge.