MVP applies to teams, too

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