It's no secret that we're a small team. There's Bryan in Portland, and there's me in Sydney. But we still manage to ship a lot of things while getting great feedback from our users.
Part of what makes it possible is keeping our roadmap public. There are some scary bits to it, but the benefits vastly outweigh the risks.
Why public roadmaps can be scary
It can be stressful for a team to let everyone know what they're working on.
- Your competitors might steal your ideas.
- You might disappoint customers by not shipping on time.
- You have to maintain multiple backlogs.
- Some things might be criticized publicly.
Those concerns are all valid, especially the ones around managing customer expectations. There's nothing worse than giving someone a deadline, and then having to backpedal and tell them that the feature will be delayed or worse, canceled.
So we had to think first about why we might want to have a public roadmap. And a lot of it was about being able to move faster.
The benefits of a unique public roadmap
First, we're a remote team. When I get my first coffee on Monday at work, it's still Sunday for Bryan. Being remote makes it harder to sync, so we needed a simple way to share priorities and discuss progress. But that does not necessarily make a case for having our top priorities public — it's more an argument to have a place to track roadmap items.
Secondly, we're a tiny team. So we have to be very careful about how we spend our time. Writing a blog post for each release, and keeping track of the features people are interested in is costly (even more when English is your second language). The less time we could spend on comms, the more we could invest in the product.
Third, we can't compete on sales budgets. Other companies in our market have huge teams that spend a lot of time emailing people and doing calls to sell their value. Well, we might not be able to do that, but we can still tell people what we believe in, and show them that we have a plan.
Having a public roadmap addresses all of these points at once. We can collaborate in the open, easily show what was coming up, and send a link to our roadmap or specific items when people were asking us about the future.
Ok, this is cool but we had to figure out a simple way to do that in practice.
Learning from the best
Looking around, we found 2 great examples to follow: Front and Buffer. Both companies are using Trello to communicate what they're working on. They differ in the way they manage released items, but the approach is similar:
- One column for the ideas and feature requests
- One column for the things that are planned
- One column for the items in progress
- A way for people to see what's been released
I like that Buffer has an extra column to show what they're not going to do as well, and it's something to keep in mind as we grow.
The advantage of this format is that you don't commit to actual deadlines. Your customers can map themselves your average velocity to what's in the "in progress" and "planned" columns.
I don't know if Front and Buffer have internal roadmaps as well, but we don't. 90% of what we're thinking about is captured in the ideas & feature requests column. Only some items that are not yet well defined are kept in internal docs.
We also went with Trello. The only downside is that customers need an account to vote and leave comments. But everything else rocks: the simplicity of the UX makes it easy to manage releases, and it only takes a few minutes each week to maintain the backlog.
If you're curious, you can check our public roadmap at https://trello.com/b/jFtwfQIG/tability-roadmap.
Transparency for productivity
The idea of keeping things public goes beyond the practicality of having fewer things to manage. It also means less worrying about the competition, and more focus on helping our customers.
Enjoyed this post? Get more like that in your inbox.
Scaling small is a weekly newsletter talking about doing big things while staying lean.Subscribe to Scaling Small