This will be a short one because the book is mainly about the process and is fairly detailed – so if it’s something for you it’s worth buying and reading fully or there articles where it’s been summarised it online. However, there are a couple of things that I found quite useful which could be transferable.

Sprint – How to solve big problems and test new ideas in just five days, Jake Knapp

Written by some guys from Google Ventures, the notion is a bit like the Scrum Sprint where the objective would be to have something testable with users at the end, but it’s on steroids. With a big emphasis on speed, the idea is that this could be applied to any problem you’re trying to solve, as long as the problem is big enough. It has to be important. The book guides you through the process and what to do each day, along with where to spend most of your time. All sounds great until you try to get all of the people required, your best stakeholders, (aim for 7) into one room for a whole week with limited email checking! However, there are a couple of great takeaways that could be used as part of this, but also as part of other parts of the product design process.

One of the exercises they propose towards the beginning of the Sprint is the idea of ‘Starting at the End’ – where clarifying the problem to be solved and making sure all of the team have a clear focus in which to put all of their energy.

“When a big problem comes along, like the challenge you selected for your sprint, it’s natural to want to solve it right away. The clock is ticking, the team is amped up, and solutions start popping into everyone’s mind. But you don’t first slow down, share what you know and prioritize, you could end up wasting time and effort on the wrong part of the problem.”

The method that really stuck with me and I could see immediate application for was the ‘How Might We‘ method. Originally devised by IDEO via Proctor and Gamble in the ’70s, the idea is to transform the way in which the team thinks about problems by reframing what we’re trying to solve and get a bit closer to the customer. It works by each team member applying the “How Might We?” question every time their hear something interesting, e.g. If were trying to sell a loan to customers we could start with some “How might we?” questions such as, ‘How might we help customers buy a new car, or a new kitchen?’ and ‘How might we create an environment where customers would trust us?’ Everyone ends up with a stack of notes they can then end up prioritising later and do some affinity mapping to bring similar ideas together.

‘When we tried it, we came to appreciate how the open-ended, optimistic phrasing forced us to look for opportunities and challenges, rather than getting bogged down by problems, or almost worse, jumping in to solutions too soon’

The book is an easy read, split up into bit-sized chunks so you can put it down and pick it up when you need it. I think it’s a great method book to read even if you never manage to convince your leadership to actually follow through with it. In addition there are a number of techniques in there which can be highly valuable at lots of other points – there are some good ways to make decisions here, particularly if that’s often your sticking point in Agile and Scrum it is often said that ‘Done is better than perfect’. The drawings are quite cute too.