Creating MVPs that are not minimally viable products

Creating a product takes time. There is always the chance that a feature you designed completely misses its goal because a user doesn’t understand or like the flow that has been created. The way to reduce this feedback loop is to put a product in your customer’s hands as early as possible.

I’ve heard a product manager actually say “that label should be red, this is MVP gating”. “MVP gating” means that this problem will stop us from releasing the minimum viable product. However, for most product managers, it is their way of saying “I won’t approve this app for release”. This was a project that ended up having a 13 month release cycle because of all of the “MVP gating” and bug issues. The point of an MVP is to make sure the features you are creating are actually what the customer needs. Otherwise, you can spend a year developing a feature that zero users interact with.

Scope creep for projects is a major problem. This does not mean that you should release poor quality software, but rather to focus on polished feature turn around so you provide the best value to a customer. The customer is the person that needs to be happy, not the CEO of the company. Make your customer happy and the CEO will love you.

Inevitably, when scope increases, it puts more pressure on the deadlines of the project. Increasing scope leads to more technical debt because you have less time to polish all the features. Zero customers will be unhappy about a feature they don’t know exists, but all customers will be unhappy about a feature that doesn’t work. Beyond that, there is a point where working like this becomes a waterfall process because every fix has another low priority bug. Eventually you are not iterating on the development anymore.