Driving an open-source community using productboard

As product manager at Strapi, I had major issues keeping track of every single suggestion and keeping my mind clear with the humongous amount of information sent to me by the community.

Our biggest strength is our community, we love receiving new use cases, insights and feedback from everyone. We also like to talk, share and discuss about the next steps or features.

The first solution we thought out was to create a vote page on our website (https://strapi.io/vote). The question was simple: what are the most wanted features? We got more than 7000 votes in less than 10 months. It helped me and the team in defining the priorities and the roadmap. However, there was still many unanswered questions... what are the real needs of our users? What are the use cases behind each vote? Who are the people who voted for a specific feature? How do I know if this feature is critical to them?

But a lunch changed my life (no kidding): it was a lunch with my friend Robin Lambert, co-founder and product manager at Livestorm. Discussing that issue, he recommended to take a look at productboard. It was a game changer for me. It was the tool I was looking for to get organised as product manager.

For those of you who don't know productboard yet, it's product management software that helps you to understand what users need, prioritize the next features to develop and define a crystal clear roadmap.

At Strapi, we are receiving feedback from many different communication channels such as GitHub, Slack, StackOverflow, Spectrum, Twitter, email, etc. I was referencing everything in Notion by hand. It was way too complicated to classify and keep everything synchronized until productboard came to the rescue. Now we have a dedicated and centralized place where we're redirecting everyone.

For example, here are a few use cases of why I really appreciate working with this software:

• Member A: Do you have a roadmap? Our answer: Yes, go check out our public portal (https://portal.productboard.com/strapi).
• Member B: Do you plan to support multi-languages? I'm working in a company based in Switzerland and we have four national languages (German, French, Italian and Romansh). Our answer: Sure, take a look at our roadmap and feel free to give us more insights! (https://portal.productboard.com/strapi/c/19-content-internationalization)
• Member C: I can't find any information about Firebase support. Is this planned? Our answer: No, but you can submit this great idea through our public portal. (https://portal.productboard.com/strapi/submit-idea)

Moving from nothing to productboard

As I said before, I was referencing the feedback and ideas in Notion. The feature requests were listed on our GitHub repository hidden between the issues. Our first action was to close all the features requests on GitHub and move them to productboard if they were relevant according to our strategic vision. I merged and aggregated the ideas referenced in Notion into the features cards created in productboard.

At the beginning, I was a bit afraid about making this brutal move but everyone seemed happy about it. In less that four hours, every feature request from GitHub had been migrated over to the portal, apart those very specific ones that didn't benefit from productboard insights management.

To complete this move, we updated the Feature Request template to encourage users to go to the public portal instead of opening a new issue (which would anyway not be an issue but a feature request). We also asked our most active members in the community on Slack to push the link as often as possible and redirect users there if needed.

It was a relief to be able to take back control on the product roadmap. GitHub wasn't the right tool to manage the vision of our product. Since the first day of using productboard to manage our community roadmap, we received more than eight hundred productboard insights from the community (~20/25 per day). We reduced by 3x the number of messages on Slack or Intercom asking about the roadmap and upcoming features. It also gives me a far better vision of the pains felt by our users. It's a gold mine for a product manager like me!

Limitations

However, we don't want to stop there. We would like to keep the users informed, those who gave us insights on a specific feature, about when that feature will be developed or released. But here comes the limitations... productboard is a very young product like us and there is for the moment no way to use an API or a webhook to build a workflow, for example, through Zapier or IFTTT. Unfortunately, support told me implementing an API wasn't one of their priorities and they weren't able to give me any ETA.

I made a list of the workflow I would like to implement in the future:

• Thank the users who gave us an insight on a specific feature.
• Inform the users about the progress made on a feature.
• Give beta-access to the users who voted for a feature.
• Send an explanation email to the user when I don't publish their suggestion.

The other thing that I was missing from GitHub was the ability to discuss with the people who engaged with us on a feature. That's also a missing feature on productboard: I would love to be able to speak with them about their use case. Currently, I need to get in touch with them using their email.

In any case, productboard dramatically changed the way we interact with our community. Transparency is one of our key values and this software simplified everything. Our product roadmap is easily accessible, everyone can submit a new idea and as a product manager it has become so easy to keep every feature on track.