How do you know when to stop adding features?
by•
In the past few months, I have come to learn that building products isn't all about adding features.
Every single idea seems necessary.
Every single feature seems to be essential to improving the product.
However, each new feature brings along complexity, new use cases, delays its release and makes development harder.
Eventually, there comes a time when you have to decide which features are necessary and which are not.
For those entrepreneurs who have already built their products:
What criteria would you use to determine when your product is ready?
Was there any feature which seemed to be an absolute necessity, but turned out to be not very much needed by the users?
I'd love to hear the lessons you learned before (or after) your first launch.
29 views
Replies
I have noticed that once a product solve on problem really well, users are surprisingly forgiving about everything that's still missing.
@new_user___0932026a86e905cf4b2b7f7 Thanks for bringing this up. I think the right time to stop adding features is when each new addition starts making the product harder to understand instead of easier to use.
the test that's worked for me: does this feature serve the one promise the product makes, or does it just add capability? capability is infinite, the promise isn't.
concrete example from this week. someone pointed out a real gap in my app, trust validation for content provenance. genuinely useful, and i still didn't ship it before launch. not because it's hard, but because it wasn't required for the thing i actually promise. it went on the list instead.
the harder version of your question is knowing when to kill something you've already half-built. i had an idea that reused most of my existing code, cheap to build, and i dropped it entirely once i worked out it didn't fit what the product stands for. "we already have the code" is the most expensive reason to build something.
MonoCloud for Startups
The rule that finally worked for us, a feature is not done when it ships, it is a commitment you maintain forever. So the question stopped being "would this improve the product" because the answer is always yes, and became "are we willing to own this for years." That kills most ideas on the spot, and the ones that survive are the real roadmap.
We build identity infrastructure, so we feel this harder than most, nothing we ship can ever be quietly removed once customers depend on it. And to your second question, the feature that seemed essential and was not, a whole section of our docs we were sure people needed. Keeping it updated cost more than it helped anyone, we killed it, and nobody noticed. The launch teaches you what was necessary, the roadmap only guesses.