Michael’s dilemma
|
My friend and fellow bootstrapper Michael Koper wrote on social media: My biggest customer requests a feature. It is useful only for 5% of our users.
I quickly spin up a Claude session to get the feel of it. It adds 900 lines of code, decent quality.
It makes the code more complicated, because it is in the core and it touches a lot of things.
They already are on a massive commitment, customer for 10 years. Biggest LTV we have.
Dilemma!!! For context, Michael’s company Nusii is currently a 1-person operation. It’s a solid product, more than 10 years old. What would you tell Michael? I’d simply say no. For me, this is not a dilemma. Here’s why: Technical debt Michael told us that the feature is in the core of his product’s code. This is going to make all future development more difficult. That’s technical debt, people. Technical debt slows down all future development, repeatedly, for every new feature and for every bug fix now and forever. Technical debt is unavoidable, of course, so you have to choose carefully what’s “tech debt”-worthy. A big lump of additional code to please one customer is not worthy. And yes, even code written with help from Claude or whatever AI tool of the day is technical debt, making all future work harder. UX debt A common story we heard in our research for Kill the HiPPO is that in the early days our software products get praised for being simple to understand and easy to use, but as feature after feature is added, they become a confusing mess of settings and buttons. Why add to UX debt for one customer? BTW: a nice cure to UX debt is described in Kill the HiPPO chapter 6: Add a Button; Remove a Button. It adds to the criteria for a new feature: what existing feature will we remove to make room for this new feature? Default to no When running a software company, you soon get overrun with feature requests. You learn to default to saying no to all requests. You might say it nicely, such as “we’ll consider it for the future”, but it has to be no. Almost certainly, a long-term customer is not going to cancel because they didn’t get one request satisfied. If the missing feature is a dealbreaker, they’ll ask for it over and over again before cancelling. I’ll assume Michael’s customer asked just once, which means it might just be a “well that would be kinda nice but we’ll live quite happily without it” feature request. Today’s 5% is tomorrow’s 0.5% What happens when Nusii doubles in size? becomes five times bigger? ten times bigger? That 5% of revenue coming from one customer (note: my assumption - Michael didn’t actually say this) becomes 2.5% or 1% or even 0.5% of revenue. Is it worth having an obscure feature that makes the code harder to maintain forever to please a customer that contributes just 0.5% of revenue? Will the customer pay for this? One interesting response to this dilemma comes from Tyler King, who features in Kill the HiPPO chapter 4: Can you charge them more for it? Seems reasonable to say that you've got to prioritize features that serve the bulk of your users, but you're open to custom development for the right price. We've done this before. I think we charged something like $75,000 most recently. Some of the founders we interviewed for Kill the HiPPO confronted this dilemma early in their product’s history, and went ahead and built the feature. They then regretted it for years afterward—and in one case even eventually ripped out the feature. And yet...perhaps it was the willingness to please early customers and to do things that don’t scale—such as building specific features requested by one important customer—that allowed us to survive the early days and grow to where we are now. Kill the HiPPO news
I’m looking for podcast opportunitiesDo you know of a podcast that would be a good match for a chat about Kill the HiPPO? If so, let me know! Until next time, Steve McLeod |