Yoav, knowing when a product is at the MVP stage is a really tough question. I would give you this vague and probably not very helpful answer: it’s a minimum viable product when it solves an important user problem. The trick is, you have to learn about real customer problems by observing users dealing with the problems you’re trying to solve. I find contextual inquiries a really great way to do this before I start designing a product at all. Observing problems and formulating solutions is a much better research method than asking users about either problems or solutions.

And I think you can ship early without visual indicators that stuff’s coming soon, unless you’re absolutely 100% certain that it is the next thing to be shipped. In fact, in many cases you might not want to commit yourself to adding specific features to your MVP. If it really is a minimum viable product, you can ship it, let it stand on its own, and immediately do more customer development to find out what features really should be added next. You want to iterate based on customer feedback rather than on the plan that you created before you shipped your product.

Also, do be careful with promising your users new features that are not yet built, since this has bitten me more than once. Sometimes, the feature you think is absolutely going to be built next gets pushed back for all sorts of reasons (some good, some bad), and this can disappoint users who will feel they were promised the feature.
Of course, there are exceptions to this, so I don’t want you to feel like you should never put in a placeholder or help text!

Thanks again for reading. I think figuring out when you’ve got a minimum viable product is a great topic for a future blog post. But I’m not promising anything!

Laura

Do you have any tips on knowing when the minimum viable product for a first release is really that? That is, when the promise is shown enough.

Would you ship early and supplement the UI with visual indicators or help links about stuff that’s coming soon?

It’s very frustrating when this happen, but we should learn from that.

The biggest problem I’ve had in developing new features has always been adding them to shaky basics which never seem to be a priority to get right because of the constant desire to meet vicious product role out schedules.

My favourite analogy is of the film industry: how much pre-work is done down to the finest of detail prior to the decision to commit finance and give the go-ahead to shoot? Of course, not all films are box office hits, but the ability to plan properly surely minimises the chance of getting it completely wrong.

Thanks again for a great article.

Too much of the churn in features just amounts to noise. That noise costs your users time, so to save their time, they never get around to using your new features. It doesn’t mean much more than they just don’t have time to deal with it right now.

Your portfolio of features is also a zero-sum game. When a new feature is being used, some old feature isn’t being used.

Your mention of product adding feature upon feature is what we call feature bloat. Feature bloat is critical for the product when it faces the early mainstream, IT, market. But, moving into late market, the UI must be sublimated, made simpler for the non-geek. There is no general rule that says sublimated is better for all markets. Each market presents its own requirements.