MVP applies to teams, too

A group of people with laptops sitting around a rectangular wooden table.

You’ve probably heard of the “minimum viable product” (MVP) concept when creating a product. The general idea is that you shouldn’t make a fully-featured version out of the gate. It will take longer and might end up being the wrong thing. Instead, you should make the version with the smallest feature set that’s still useful to early adopters. From there, you can gather real-world feedback to improve future versions. Over time, you add more features until the product is done (to the degree software can ever be done). This makes sense for product development, but it applies just as much to teams.

When you’re starting or re-starting a team in an open source community, there’s a lot of enthusiasm. You have ideas about what the team can do. Others interested in joining the team have ideas about what the team can do. So you develop a grand plan and accomplish…very little. What happened?

The Flywheel Theory says that once a team loses momentum, it’s hard to rebuild it. Never having momentum is a good way to lose it. If you’re not building a minimum viable team, it’s easy to end up in a position where little is actually getting done. This means that people don’t see accomplishments and their initial enthusiasm fades quickly.

When you’re building a team to do something in your community, make that thing very small to begin with. The scope should be small and tightly coupled. For example, start a documentation team by making a team to write release notes. Don’t worry about translations, user guides, et cetera. As the team is successful, you can start to add more to the team’s scope.

It’s hard to contain your enthusiasm when you’re starting something new. Keep in mind you’re trying to be sustainable, which means pacing yourself. Otherwise, all of that enthusiasm goes nowhere.

This post’s featured photo by Christina @ wocintechchat.com on Unsplash

Ben formerly led open source messaging at Docker and was the Fedora Program Manager. He is the author of Program Management for Open Source Projects. Ben is an Open Organization Ambassador and frequent conference speaker. His personal website is Funnel Fiasco.

Share

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.