(This was originally a draft chapter of the book. I've removed it from the book and made it a blog post.)

It took more than a year to complete the interviews for Kill the HiPPO. We usually worked on a single founder story at a time, from start to finish, before moving on to the next one. Founders are busy people; it would take considerable time to find the right people, get them to agree to be interviewed, and get their input on the draft of their story.

That gave me time to reflect on each story as it was being written, and to consider how I might apply to my own product. It’s been very helpful. Here are some things I’ve changed due to my work on this book:

Spark “Wow”

James Kennedy’s story ("Does It Spark Wow?") helped me understand that sometimes you have to build features - at least partly - for the sake of the sales process. Adding a certain pizzazz that jumps out during demos is important. I’m now ensuring I allocate time to “wow”-sparking features.

Build for one well-chosen person

Bridget Harris’s story (Building for “Simon from Canada”) introduced to me a new way of doing customer research. Instead of talking to lots of customers thinly, talk to one customer deeply and often. We have a customer who exactly matches our ideal customer profile, who is friendly and approachable, and who loves to give us feedback. I now encourage him to give us even more feedback. I bump the priority on things he requests.

I still do talk to lots of customers thinly - I think it is extremely important for the creators of software products to do this. But I also have identified and encouraged that one “Simon from Canada” - style customer.

Set a seasonal theme

Peldi Guilizzoni’s and Liz Green’s idea of setting a theme for the next “season” (be that a month, a quarter, or a year) has helped me understand the need to allocate time for things that might be ignored.

For three months, we had a “lots of tiny UX improvements on existing features” season - those littles things that never seem as important as the big new features you work on, but together make your product more enjoyable, productive, and intuitive for existing users.

Build the “CarPlay” features

Tyler King’s story (Cupholders vs CarPlay) might be my favourite one in this book. But so far I haven’t found the essential “CarPlay”-style features missing from our product. This concerns me; I might be missing something very important. I’ll keep looking.

Constraints are good - even artificial ones

Like Anthony Eden’s experience, I’ve had my team work on features that never seem to be finished and ready for release. I’m now setting strict limits: we must get something created that is usable and delivered to our customers within a month at the most. If that’s not realistic, we’ll break it down into smaller sub-features and work on delivering one of them.

It’s frustrating for the team - and even more so for the founder - when you are working hard but never delivering.

Remove features, settings, buttons

As Max Seelemann describes in his story ("Add a Button; Remove a Button"), your product’s simple and clear user interface gets destroyed over time as you endlessly add more features. I realised from Max’s story that I should have said “Enough!” some years ago with the creeping complexity in my product’s settings.

So I checked our analytics for seldom-used settings, and eliminated them. Now when we are adding a new setting, for example, we are always looking for another setting that we can eliminate. One that might have made sense a few years ago, but doesn’t now.

I was surprised by how easy this was. We found a setting used by just one person, and due to other settings they had applied, that setting didn’t even have an effect!

Lean into being the product manager

Kieran Delaney’s story (“Until Your Company is Much Bigger, YOU are the Product Manager”) is about accepting that as a founder you shouldn’t delegate the product manager role too soon. Until you realise this, it’s frustrating trying to balance your product management hat with all the other hats you are wearing. I now accept that I shouldn’t delegate it too soon; there are many other roles I should be delegating first. Product management is so deeply important to our product’s success, so I should keep doing it until the company is too big for me to do so. And for small, bootstrapped companies like mine, that day quite possibly will never come.