If you’ve ever sent a feature request to Trello, you may have gotten a note back saying that we’d pass it along to the team for consideration. Depending on your level of cynicism, you may or may not have believed that part, but we are sincere!
The support and product teams here at Trello really do work together to consider the feedback that we get from our users, and to figure out how we can use that input to make Trello even more awesome.
So let’s take a look at the epic journey your feature request takes after you hit the “Send” button.
Incoming Feature Request!
When you send us an email with your suggestion or post something on Twitter, the support team is the first to set eyes on it. Real, human eyes—no robots, here! We’ll let you know that we’ve heard you loud and clear, and then we’ll track that request on a special Trello board called “Support: Product Narrative.”
The first list on that board is the Inbox. This is where we add any brand new request that we’re not already monitoring. The support team gets together twice a month over a video chat to go through this list and quickly discuss each item and where it should go on the board. At the end of the meeting, we sort these new requests into one of our tracking lists.
The three main lists we use for tracking are UX Pain Points, Related to Existing Features, and Requests for New Features. Each list contains several cards, with each card representing a piece of feedback, like “Request for more puppy-related Power-Ups.” Whenever we get an email or tweet related to that feature request, we add it to the card.
A long list of links can be difficult to make sense of, so to help us keep our users’ voices front and center, we use the Help Scout and Twitter Power-Ups to show a preview of each request on the back of the card.
Stop Trying To Make Fetch Happen
There’s also an Unlikely list. This is where we put cards related to features that we’re not likely to add any time soon. It doesn’t mean, however, that these features are impossible, and we do still track interest in them so that we can understand those pain points.
So, what makes a feature request unlikely to make the cut? An unlikely feature is one that doesn’t fit with the core vision of Trello, or one that would only appeal to a very small number of users with little longevity or future appeal.
One example of an unlikely request that we hear about a lot is for admins to be able to limit what individual board members can see on a board, so that managed users can only see the cards of which they’re a member. This isn’t a bad idea, and it definitely makes sense for some workflows.
Trello’s aim, however, is to provide groups with a shared perspective. If two people look at the same board, and one isn’t able to see the same thing the other user is seeing, that shared perspective is lost. Because that feature isn’t in line with Trello’s vision, it’s less likely to be prioritized over other features.
Stop, Collaborate, And Listen
It’s all well and good to track the feedback we get from users, but the process can’t stop there. The support team doesn’t decide what features will make it into Trello—for that, we need to get the product team involved.
Once a month, a member of the support team checks in with Trello’s Product Managers to review a selection of cards from the Support: Product Narrative board. Since many of us are remote, we use video chat to gather around the Trello board.
To stay organized, we use labels to group together cards that are related to a similar part of the product, such as “Mobile” or “Notifications.” We use a “Top & Trending” label to identify cards we want to discuss in the meeting, and stickers help us see at a glance which cards have the most requests associated with them.
Believe it or not, we get multiple new Trello feature requests each day. Rather than go through each individual request, we use this meeting to discuss the biggest pain points, trends, and opportunities for quick wins. Instead of making a final decision about each feature request, we focus on communication (the key to every good relationship—am I right?). Support shares the top things we’re hearing about, and Product lets us know which of those are already in the works, are currently blocked, or could be considered in the future.
Sometimes, however, a decision is made right away. One real live example of this is the “Change email” link on the account settings page. For a long time, this didn’t exist. You could still change your email address by adding an additional email address and then removing the first one, but this solution wasn’t intuitive. Even though the support team got questions about this on a regular basis, it was just seen as something that needed to be explained, rather than something that should be fixed.
That is, until we looked at the numbers.
Once we started actually tracking the number of support tickets we were getting related to changing an email address, it was pretty clear that this was a big—but solveable—problem. We talked it over in the monthly meeting, and within just a few weeks, we had a solution. The “Change Email” link was added to the account settings page, and the support team began seeing fewer questions about how to change an email address.
On the other side of the coin, sometimes there are ideas that we all like, but they can’t be implemented right away. A good example of this is the request for more label colors. We could extol the virtues of adding new colors until we’re blue in the face, and we’d be tickled pink to add some more. But when you drill down into the details, it’s not a black and white issue.
Each of the current options for label colors has a variant that allows it to be easily distinguished by users with color-blindness. If we were to give new colors the green light, we’d need to come up with variants for those as well. Additionally, our labels are currently linked to keyboard shortcuts, which further complicates the matter.
This doesn’t mean that we’ll never add new label colors, just that it will take more planning than you might expect. After all, we couldn’t just add them out of the blue.
Trello’s aim is to provide groups with a shared perspective. If two people look at the same board, and one isn’t able to see the same thing the other user is seeing, that shared perspective is lost. Because that feature isn’t in line with Trello’s vision, it’s less likely to be prioritized over other features.
Where We’re Going, We Don’t Need Roads (But We Do Need A Roadmap)
When the product team does decide to take action on a specific feature request, they’ll move that card into a new list on the board to show that they’re working on it:
- If it’s a feature we definitely want to add, it will move to the On Product Roadmap list.
- For requests we’re interested in but are still exploring, the card will be moved to Product User Research.
- Finally, once we’ve shipped a particular feature, the related card will go into the Potential Solution Shipped list.
Sometimes the solution may be slightly different from the specific request a user made. Rather than implementing the exact feature that was requested, we try to understand the pain point our users are running into and release a feature that will solve that problem for the most users possible.
Once a card makes it to the Potential Solution Shipped list, the support team knows to keep an eye out to make sure we’re no longer getting emails related to that pain point. If we are, there’s still work to be done!
And Now, The Moment You’ve Been Waiting For…
A new feature isn’t very helpful if no one knows about it! When we ship a feature that users have been asking for, we like to send them a note to let them know they can start celebrating. To do that, we use a custom Power-Up that was written by a member of our support team with help from our developer advocate.
The custom Power-Up gets all of the conversation IDs from every Help Scout ticket added to that card. Then, it grabs all of the email addresses from those conversations and sends them a new message in Help Scout to let them know that the feature they asked for is live in Trello.
When you need something specific, custom Power-Ups can be a handy way of adding that functionality to Trello for your team. Interested in building one yourself? Check this out.
Like Trello itself, our process for handling feature requests is always changing and improving. In fact, the Support: Product Narrative board underwent a complete reorganization just last year. Fortunately, tools like Trello make it easy to adapt our workflow whenever we need to.
Although our process is continuing to evolve, there’s one thing that hasn’t changed: Our users, all of you, matter to us—and we want to hear from you!