Kill the HiPPO

Hello! There's a new chapter for you to read in the beta version of Kill the HiPPO, the book I'm co-writing on feature prioritisation for bootstrapped software founders. The chapter is “We Sell ‘Shovels’, Not Stacks”: IDRsolutions’ Mark Stephens initially developed an end-user application for a customer with a niche use case, but ditched that product in favour of selling software components, or “shovels”, as Mark calls them. 25+ years later, the company is still going strong, with Mark...

Hello! Back when web development was a new thing in the mid 1990s, the websites we built were limited to a palette of 240 so called “web-safe” colours. And we had to make sure they worked well on a resolution of 640 by 480 pixels. At the time, that was the best on offer from many monitors. These were terribly tight constraints, but they made the job much easier. When you have tight constraints your choices are limited. And those limited choices make decisions easier. In many cases there is no...

"In the early days we added too many features." I've heard this from most of the people we've interviewed for Kill the HiPPO, our book on feature prioritisation for bootstrapped software founders. In a research interview we conducted yesterday, the interviewee shared a powerful way to stop the inevitable UI clutter that results from this: You want to add a new button? First remove a button.Likewise, to add a new setting, first remove a setting. (I can't say who the interviewee was yet; our...

A couple of weeks ago I gave a "lightning talk" about Kill the HiPPO, the book I'm working on. A lightning talk? My talk was titled "How do bootstrapped teams really choose what feature to build next?". I started with a quick summary of the concept of the book, then sped through 5 unique approaches I've discovered so far in the interviews Siew Ann (my co-writer) and I have done. I presented the lightning talk at the annual Business of Software Europe conference, in Cambridge, England. Much of...

How much can one helpful customer shape your software product with their feedback?A lot - if you let them. To gather material for our book, we've been conducting interviews with software founders. An unexpected result of these interviews? They've helped me better understand my own journey while building Feature Upvote. For example, the story of Simon from Canada reminded me of how much help we received from Ruben from Spain. In our interview with Bridget Harris from YouCanBookMe, she told us...

One of our beta readers is enthusiastic about the concept of Kill the HiPPO: In my opinion, feature prioritisation is much less scientific than some books make us believe. For me it feels much more like playing jazz. There are constraints, sometimes more and sometimes less. Who is building the software, how is the market (enterprise, b2b saas, b2c, ..), the resources at hand, the stage of the company, how mature the product is, etc. Reading interviews and getting inspired by real world...

There's a seemingly popular "framework" for working out which feature to build next, called RICE. RICE was introduced by Sean McBride, while he was a product manager at Intercom. (I write "framework" in quotes, because to my eyes it is a weighted formula, and not an entire framework.) I don't think RICE is very helpful. RICE - and similar "frameworks" - provide an illusion of objective decision-making, while being utterly subjective. Here's a brief explanation of RICE - but it's better to go...

On your feedback board, you've got 3 or 4 popular customer suggestions, each with 100s of votes. And you need to choose which one to build next.How can you choose? 🤔 Here are some criteria you might be use.Which one is easiest to build?Which idea can you build and deliver the soonest? If all else is equal, then this is certainly a simple way to decide.Which one is easiest to maintain?This is quite similar to the previous question, but adds the wisdom of long-term thinking.Which one requires...