An internal roadmap guides the direction of your product, but how do you get feedback on ideas without letting your competitors know your plans? That’s where the public product roadmap plays a key role – as an open intention of where you plan to drive your product, and a place for customers and users to provide input along the way.
Last summer, the TinyMCE Public Roadmap was launched as our open-door to feedback and comment. In a recent conversation with Fredrik Danielsson, Product Manager for TinyMCE, and Roman Khudonogov, Head of Product at Tiugo (Tiny’s parent company), we discussed why and how it was built, what we’ve learned, and the impact it’s had since being going public.
Why build a public SaaS roadmap?
There are four main reasons why you build a SaaS product roadmap:
1. Transparency
A public product roadmap allows your customers and users to see the future features and improvements you’re planning to add to your software. This helps to build trust and transparency with your users, so they can see the direction your product is heading.
2. Feedback
By publishing a public version of your SaaS roadmap, you can receive feedback on the features or improvements that are of most interest to them. This helps you prioritize your development efforts and ensures that you’re only building features which are valuable to your users.
3. Engagement
A public product roadmap helps to engage your users and creates a sense of community around your product. Users are more likely to stick around and provide feedback if they feel they have a stake in the development of your product.
4. Marketing
A public roadmap also serves as a marketing tool. It can help you attract new users who are interested in the future features and improvements you’re planning to add.
Why did we choose to create the TinyMCE Public Roadmap?
Roman says it best:
“One of the bigger, but rarely asked questions for a market-leading product like TinyMCE, is ‘What now?’ We created the Public Roadmap to help decide where to direct our efforts. The public roadmap is a place for conversation, both internally and externally with prospects, customers, and users. It’s a place where we can collect and structure feedback, but also publish new ideas and have a conversation with our community about them.”
~ Roman Khudonogov, Head of Product and Design.
How a SaaS public roadmap fits into the product development lifecycle
While the small details of product development life cycles vary widely across industries, according to ProductPlan, most software products follow a life cycle that looks something like this:
- Develop the idea: Look for ways to solve problems for the end user and generate multiple product ideas.
- Validate the idea: Shortlist and choose the product idea based on market validation and internal evaluation.
- Build a prototype: Mock it up to see how it looks and how it would work for the end user.
- Create the messaging: In parallel with building the prototype, start to create and validate the product’s go-to-market strategy, which includes messaging and positioning.
- Build the product: Create a minimum viable product (MVP) that can be quickly put into the hands of customers to provide feedback to improve future versions.
- Release the product: Make it available and put it in the hands of users and buyers with sales, marketing, and product-led growth strategies.
- Improve the product: Based on feedback from the market, continuously iterate and improve on the product as needed, or until improvements reach the point of diminishing returns (ProductPlan).
Using the above list as our general guideline, let’s see how a public product roadmap actually fits into the development lifecycle. We’ll use one of TinyMCE’s recently released plugins, Merge Tags, as an example:
Development cycle stage |
Merge Tags [example] |
Public Roadmap contribution |
|
|
1. Develop the idea |
“A lot of people use TinyMCE for sending emails. What kind of customizations are they creating out in the wild, and how can we make their lives easier?” |
– |
|
|
2. Validate the idea |
“We have a hypothesis that a pre-built Merge Tags feature would be valuable… but would people actually use it?” |
Post a card to the “Ideas” tab of TinyMCE’s Public Roadmap with a description and invite votes/suggestions. |
|
|
3. Build a prototype |
“People are interested. Let’s see what this might look like, and if it’s reasonably doable within TinyMCE’s UI.” |
As we come up with designs, post them to the Public Roadmap for feedback. |
|
|
4. Create the messaging |
“Marketing has an idea of what messaging will resonate, but can we test it on our audience, early on?” |
Post updated messaging to the Public Roadmap and monitor comments for signs of confusion or misinterpretation. |
|
|
5. Build the product |
“Full steam ahead, let’s build this plugin!” |
Update the card and move it to the “In Progress” tab. Notify everyone who provided votes and feedback. |
|
|
6. Release the product |
“Let’s make sure everybody knows what Merge Tags does, and how they can use it.” |
Update the card and move it to the “Launched” tab. Notify everyone who provided votes and feedback. |
|
|
7. Improve the product |
“What else can we do with Merge Tags? What does the community want to see?” |
Monitor the launched card for feedback and prioritize it as it comes in. |
|
Key elements of a successful public SaaS product roadmap
Here are our top tips to make sure your public product roadmap is a success by keeping your customers in the loop and providing the actionable insights you need for development:
1. Don’t describe, inspire
A good public roadmap offers detailed descriptions of what you’re planning or considering. A great public roadmap inspires people to imagine brand new ways of working.
Don’t just describe the idea and how it works. Add examples of where people can use the new feature, so they can imagine it in their day-to-day workflow.
Fredrik says to “inspire people by showing them capabilities and solutions that you’ve identified as potential use cases. You’re excited about this stuff, so let it come through.”
2. Make it visual
If you have designs or mockups, show them! You’re far more likely to get a reaction from people if you show them something, rather than simply talking about it. Even if you know the final product may change from your current design, show it anyway.
3. Encourage dialogue
Provide a way for people to give you their thoughts and opinions. If it excites them, they’ll let you know what they need, or if they don’t find it exciting, you won’t get a lot of votes. Either way, it's better you find out now, rather than after you’ve built a new feature.
Once again, Fredrik shares his experience:
“We use ProductBoard’s Product Portal for our public roadmap. It gives users the ability to vote on what features they want, and even provide input on how they see it working. All of this information gets recorded in ProductBoard’s larger product management tool, along with all our other insights, giving us a true 360-degree view.”
4. Promote it
People often get this one wrong. They treat the launch of their public roadmap the same as they do a product launch, but it isn’t the same.
Your community doesn’t care that you launched a public roadmap. What they care about is how easily and quickly they can see what you’re working on, and being able to provide their own suggestions and feedback.
So instead of promoting it with a one-off blog post or newsletter, look at ways to include your roadmap on an ongoing basis, and how (and where) it fits into the whole customer experience of your product.
This is how we encourage people to visit TinyMCE’s Public Roadmap and leave their feedback:
a. In the docs
People go to your docs to see if and how they can do something. If they discover they can’t do what they came to do, the next best thing is knowing if it’s coming and if not, how they can request it.
We added a permanent sidebar link to our docs for quick and easy access to the public roadmap:
b. On the website
We also added a link into our website footer – for quick and easy access – without intruding on the main navigation:
c. In release emails
Whenever we announce new features, we include a link to the public roadmap at the bottom:
d. External communications
Finally, customer-facing team members are encouraged to share the public roadmap with whomever is interested, or people that may benefit from knowing what's coming.
5. Keep it up to date
This seems like a no-brainer, but it’s important to make sure your public product roadmap is regularly updated with each feature release. Your community needs to know they can trust it as the single source of truth for what’s being launched now and what’s on the horizon.
At Tiny, we update the TinyMCE Public Roadmap with every minor and major release.
6. Use it to align internal teams
As your company scales, it becomes increasingly hard to get multiple teams on the same page. Your SaaS roadmap is a great opportunity to help internal stakeholders see the “big picture” of what you’re working on, celebrate the successes (large and small), and align messaging.
“In all-hands meetings, we often show our public roadmap as a simplified version of our internal roadmap. Not all teams care to see the fully-detailed roadmap, and the public version is much easier to consume for a broader audience,” says Roman.
7. Combine insights with other data points
At Tiny, we lean heavily on the insights we gather from our public roadmap, but it’s not the only tool we use to guide our strategy. A solid strategy takes into consideration data points from a number of sources. We also rely on:
- Customer conversations
- Support desk tickets
- Community discussions
- Product usage metrics
- Market research
What to avoid with your public product roadmap
As with every project, there are a few things to avoid. Here’s our best ‘don’t do this’ list to help you with the development of your own public roadmap:
1. Avoid the to-do list
Fredrik says, “Don’t list everything you want to validate on your public roadmap. Generally, customers only care about the big items that are really going to help them move the needle with their jobs-to-be-done.”
Adding smaller, less impactful items takes the attention away from the more important and innovative ideas that you want to explore.
2. Avoid specific dates, unless you can 100% deliver
Things always happen in software development: roadmaps change, and customers know that. But when a specific date is put on a roadmap, customers take it as gospel and expect something to happen on that date.
As our new ideas progress, we learn more about the work involved in that development, and dates and scope often change. So, to avoid upsetting customers, we tend to use either seasons or quarters, for when features may be delivered.
“Customers don't mind knowing upfront what you'll be working on next fall, but you are also committing to a plan that might not pan out. At best, people don't care if you have to change plans, but some will care, and most likely will be disappointed,” shares Roman.
3. Avoid giving it all away
It's sometimes hard (but the best advice) to walk the fine line between generating excitement and feedback, without giving away your entire product strategy to a competitor.
Unfortunately there’s no hard and fast rule about this, you just have to use your best judgment.
TinyMCE’s SaaS product roadmap – the results
Since going live in mid 2022, our public product roadmap has generated over 300 valuable insights from users and customers, and helped us to prioritize, define, and bring 8 new features to market.
Best of all though, is that TinyMCE’s future direction is transparent, and customers have a much louder voice in what comes next.
One final piece of advice that came from Roman, when he was asked what he’d do differently: “I wish we’d done it sooner.”
Remember, you don’t need a fancy web portal to launch your public roadmap – a page on your website is a great starting point. Your customers will thank you.
