Building communities in Virtual Reality

How I found product market fit for the Reality Labs Communities product in 90 days.

Zero

Communities

At the outset we had no communities product

117k

Communities created

Over several months users organically created communities

58k

Average DAU

Daily active users for mobile communities

The challenge

While Virtual Reality is fun, research revealed it can also feel isolating. Teens and Young Adults (TAYA) expressed a strong desire to find like-minded people to play with in VR, but getting together in a VR world can be surprisingly difficult. Multi-world-instances, world instance capacity, confusing invitation systems, time zones, and technical hurdles all conspired to make the simple act of playing a game together a challenge.

This is made even worse given that players can engage in the same world from both headsets or mobile devices at the same time.

Beta launch

A week after kick-off the team realized we had to move our original launch date up by 30 days to be ready for Meta Connect in the fall 🙀. So, we had to hustle and cut some features. Below is the VR Beta we shipped with a few key details:

We recruited power users to seed the experience as "admins" for the first communities
Admins selected a single associated "community-world"
10% of organic traffic could discover communities
The product supported up to 250 members per community
To expedite shipping we nested Communities within the Horizon OS Chats App

Good signal

Almost immediately we saw the product be taken up by VR players. From the middle of April through the end of May we saw Communities DAU rise from zero to 17.6k. However, we weren't seeing the same level of engagement on mobile, which was about to become a priority.

We need a new strategy

That we had built the Communities Beta for enthusiastic headset users—and that it was taking off—no longer mattered. We needed to demonstrate product market fit on mobile quickly. I dug into how Communities were performing on mobile and uncovered some concerning issues:

While our 1:1 world-to-community association made sense for engaged headset enthusiasts, it made little sense for less engaged mobile users who jump in and out of play.

The "invitation model" for getting together on mobile was long and confusing. On very low days only 6 invites were sent on mobile within communities 😱. Invites wasn't our team's purview, but this had to change.

Users were confused by a feature called "Meetup Spots," which pre-dated my time with the team. In order to make progress we needed to deprecate that feature to make room for what would come next.

A new vision for communities

Now was a good time to step back and think. We rushed to ship the Beta. What would we build if we weren't rushed? I thought about it, dogfooded the experience (a lot), tested competitors, and monitored the data daily. Ultimately, I wrote a new Vision for Communities that helped me rally the team around some new core principles.

Play first: Chat must become secondary in the IA. We built upon the chats app out of convenience, not because it was the right underlying primitive for our product.
Competition: Leaderboards (should hopefully!) drive retention. Most other gaming experiences have them.
Collaboration: Community-oriented quests create identity. Quests existed elsewhere in our system already.
Knowledge sharing: Real-life communities teach members how to level up their skills. Our product should do the same.
Rituals: Communities need clear expectations around scheduled time to get together.

This product vision document is how I built belief among PM and Engineering, creating the opportunity space to remove under-performing features and replace them with better ones.

Deprioritizing meetup spots

To make room for this new vision in the interface I aggregated all available information about an underperforming feature called "Meetup Spots" and invited my product partners and leads to a "deep dive" session. I convinced our PM Lead, who invented the feature, that we should remove them in favor of better potential new ones.

Adding an activity banner

We tested the combination of the activity banner and meetup spots to see which feature performed best. This new activity banner displayed community member's online status and "joinable" activity to other community members, enabling members to see the obvious opportunities to get together. This sounds simple, but there were many legal and privacy implications I had to navigate to ensure compliance with Meta standards.

Play-first information architecture

Next we needed to solve the invitation model problem by expanding the invite-concept and increasing the number of worlds associated with a given community. Visiting a community-associated world, or sending an invitation to a world from within a community, became a broadcast invitation to community members that you were ready to play together.

Leaderboards for the win

Now that community admins could associate their community with more than one world we needed to increase member's desire to engage with one another. Games are competitive by nature and other teams were experimenting with leaderboards. All we had to do was import existing leaderboards from associated worlds and limit the user list to display only community members.

The results

Communities was my first product within Reality Labs and required a significant learning curve to understand the technical complexities of this multi-platform virtual experience. Communities was nearly always in danger of deprecation as we sought Product Market Fit amid shifting organizational priorities. This product taught everyone on the team, myself included, the value of perseverance and close collaboration with your partners. Ultimately the final metrics speak for themselves.