I think one of the biggest myths in tech is the myth of the MVP. The MVP gives a team a goal to rally around, but it sets unrealistic expectations of what the product will continue to be. An MVP implies that the product will be successful, and won’t need a lot more work or maintenance. When teams rally around an MVP and the MVP is not the successful version of that product, those team members are left with feelings of failure, disappointment, and burn out.

Dropbox new products team

One of the mistakes I made on Dropbox’s new products team was that I used MVPs when I should have used a demo. MVPs imply that the product will go on to have a long life; instead, when a team is trying out a new product or set of features, the team needs to leave plenty of room for the possibility of failure. The term ‘MVP’ precludes this, and instead teams should understand they are really building a data-gathering demo.

Dropbox desktop app push

On another team, I saw the problems that expounded as Dropbox made a huge push to create the first version of their desktop app. Teams worked overtime and were rallied around the goal, and were expecting a huge payoff after the initial shipment. However, the product was slow to catch on. The hundreds of people who worked on it were incredibly disappointed and burnt out. They were unable to rally to push forward and iterate on the product at the same level as before, which is just when the product needed more excitement and more pushes.

Vsho’s versioning

When we were building Vsho we were very careful not to use the term MVP, but instead built in weekly demo sessions and adhered to versioning. If V1.3 was a better experience than V1.5, we were happy to roll back the changes. We were able to move quickly and with excitement, understanding that everything we shipped was ultimately an experiment that we were learning from. We were wary burn out, and didn’t set unrealistic or overly complicated goals for our versions. In short, our expectations were met and we didn’t become disenchanted.