If it's a nice problem to have, don't solve it now

This is good, difficult advice. I'm working on an app, and it's so easy to go off the feature deepend. I recently spent a week trying to do data import/export - an un-requested feature by my 20 users. That time almost certainly would have been better spent marketing or otherwise finding more users.

I deleted my older comment.

For many "nice problems to have" I really disagree.

A nice problem to have can be a real problem. It's nice you are in that situation but it's still a problem.

Your site offline because of demand is a nice problem to have. It's absolutely one to solve right now.

Just to push back a tiny bit on this, sometimes nice problems can turn into nasty problems very quickly.

"My customer data isn't backed up", is a nice problem to have when you're just launching a new service and don't have any customers. But it's still a problem you'd probably like to solve relatively early. There won't be a moment where missing backups are an immediate problem but also still easily solvable; they're either a future problem or you're unavoidably about to lose a large number of your customers.

As a less on-the-nose example, sometimes when I'm building software, I can anticipate that something will be a problem two or three months from now. In those cases, I have a decision to make. If the code is disposable, I can ignore the problem and solve it later. But if I'm working on core architecture, spending an extra 2-3 days to solve the problem now can save me 3 weeks of refactoring in the future.

Many businesses start agile and become slow and cumbersome over time precisely because of this reason. They can't keep up the pace they started at because the technical debt, compliance issues, and future problems end up weighing them down over time.

I think there's just a balance to be had here.

I take a different attitude to "nice to have" problems. I work on a professional services team that is massively undersized relative to demand. Our role is less than a year old within the organization. We have far more clients in need of support from my team than we can give.

This is a great problem to have - lots of pent up demand. Nevertheless, it is a problem, and we must actively strive to solve it. It's nice to have lots of demand, yet if the problem is not solved, we will be giving up future revenue. A larger team will be able to support more revenue than a smaller team.

There is no part of this situation where it is a good idea to slow down on hiring, or to compromise on hiring standards.

Ninja edit: this is in contrast to things that aren't a problem yet. E.g., in the article, the author discusses not having password reset functionality. That is not yet a problem in the absence of users. It's not a nice problem to have. It is not a problem.

I think that this advice cannot be generalized. There are companies with large development teams spending staggering amounts of time solving problems they don't have and probably never will and companies burning through whatever goodwill they can find to extract maximum profit by throwing garbage, buggy, and incomplete software out into the market "because agile". Almost no one gets this right. I think the two sides feed off each other by each pointing to the other as an example.