> But the development team still needs to be paid and the advanced features they add each year tend to be harder to implement, so over time the costs are increasing while sales go down.
Do they need to? I mean, if users don’t see the value in spending $150 for a few new features they don’t use, that says that maybe the ROI isn’t there for those features.
Think about the marginal value of each hour of developer time.
Value = number of feature’s users across the product’s lifetime * utility of the feature per user / cost to implement that feature.
Early in a product’s lifecycle the features added have high utility (you add the most important features first) and most of your users haven’t bought your product yet. (So features are a long term investment). Marginal expected value is high - assuming you get the sales. Later in a product’s lifecycle the features are more marginal (and often more costly to implement). If users don’t want to pay for the upgrade, what they’re saying is the new features being added aren’t worth the development cost. If the user base is still growing it might still be worth adding those features. But at some point you should entertain the idea that the product is essentially done. The best play might be to move most of the engineers to a new product. Keep a small team which can fix bugs, renew google maps API keys and add ARM support and so on and call it a day. Profit should go up at that point because you should keep getting sales while your costs plummet. Over time sales drop as your old product has sold to most users who want it, and in that time the income can be used to bring a new product to market.
This is the model the video game industry uses (to great effect). Why are we so allergic to the idea of “feature complete” in software?
The alternative is what Adobe does - try to wring ever more money from your customers while providing them less value each year. It’s no wonder customers are desperate for alternatives to their products.