Deciding whether to implement sharing tools first, or an email importer, or to add profile picture, or even profile pages, can be a fraught and confusing exercise for young internet companies. Most founders with a strong point of view about what they want their product to do have an intuition for what the universe of features should be, but the extent to which those features should be implemented, and particularly the order of operations, has stumped many an agile development team.

Here is a framework to consider: while it’s very difficult to know which among the features you want are predictive of growth or stickiness, it is certainly the case that most feature implementations follow some logarithmic growth equation.

In these cases, the marginal utility (Y axis) of a feature is very, very high at a very basic implementation. As investment in the feature continues (X axis), the marginal utility very quickly tapers off, to the point where a large investment in the improvement of a feature will only incrementally improve the user experience. Because of this, feature implementation is somewhat counterintuitive. If you have a feature that, from the moment you implement it, things immediately start working better, leaving it *underdetermined* – that is, not investing too many more resources into developing it – may actually result in it being used more organically, creatively, and ultimately in a manner that drives better growth, while your precious product and engineering resources may be better focused elsewhere.

Not every feature implementation has the similar logarithmic growth curve. Some may be much more pronounced, whereby even the smallest investment in the feature will result in dramatic improvement in user experience, but which tapers very quickly. And others may be flatter, and will seem nearly linear. But it’s been my experience, and that of many folks I’ve spoken to, that for a cash-strapped, fast-growing startup, this curve overwhelmingly tends to apply to feature development. To that end, there are features, at basic implementation, that may very well be “table stakes” for a product to be minimally viable. If you notice that your users are hacking certain features in absence of you building them, these are hints as to how to distinguish between these growth curves.

But, careful: feature bloat can lead to a product having inertia, to a team not recognizing what the growth engines are, or isolating the really effective consumer behaviors. And so when you have a long list of features in your product pipeline, be careful not to implement *all* of them, but to focus on those whose marginal utility rises extremely fast.