Konawaba, Couchsurfers! Today we’re addressing a question from the Beta Panel: Why does Couchsurfing launch new systems on the website without obvious features?
We’ve been discussing how this strategy applies to the Events system as we get close to launch. There are a few additional features that members of the Beta Panel have requested we build before launch, like calendar integration and allowing events to have multiple organizers. My response has been: “I totally agree, but we’ll wait until after launch to include it.”
As you can imagine, this can be frustrating for members who have sometimes spent years asking for specific features we have yet to build.
How We Develop Software
When we develop software at Couchsurfing, we’re creating a Minimum Viable Product, or MVP, an idea popularized by Eric Ries.
The basic MVP strategy is to gather validating data that tells you what your community needs, then build a system to satisfy those needs. Once you’ve released this system you can learn from the ways people use it. By first assessing user needs, then testing whether we met those needs by releasing a minimum viable product, we’re trying to find what is called “product-market fit.” Product-market fit means that you built a system that meets your user’s needs.
During most MVP processes, the development team has to gather data by creating mock websites that measure whether there are customers that would use the product they’re building. Since Couchsurfing has been around for some time, we already have members. We’re able to watch how Couchsurfers are currently creating events across Couchsurfing, Facebook, and Eventbrite. We’re also able to talk to Couchsurfers about what they need from an Events system.
Before We Start Building Software, We Look At User Needs
Before we started building the Events system, I gathered validating data for Events in a few ways:
- I interviewed Couchsurfers who organize events like CouchCrashes and weekly meetups about how they organize and what their needs are;
- I cataloged all the features that Meetings and Activities currently offer; then
- I asked even more people what else they were missing.
Interviewing users gave me a lot of qualitative data about their frustrations with the current systems. I catalogued all the features users currently have access to in Meetings and Activities, then reached out to about 100 more active event organizers across the world to gather what they thought was missing. I also collected ideas for features they believed were necessary. After doing this, I determined what our MVP for Events should be.
Developing Events to Address Two Un-met Needs
The two most notable features event organizers wanted that we didn’t have in our existing system were creating recurring events, and mass-messaging event attendees. By including those two features into Events, I think we’ll have created a system that better serves the community needs than either Meetings or Activities.
This is where we come back to developing a Minimum Viable Product and why we launch systems without additional features. I’ve made a number of assumptions in developing the basic functionality of Events, the MVP. If I’m wrong about how Events should work at their most basic level of functionality, I want to learn that as quickly as possible. The only way to learn about how people actually use software is to let them use it.
Releasing, Learning and Improving Events
By releasing an MVP of Events and learning from it, we’ll be able to quickly determine what to fix. Getting basic functionality down first is more important than whether a system has all the features that seem obvious from the first day.
This is why we release software without every additional feature (like adding Events to your Google calendar). Events should still serve the broad needs of our members without additional features, while also giving us time to learn before building additional “nice to have” features.
I’m aware that software was released in an incomplete state at Couchsurfing in the past and perpetually remained that way. The Activities feature is a great example of this approach. Activities has very limited functionality compared to Meetings and it hasn’t been improved since.
In contrast to our current approach, Activities were not rigorously tracked in order for the team to keep improving it. Continuing to work on a system once it’s been released is a hallmark of maintaining product-market fit once you have it.
As an organization, we know a lot more about how Couchsurfers want to use Events than any other system we’ve launched. We’ll be collecting both qualitative and quantitative feedback after we launch Events about mistakes we made while building it, as well as features people need to create successful Events. And once we have a solid system that satisfies event organizer’s needs, we’ll start adding additional features.