I first wrote about minimum viable product (MVP) just three years ago, but the term itself was coined over 20 years ago. But I've been thinking about this more and more with all of my new projects, for one significant reason:

Even compared to five years ago, much less 20 years ago, association management software (AMS) systems have become remarkably complex systems. And as a result, the options, configurations, and setups have all become more complex and more time-consuming. This is why focusing on MVP has become more important.

When moving from one AMS to another, my rule of thumb is fairly straightforward for determining MVP: In general, anything you could do (and needed to do) with the old system you should be able to do with the new system at launch. (I'll grant there can be exceptions to this, but that's why it's a rule of thumb!) But beyond that, nothing is required at launch. That's the whole idea of a minimum viable product; what's the least we can get away with and still actually be live with the system?

Because new AMS systems are so complex, it's easy to get caught in the quagmire of "We should do this because we can!" Focus on what you need to offer and once the system is launched you can start adding more features and functionality.

But whether it's a new AMS, a new LMS, a new website, or any other new technology, always focus on the MVP. Because getting the system live and in use is far more important for long-term success than launching it "perfectly" (which isn't possible anyway!).