Building a product while taking into account time, money, resources, user needs, and probably about a thousand other things is no easy feat. It requires a lot of planning, that’s for sure.
In this article, we’ll take a look at product roadmaps, public product roadmaps in particular, why they’re great for planning and addressing user needs, and the tools used to create them.
Table of contents
- What is a product roadmap?
- Why maintain a product roadmap?
- Why share a product roadmap publicly?
- What shouldn’t be in a product roadmap
- Tools for creating product roadmaps
What is a product roadmap?
A product roadmap is a timeline that shows when features and significant improvements to a product can expect to ship.
In many product roadmaps, the dates aren’t necessarily specific, but they at least show the order in which features/improvements are likely to ship. But of course, great product teams know when they need to adapt or pivot, so product roadmaps are rarely set in stone and are always subject to change. Harish Natarahjan provides a much more comprehensive overview of product roadmaps.
Why maintain a product roadmap?
The goal of having a product roadmap is to provide product teams with loose objectives that, in turn, provide them with a bird’s-eye view of what they should focus on. This helps teams stay on track when working towards larger goals, plan for resources in advance, and build (or at least maintain) momentum.
Staying on track is largely a psychological endeavor. Firstly, having a visible objective creates a potential reward for our brain — a benefit that requires no elaboration. The accountability to ourselves, but more so to our teammates and even users, is also a powerful motivator, as there’s always somebody quite literally waiting for us to take action (it’s anxiety-inducing, but not necessarily in a bad way).
Putting brain bamboozlement aside, product roadmaps are also useful for planning. Specifically, knowing what needs to be done can help product managers allot time, budgets, and people, gather tools, and hire more people as needed.
And finally, one thing that product teams often forget about is the risk of taking too long to ship product updates. When this happens, users get bored and frustrated and teams burn out and lose motivation as time goes on. Stakeholders (including users) need regular dopamine boosts to remain invested.
Why share a product roadmap publicly?
The biggest reason for sharing product roadmaps publicly is transparency and support. Your product roadmap acts as proof that things are progressing and that you as a team and product are worth the continued investment. In return (depending on how well you manage expectations), support will range from casual lurking to vocal cheering, and maybe even some feedback.
The second reason is validation. Validating product ideas is one thing, but how you prioritize them is something else entirely. A great mantra to get the most out of your public product roadmaps is “let your users build the product” (or something to that effect). If your priorities are all wrong (it happens!), your users will let you know.
There’s also product retention to think about. For subscription products, including SaaS products, providing an approximate ETA on specific features or improvements can be the difference between customers churning or deciding to stick around. People fear the unknown, so they’re more likely to unsubscribe to products than risk paying for something they might not get or get soon.
And of course, sharing product roadmaps publicly increases your accountability too.
Products that were too private and why that hurt them
Products don’t necessarily need roadmaps to garner support, but they definitely help — not having a roadmap often hurts.
An example that always comes to mind is when InVision was building InVision Studio. Designers were super hyped for Studio, thanks to InVision’s marketing efforts, despite not knowing exactly what they would get. After all, people trusted the brand, their marketing was wickedly enamoring, and they were very open about how much funding they raised. It all seemed very promising.
However, these things can only be impressive for so long and what we didn’t see was them being open about their product roadmap. I can’t profess to know what happened exactly (I’m sure it came down to a lot of things), but one thing’s for sure and it’s that delays and lack of transparency played a role in people gradually giving up on it, especially post-launch. It was buggy and didn’t really have a competitive edge over similar products.
Being more open, in particular by using a public product roadmap, could have changed that.
The lesson here is that hyperbole will only get you so far, and we’ve seen this in many other industries that often work in secret too. The gaming industry is particularly disappointing. Games have explosive trailers and a ton of hype around them, but no actual gameplay reveals upon release.
As a result, a horrendous number of games are broken on day one, to the point that some (such as Cyberpunk 2077) have to issue refunds, and others (such as Halo Infinite) end up canceling promised features because their internal roadmap is just so out of whack. Skull & Bones has been pivoting and delaying since 2013 and we’re still not sure what kind of game it’ll even be — as a result, people are no longer interested in it.
In short, a product roadmap isn’t just a useful tool for product teams. To some extent, a roadmap also defines the relationship between a product and its audience.
What shouldn’t be in a product roadmap?
There are many things that can improve your product, but not all of them should be in your product roadmap. For example, if your business partakes in the open movement, how you run your business and solve interesting problems, details about your tools and processes, monthly recurring revenue (MRR) updates, and other business metrics and insights — things that indie makers and bootstrappers are very passionate about — would be better off shared in blog posts, on social media, or on other interest-based social platforms.
All of these are extremely useful and interesting, but they mean nothing to your audience as users of your product. Product roadmaps can be integral to your “building in public” persona, but not everything that you do and build needs to be in your product roadmap.
You generally won’t want to mention bugs in your product roadmap either. Not only does this put every flaw that your product has in the spotlight, but most of them will be so insignificant that they’re just not worth knowing about. Many of them will go undiscovered by the majority of users anyway. You can make an exception for particularly controversial bugs (i.e. anything of public interest).
All of this considered, it’s important to not think of your product roadmap as an open book or as your to-do list. Product roadmaps should include only things that directly improve the user’s experience.
Tools for creating product roadmaps
Trello is a Kanban-style project management tool that can be used for a wide variety of things. Considering that it has a pretty generous free plan (to the point that you might not even be aware that one can even pay for Trello), combined with how great and popular it is, you might be using it already.
That being said, Trello isn’t specifically designed for product roadmaps, so using it won’t feel as streamlined compared to other tools. Prioritization is something that you’ll need to do outside of Trello, and unless you’re willing to let users have edit access to your Trello boards, you’ll need to set up a Google Forms + Trello Zapier workflow — or something similar — in order to collect feedback (users won’t be able to subscribe to updates, though).
This option is most suitable for individuals and maturing teams:
Airfocus
Airfocus is a dedicated product roadmap tool that covers the entire process, from collecting feedback, to following up (if needed), to assessing priorities based on a variety of factors to creating/updating your product roadmap.
You’ll also be able to make your roadmap public, collect feedback, and let users subscribe to updates. However, there’s no free plan and even the basic one omits some key features, so prepare to open your wallet.
TeamGantt
TeamGantt has features dedicated to maintaining public product roadmaps plus a variety of other project management features, so you might want to consider this option if those additional features would be useful to you or your team. Practically speaking, having fewer tool subscriptions is more budget-friendly and tends to result in smoother workflows.
Monday.com
Monday.com is like TeamGantt — it’s designed for project management in general but it comes with way more features and costs way more. Again, see if what they offer is right for you/your team, because the high costs are worth it if you use Monday.com to its full potential.
Productboard
Productboard is very comparable to Airfocus. It rates slightly higher than Airfocus and, as a result, is a little more expensive. However, it’s more cost effective if you have more than five viewers/contributors.
ClickUp
ClickUp has an incredible amount of features, rates extremely well, has a free plan, and has an astonishingly affordable paid plan for additional product roadmap features, such as feedback collection and timeline-view. It’s also very pleasant to use.
Think Trello but more efficient and with more native features. Its friendly pricing structure scales with operational needs.
Aha!
Aha! also rates really well, but the roadmaps plan is wildly expensive. It might be difficult to justify the cost of it, considering that this list already contains some excellent product roadmap tools. However, it looks and feels like a dream for teams that prioritize organization and have a multitude of data points.
Ultimately, it’s probably Trello and ClickUp that are going to stand out for you, so if you just don’t have the time to research all of them, I would look into those two.
All of these product roadmap tools have at least a 4.5/5 rating on Capterra. Sara Nguyen’s 10 product roadmap tools and their best features include a few more tools and goes into more detail.
Alternatively, if you’re open to having a little fun and getting creative, you can always design and code your own solution like Lemon Squeezy did:
Generally, I would suggest that you stay away from integrations — specifically ones like Jira and GitHub that feed bugs/issues into your roadmap. As mentioned earlier, you won’t want to saturate your product roadmap with potentially hundreds of bug reports. Most product roadmap tools offer these integrations, but they’re not ideal for public roadmaps.
Conclusion
If you take anything away from this article, it’s that product roadmaps define the relationship between your product and its audience. Roadmaps should be fueled by user feedback, and in return, your roadmap should be how you respond to that feedback, telling them what improvements you’re going to make, when you’re going to make them, and perhaps even notifications of when you’ve made them.
Creating a product roadmap is pretty fun. Even if the clarity that it brings isn’t your cup of tea (I find that it helps with my inability to focus), finding the right tools and putting together the right workflow is a low-key rewarding challenge.
If you’ve got something especially interesting about product roadmaps that you think the audience and I would like to know about, feel free to drop a comment in the box below.
Featured image source: IconScout
The post A guide to creating and sharing public product roadmaps appeared first on LogRocket Blog.
from LogRocket Blog https://ift.tt/dKMUzRn
Gain $200 in a week
via Read more
