Death by a thousand paper cuts

Hello!

Kill the HiPPO news

In last week’s email I mentioned that a German-language product management blog published a post about Kill the HiPPO; in the following days, I sold a few copies on Amazon’s German site.

It’s satisfying to see an immediate result from a promotion effort, especially in comparison to the marketing efforts for my company’s software product, which typically take months to show any results.

Also last week I was interviewed on the Rogue Startups podcast about Kill the HiPPO. Craig Hewitt, the host, asked me some questions I wasn’t expecting, keeping me on my toes! It’s not yet published, but hopefully will be soon.

I’m still looking for podcast guest opportunities - particularly lower profile ones at this stage where I can hone my message without the stress of a big audience.

Death by a thousand paper cuts

The founders we interviewed for Kill the HiPPO seemed to me to be like artisans, who care deeply about the quality of their product as well as the customer experience. That’s no accident; we chose carefully who we wanted to interview.

They - without exception - make great software.

Unfortunately, there are other software companies out there, who don’t care about the fine details.

So much software is painful to use.

Although it serves its basic purpose, everything is harder than it needs to be. Workflows don’t make sense. The help docs are woefully outdated. You need to go through an awful process of “click-wait-scroll-click-confirm” to do something that should be a 1-step process.

You know the software I mean. Probably some product you have to use every day. You need to psych yourself up before using it.

To avoid our software ever having that “death by a thousand paper cuts” experience, I have some policies for our team:

• “When you see a bug, a mistake, an outdated doc - report it immediately.” In our case, it is reported to me, via Slack. Our team is tiny; that works for us. If our team was bigger, I’d create a dedicated email address, such as bugs @ featureupvote.com - and maybe even assign someone each month as the “chief problem fixer” for that month. The important thing is the reporting procedure has to be quick and informal.
• We prioritise bugs over features. Fixing a bug is ten times more important to me than adding a new feature. You might argue that having one or two minor bugs is tolerable, but over time, that attitude allows too many minor bugs, all of which compound to become bad software.

These two policies build on each other. When a team member reports a problem, and then sees it immediately fixed, they discover that they are actually being listened to and they realise the team cares about quality. This makes them more likely to report other problems they find.

Some other practices help too:

• Dogfooding. Strange name, important practice. I wrote about this last week.
• Regularly demoing our software. It forces us to encounter any ‘paper cuts’ right in front of people. If something happens during a demo that I’m slightly embarrassed about, we fix it.

I think this approach is working. This is one of my favourite pieces of feedback about our product:

Kill the HiPPO is all about building features. But sometimes building a new feature is the wrong priority. The right priority is making sure your existing customers feel that your product is a joy to use, and not a “death by a thousand paper cuts” experience.

Do you have a system or policy to ensure your product stays a joy to use?

Let me know about it! I’d love to share it with others in a future email.

Until next time,

Steve McLeod
​​​killthehippo.com​​

​
​