Why You Shouldn't Wait for Dev or Product Help
Greetings my fellow community managers,
Many of us struggle to get the needs of our communities met by company product and dev teams. This has been true for me. However, don’t fret. Sometimes not having the dev or products help at first is a blessing in disguise.
The 7 Cups community has made many suggestions along the way that we did not have time to fully develop with our product and dev team. This did not slow us down though. Usually, there is always a creative solution to whatever the problem you are trying to solve that can be done manually, with no dev help. The project may not function at scale but it can be a helpful test ground for future features and product changes. And this method has real benefits. Some of these include:
Including your community in problem solving. Letting them be part of the process pushes the ownership of an idea out to them.
First iteration of an idea always has problems. If you test an idea out first you will learn a great deal. These learnings will inform future product and dev updates. By the time you get around to developing the idea with you product team, you will have first hand experience it, hopefully some data you can refer to related to the idea and general sense of what will work best in a future feature.
I know developing an idea independent from dev or product teams help can sound scary. But as someone who has done it many times at this point, I can assure you the result of your efforts is well informed features.
Don’t fret, there is a process you can lean on while doing this! This is a startup methodology I have leaned on over the years. You can even share these ideas with your community and let them help you brainstorm ideas and solve problems. Some of the best solutions to problems don’t come from me, but from the community.
Identify the problem in the community you want to solve.
Write out the solutions. What are your hypotheses on how to solve this problem!?
Select one hypothesis you want to experiment with and identify a metric you will use to track the success of your hypothesis.
Experiment! Figure our way to manually test your main hypothesis.
Learn! Lean on user feedback and the data! See what is working and not working.
Iterate! Change and update the hypotheses to better meet the feedback and metric goals.
Here is an example from my work:
Problem: Listeners need extra coaching and support when they first join the listener community.
Possible Solution: Match new listeners up with experienced listeners in a learning buddy type relationship.
Set up a system by which new listeners and veteran listeners get matched up.
Metrics: Track the number of people who participate in this buddy program.
Experiment: Find a group of experienced, high rated listeners and ask them to be part of the project group. From here, set up a google sign up sheet where newbie listeners who are struggling can sign up to get connected with an experienced listener. The experienced listeners have access to the response sheet. When a new listener submits, the experienced listener, signs up to “connect with them” on the response sheet. They reach out to that new listener directly and support them in whatever way is needed.
What did we learn? A lot!
When the experienced listener reaches out to the newbie, many do not respond (even though they have signed up). The reason is response time and our new listener funnel. People want ondemand help. Support a few hours or days later is not as helpful.
It’s difficult to keep the experienced listeners engaged in the project. Many drop out. So we have a quick turn over. We added game elements to incentivize long term participation.
This project does not impact the quality of listening newbie users provide. Broader data related listener quality has not been impacted.
Listeners who do chat and connect with a more experienced listener tend to feel more connected to the community, more comfortable in their listening skills and stick around longer.
Iterate! We know from user funnel data that the problem we are trying to solve with this program is an important one. To effectively reach more newbie listeners, we will need more dev and product assistance, which I will continue to advocate for. In the meantime, I have learned some important lessons about this idea that will be critical to any feature release related to solving this problem. I have informed ideas about what specific features would be needed to best solve this problem. I understand how our users are most likely to respond to this idea in execution and I can account for that in product development.
This program still runs manually in the community. As of February 2018, I can report, we are working on another manual iteration of this idea. Whenever there is time, we hope to create a more formal product solution to this problem. Anyone reading this, I encourage you to get after it. If there is a problem in your community that you want to solve, don’t wait. No harm can come from this process besides finding out your idea simply won’t work, which is helpful to learn any way.