Here are 8 of the biggest challenges of a Trello roadmap
As products and teams grow, many often struggle to manage feature requests, prioritize a backlog, and communicate their roadmap with Trello.
@BAMarieFuller Trello is a cluster… :)— Daniel Pasker (@dpasker) November 29, 2016
One reason why some agile folks don’t find value in roadmaps is because they’re often inspired by the wrong things. Roadmaps should be inspired by stakeholders.
All roadmaps are wrong. Some roadmaps are useful.— John ✈️ #VMworld 🌠 (@jxxf) December 19, 2016
Stakeholders can be a mix of internal people like developers, support reps, and the CEO. Stakeholders can also be external people like customers, integration partners, and leads. By understanding which stakeholders are interested in roadmap outcomes, you can learn from them, engage them, and ultimately collaborate to create better solutions.
A Trello roadmap lets people subscribe to a card (which is great!), but what about external people who aren’t using Trello?
You can’t programmatically add subscribers from support tickets or email to understand demand because, unlike most systems of record, Trello uses a username instead of an email address for subscribers. This also makes it impossible to look at subscribers in Trello and use data about your business to separate viable feedback from the noise. To our next point…
One of the biggest success factors of a product is whether or not you engage with the right users about the right things at the right time.
The ability to subscribe to a Trello roadmap is awesome for people wanting to stay in the loop. However…
you have to have a Trello account to subscribe
you can’t subscribe someone on their behalf (like a +1 when you hear feedback similar to something already on your roadmap or backlog)
Subscriber notifications from Trello are high-level updates directly from Trello like when a card is moved to a new column. There isn’t a way to engage subscribers for more in-depth communication like user interviews, surveys, etc. The easiest way (or only way?) to engage with Trello subscribers is via comments.
Comments are one way to have transparent conversations, but it’s difficult to have meaningful conversations with Trello users in public comments. Comments can also create negative perceptions or challenges for product teams. To see examples of those challenges just read the comments on Trello’s own public roadmap here. Their reason for discontinuing comments on their roadmap is similar to what we heard from Jonathan Roberts, one of our favorite UX designers from Redgate Software. His reason for dropping UserVoice had to with public comments not helping his team or customers achieve desired outcomes. Learn more about his decision to drop UserVoice here.
A public roadmap lets customers align themselves with your product as it evolves over time — which is especially important for SaaS products. However, customers don’t need the gritty details of how you plan to get from point a to b. Customers care about how they’ll be impacted by the future of your product. Technical details on a public roadmap become a distraction from the things customers do care about.
The solution for most product teams using Trello public roadmaps is to create an entirely separate board for their public roadmap and a different board (or boards) for their actual roadmaps.
It’s tedious to keep boards in sync because the data shared between the two is often thought-migration rather than data-migration. Instead of working in harmony, public Trello roadmaps become static documents and create a bottleneck for the most in-demand members of the product team to reconcile.
This point has more to do with form over function, but it’s worth mentioning. If your roadmap is the public space online where you communicate the future direction of your product … shouldn’t it feel like a space that belongs to you instead of a third party?
Most product teams get creative with their Trello roadmaps by adding a “How this board works” card and a logo as an attachment. It doesn’t change the fact that the domain is Trello.com and no matter how much you change the colors or background image, a Trello board will always be branded as Trello. Even the icon in the browser tab makes it hard to know in a busy workspace if they’re engaging with your roadmap or with Trello.
A Trello board looks like work to be done, rather than a vision or stories to be told. That is why the ‘how it works’ card is so commonly used to share disclaimers and give users instructions for how to engage with the roadmap. If your public roadmap needs a user manual, there is room to improve the user experience.
To make a product roadmap driven by stakeholders, the easiest thing to do is sync the product roadmap, the backlog, and product feedback simultaneously. These workflows require varying degrees of transparency and types of engagements for teams and customers.
This is another reason it’s difficult to manage a single Trello board and you often end up using multiple boards. For example, you might want to enable comments and votes on a board for collecting feedback, but only enable voting on your public roadmap. It also becomes difficult to manage larger data sets in Trello when you need to sort, filter, and prioritize ideas during sprint planning.
Trello has powerful search and filtering tools, but when it comes to a Trello roadmap it’s difficult to understand things like:
what are teams working on over time?
are we meeting our objectives?
what is the revenue associated with this feature request?
If you have a public Trello roadmap, you’re limited to understanding the same data seen and accessible by your public audience.
Mockups & GIFS are a special way to help your audience visualize the future. People can look at an image and quickly understand complex changes.
However, because Trello displays images within cards, images don’t add as much understanding. When you open a card, you need to click on an image and interact with attachments to see a full-size version.
If you want to share a public roadmap via social media, a Trello roadmap doesn’t give you a friendly format. For example, with the link to Buffer’s public roadmap you’ll see that Facebook displays metadata from Trello instead of Buffer. You’ll also need the Trello mobile app to engage with a Trello product roadmap on mobile devices.
We’re huge fans of Trello. We’ve used Trello to manage product roadmaps, collect feature requests, plan sprints, fill backlogs, and for pretty much every product management workflow. In fact, I wrote this post about using Trello for product management on their blog last year. Trello is a great tool for getting things done. We love using Trello to knock out the tasks happening in our roadmap behind the scenes.