Cross-functional collaboration is never easy, but it's particularly tough if you work at a company where Community is siloed.
Fortunately for me, at Groove, our product is our community. We're an accountability community for dreamers, doers, movers, and shakers who want to work in a great company — a free mobile app where members from around the world are matched with 1-3 other people to keep each other accountable in 50-minute focus sessions. Our community's needs are therefore inextricable from our product's success
Even with this, alignment between Product and Community has not been a walk in the park. It requires consistency, clear communication, and a systemic method of collaboration. Here's why alignment matters and how we've almost perfected it.
Our team at Groove is still relatively small, but collaboration is hugely beneficial even for bigger companies with a stand-alone product and a community to support it.
Community and Product teams often think quite differently. While my brain works somewhat like a yearbook with pictures of our community members and information about who they are and what they like or dislike, a product designer's mind may be on how to improve certain features according to what they've decided the user needs.
The good news is that there's a place where these ways of thinking align, and that is to create a product users and community members will love and want to use.
Some of the biggest problems that Product teams face are:
A community of users can assist product designers in having a base of users willing to offer feedback, share ideas, and become beta testers for their products.
When I started at Groove over a year ago, I realized there wasn't yet a formal way to communicate the community's needs with our Product and Design teams. This sparked the idea for #Pulse — a dedicated asynchronous Slack channel for our team to "take the pulse" of our community.
I go through all our community insights each week and drop them into our #Pulse channel.
These insights could come from our suggestion box, comments, requests from our members, or conversations between our members. Fortunately, I'm not the only one who tracks this. Our entire team takes part and drops significant insights they may have found in the community channels throughout the week or day.
This keeps most of the insights from our community in one place for all the relevant stakeholders to see. Then, every Tuesday, the day before our team sync, I compile all this information and prepare to present it to the team in easily digestible bullet points or as a story of what is happening in our community.
We hold our team sync on Wednesdays, and this meeting is joined by representatives from each department, including our Chief Design Officer, Tova Safra.
At this meeting, I share a snapshot of all the most significant community insights from that week with product and design in mind. Then, I translate conversations into feature suggestions and present requests directly from our community about what they'd love to see on the app in terms of functionality and design.
The great thing about having a community is that your members will tell you how your product has impacted their lives, and that can bring a lot of positive feedback to the people behind the scenes who work hard to bring the product to life. I usually take this opportunity to share these stories with stakeholders.
For example, one of our super users sent me an email about how she just graduated with her Master's and how much of her work on her thesis was within the Groove app, along with other groovers. She thanked the team and said Groove has really helped her through this process.
This feedback was really something to celebrate! And speaking of celebrating…
Taking the time to share the proverbial toast to your wins is also essential when taking the pulse.
Our team always celebrates things like when we added chat to the Groove app and how our customers received that. Or when one of our community members let us know that they were able to use the Groove app while on an airplane — that was our first in-flight groover and the perfect reason to celebrate how far we've come.
Last but definitely not least, on the agenda should be a data round-up based on the metrics your team is tracking.
I usually report on daily and weekly active users, how many groups were created within the app that week, and engagement numbers. This can get a little repetitive weekly, so it's important to add a few notes explaining the data and what affected it to your stakeholders.
Apart from our weekly pulse meeting, we also participate in weekly sprint planning sessions with Product, which are separate from their exclusive ones.
These work as a giant, company-wide to-do list and help us align once a week on priorities and also check in with each other on how things are going and review the past week. We all get to see how we're progressing on our team goals and what we'll be busy with in the upcoming week or month.
These meetings also help us to:
Manage different horizons: Each team lead has different timelines for their OKRs. Aligning these timelines can help all stakeholders understand how long specific agreed-upon objectives will realistically take.
Realign priorities: Things move fast, especially in a start-up. So checking in to ensure that we're all still prioritizing the same thing is essential, and we all have to realign what those are.
Figure out what we don't know: Sprints are an excellent opportunity for stakeholders to ask questions and update how things are progressing in different departments. This may be necessary to determine who might be out of the loop.
Build in public and take your community for the ride.
Collaboration with Product also means that your community needs to know that they are contributing to improving the product they're currently using. At Groove, we've intentionally been very transparent about needing feedback from them, which has led to having a separate channel for our dedicated beta testers.
How did we get here? First, we asked our members a few questions before bringing them on board, such as: how they'd like to contribute, how much time they're willing to spend on this and how long they'd like to stay in our beta group. This gave us a clear picture of each person's level of involvement. Currently, we have 12 Groovers dedicated to testing and suggesting new features for our app. They get access to versions of the app before the public releases.
Through this transparent and systemic collaboration, we've been able to formalize how we get feedback from our community and how we communicate that feedback with Product to ensure that our users get what they want from the product.
We're super intentional about making the community feel a part of the process, so much so that we even have a product roadmap that we share publicly each quarter. It's a great way to share how we're implementing Groovers' feedback.