Introduction

Introduction #

This site is a work in progress, made public for review and feedback. Learn more.

This book is not what we set out to create.

At first we intended to create a guide to feature prioritisation for first-time product managers at software companies. We would write chapters on popular prioritisation frameworks like RICE, as well as chapters on lesser-known approaches.

When we started researching the idea, we discovered that just about every product management tool had already created this as website content. And they were all rather same-y and unconvincing. They felt like they had been made as a content exercise, and not from any real-world experience.

So we refined our idea for this book: we’d talk to actual software companies to learn how they had introduced formal approaches to feature prioritisation. The software companies would be mostly founder-owned (that is, without venture capital investment) and they’d be at a stage where they had only recently introduced a formal product manager role - or were yet to do so.

From those interviews, we’d get quotes and examples of how people are using the well-known prioritisation frameworks.

That was the plan, anyway.

A strange thing happened during the first three of these interviews: we discovered that the people we were talking to weren’t using the popular prioritisation frameworks. We listened to their stories and realised that feature prioritisation can’t be reduced to a simple formula. It is hard and messy and based on many unknowns and competing aims. And it isn’t constant. What works in the first year or two becomes counter-productive in the following years.

Sometimes the priority is to build, and sometimes it is to un-build, if there is such a word. That is, to remove features that turned out not to be worth maintaining. And sometimes you need to spend your team’s amassed energy and time doing something other than building new features.

Even at successful software companies, working out what to build next in your software product is hard. It involves weighing up many factors, some commercial and some technical. Yet these factors are not easily quantified and compared.

And we found the stories fascinating and illuminating. We wanted to hear more of these stories of how real teams at real software companies went about choosing what features to build next.

So we decided to make this book mostly consist of interviews with teams at small1 software companies. And that’s what you are now reading.


  1. By small, we mean between roughly 20 to 50 employees. ↩︎