FIXME: Needs more context, content and adaptation

The Minimal Viable Change (MVC)

We only ship in a Minimal Viable Product (MVP) style. Minimum Viable Change is an especially apt phrase for Technical Operations and Engineering and we’re often working in the context of making changes to our production systems and services.

MVC means we deliver the smallest possible solution that offers value to our users. To avoid feature bloat, we rely on user research to validate whether our idea addresses a business need in a desirable way. This approach sets us up to expend the smallest possible amount of effort to build new capabilities, while learning more about how to best add additional functionality over time.

While an MVC may not have the robust functionality of a fully developed feature, it should still address fundamental user needs through a bug-free and highly usable experience. The minimal viable change should not be a broken feature.

Advantages of an MVC approach:

• It prevents over-engineering.
• It forces everyone involved to look for the simplest solution to a problem, which is often the best solution.
• It forces working towards an 80/20 solution. While competing products might cater to the last 20% of the market, a minimal viable solution is good enough for 80%.
• A bigger change is harder to review.
• A bigger change is harder to roll back.
• The bigger the change, the larger the risk of a conflict with someone else’s contribution.
• The bigger the change, the longer it takes before everyone can benefit from the change.
• Further changes or enhancements to the change are driven by feedback from actual users. This is a much more informative mechanism than the intuition of a product person (this doesn’t mean we should just build whatever feedback tells us, however.)