Sprint – How to Solve Big Problems and Test New Ideas in Just Five Days

I finished recently Sprint – How to Solve Big Problems and Test New Ideas in Just Five Days (Jake Knapp with John Zeratsky & Braden Kowitz, 2016, 288 pages). And I think this is a great book, that fits perfectly well in the bibliography for Product Discovery, which I’ve been fascinated about in recent times.

To start with, the book is based on lots of first-hand experience by the authors running over 100 sprints in total, and having adjusted several details on how to go about doing it.

The book brings not only the rationale behind why one should to run such a Design sprint, but it also breaks the sprint down to the hour level describing all the activities involved.

Behind the idea for a sprint lays the strategic value involved in picking some great hypothesis about a product or service, prototyping one or two possible solutions, and testing them against real users. This is at the core of Product Discovery, but this book makes it very concrete for someone looking for where to start.

I love how the process goes away from group thinking and traditional brainstorming sessions to actually cater for both learning from the experts, to sketching of solutions individually, to reviewing them efficiently in group, to gathering real feedback from real potential users.

Add to it some sprinkles of good stories from real-life sprints the authors have run themselves, and the mix is a great book for anyone trying to move away from “old” practices into modern ways of organizing tech product teamwork.

Inspired

I have recently finished Inspired (Marty Cagan, 2nd edition, 362 pages). This book is definitely one of the best in a long time for me. I wish I have read it 10 years ago.

Personally, I think what struck me the most was the contrast between modern Product Discovery practices described in the book, and a large amount of initiatives I have been part of myself, either as a Product Manager or in other software product related positions, along the last 10+ years.

Software products are not easy to get right. And there are other good books out there, even classic ones, that make this point very clear. Products are difficult.

The difference here is that Marty Cagan has himself lots of hands-on experience with really great product teams. And he has also consulted for teams that built products we all use today. So, he has insight on How to do it.

The essence is again on Product Discovery, with emphasis in finding and testing value and growth hypothesis. But the book goes all around the culture, methods and techniques to actually get that done. And it is also very honest on how much work it entails.

One of the parts I like the most, having worked myself with B2B products for many years, was the description of the Customer Development Program. That involves basically recruiting 6 different clients that can work together with the PM, designer and the development team, in order to frequently test usability and (feature/product) value. Based on my personal experience, I think this method is indeed bound to success. Although, as the author says, it involves A LOT of work.

The book contains also some good hinds to further material that can be explored to get into more details about for some of the main techniques. I surely got my reading list increased after finishing this one. And I’m looking forward to dive even deeper into topics that I think can make all the difference between hard work and failure, versus hard work and high chances of success.