PLAION and Feature Upvote

PLAION is a global video game production company. They use Feature Upvote to track suggestions and bug reports for two of their Live Ops games: Beyond Contact and Warlander.

We spoke with Dave, Head of Online Communities on PLAION’s Live Ops team. His team focuses on free-to-play multiplayer games in live operating environments.

What led PLAION to try Feature Upvote?

One aspect of PLAION’s approach to product that immediately stood out during our conversation is the team’s dedication to serving their communities.

We are very focused on community-driven game development. For us, it’s not just a buzzword. We do take this idea of working with the community to make the game potentially even better than it already is to heart.

Dave and his team also play their games daily to be on the same level as the players and understand exactly what they’re talking about when making suggestions.

I don’t think you can serve your users to the best of your ability without knowing your game and without playing your game. The two go together. In fact, we try to get everyone inside the company to play our games—even at the C-level—so that they are able to do their job and represent our games to the best of their ability. Because when you know the game, I think everything else kind of falls into place.

This focus on community is what led them to adopt Feature Upvote.

We needed a tool that would help us take all of the potential noise and ideas that are talked about casually and consolidate them into one place.

With Feature Upvote, we can turn comments into actionable items. It becomes something that we can act on and work into our games.

Before Feature Upvote, their feedback management process was much more manually driven.

We used crazy Excel sheets, Word documents, and we created topics directly in JIRA, when possible. It was a very archaic process. We weren’t able to keep it all organized and not worry about missing something before Feature Upvote.

What channels do you receive feedback through? How do you centralise it all in Feature Upvote?

Discord and Steam are where most of the suggestions come through. There, Dave and his team discuss the suggestions with the players and then point them to the appropriate Feature Upvote page.

Because we know what features have been suggested and which are being worked on, we can then say: “Oh, yeah, there’s actually already a conversation about this happening.” And we give them the direct link to the actual suggestion in Feature Upvote.

Or if the suggestion is generic or a wall of text, we say: “Yeah, this is super valuable feedback. But to help us process this and bring it to a place where we can actually take it to our development team in bite-sized chunks, could you please make suggestions for these topics here?” And then we give them the main link to the feedback board.

We’ve gotten to the point where we have ambassadors in our community who are sharing the link and saying: “Oh, they’re already talking about that”, because they also are paying close attention to the topics that are being discussed. It’s been really great.

How do you choose what makes it onto the roadmap?

We have regular meetings to go through all the topics on the board. From there, we decide what we could start putting into the game. And from that, we create our community-facing roadmap.

We then communicate to the users that their suggestions have made it into the roadmap and are part of our development process.

For Dave and his team, upvotes are relevant, but they’re not the most important part of the feedback prioritisation process.

The upvotes give us an idea of what some of the popular topics are. But at the same time, we go through every single topic, regardless of how many votes it has. And this is something that we tell our communities.

Because we have hundreds of suggestions, our users are concerned their posts will be missed—that their suggestions won’t be seen because there are a lot that have been upvoted already.

The product team sits down with the developers to discuss the feasibility and impact of each user request. They also factor in the cost of building the feature, as well as the team’s bandwidth.

We’re looking for quality-of-life ideas or ideas for improvements that aren’t completely game-changing.

We’re also looking for quick wins. If there’s something that we could implement very easily and at a low cost that would have a great impact, we get it done—especially because it’s coming from the community.

Dave and his team play the game daily, so they also come up with ideas of their own they add to the board. However, they are aware that as the publisher of their games, their feedback holds a different value than what their end users have to say.

We’re giving feedback as well. But even though we are players, feedback from players really holds a different weight than it does coming from us.

Even though we have our users’ respect as players of their game, our feedback is still feedback from a small segment of people at the publisher who are playing the game.

How do you organise and manage your feedback board?

We made things a little harder for ourselves by asking the users to write in the title of their suggestion whether it is a feature or a bug, in brackets. This helps us visually, go through and assess them easier.

Not everyone follows this rule, so I have someone go through and edit the titles before I go in and approve them. It is obviously a lot of work. But at the same time, it forces us to be aware of every single topic that’s in there.

Dave also spends a good chunk of time merging feature requests.

Merging is not possible unless you know the topics. If you don’t know the topics, then you would have to search for every single topic to find out if it already exists. But if we know the topic already exists, then we can easily find it and merge it.

The product team also created custom statuses to give users more visibility into their process.

We really want to communicate the status of the topic to the player. So we added extra elements to let them know specifically where it’s at—eg. it’s under consideration, it’s planned, it’s now in development, it’s been pushed to QA for testing, QA has found something that’s broken, etc. The whole journey is captured there.

What we did for Beyond Contact is we actually shared the status updates on Discord. Once a week, or when we would have a significant amount of changes to the statuses in Feature Upvote, we would share this as a post in Discord and show the status changes there.

They use tags to organize suggestions, but also to indicate to communicate with users when a suggestion gets rejected.

When we say something is not planned, I will always write a note saying why. Then we will tag it with “note from developer” so that they understand that they should look at the comments to understand more information about why something’s not planned.

That’s a tough part about having a very open suggestion and features philosophy with players. Some players will assume that everything that they say is going to be put into the game. But that’s unfortunately not true and we want the players to have insight into why.

What type of feedback takes the most work to manage?

The first is when there are multiple ideas in one suggestion. That is a tough one. It makes it difficult to give the suggestion a specific status. If we mark it as “planned”, then what part of it is planned? Are both ideas planned?

The second is when the title seems to have nothing to do with the body of text. The title is one thing, and then the body of text has a completely different idea within it. That happens more often than I would expect.

PLAION has players in all four corners of the world. Sometimes, a language barrier can be felt.

We do have, of course, players from all over the world. Navigating the suggestions that have been put through a translator is sometimes difficult to do. But we do our best. And again, that’s where the game knowledge comes in.

Are there any benefits of using Feature Upvote you hadn’t expected?

The Jira integration was a total game-changer for us.

I normally have a meeting with the developers where we separate the features and the suggestions from the bug reports. After doing bug reporting manually a few times, we started looking into how we could better streamline the process. And we found the Jira integration. It’s fantastic!

What have you learned about your product and or users thanks to your feedback board?

The most that I’ve learned through this process is the passion and creativity of our communities–the number of fantastic ideas that they have. The way that they’re able to help make the game better in a very quick way is really awesome.

Any parting piece of advice for other product managers using Feature Upvote?

There is an aspect of love and care that needs to be put into managing the board and the feedback. Knowing the game and knowing what players are talking about when they’re making suggestions is crucial.