The roadmap is about getting people excited. It's about seeing what your vision is, where you're going, evaluating if it fits your needs, and hopefully getting excited about the specifics. Metabase is an open source company, but I would still do this at a company making regular, closed-source software. Our competitors don’t care really care much, and this makes sales so much easier.

We wanted something that looked pretty slick because you’re talking about the future. I think you want to convey a certain level of polish in what you're doing there. 

There's some commitments about precision. What's coming up next is most likely going to happen. And then you lose confidence as you go further out. 

If we make it too high of an effort to put things there to maintain, it's going to get out of date or we're not going to put things there. So I tried to make it very basic.

If I can't put bounds around it in a way that a user would understand, it's not there.

We debated having upvoting and downvoting, which a lot of companies do, but we didn’t because we already have that on Github issues.

The public roadmap is a Kanban board on Notion. I wrote a script to use the Notion API to pull this stuff and put it into a shape that gets consumed by the by the website. I check it once a month to make sure that it's still aligned with what we're doing internally. My usual process is that I update the internal roadmap first and then if I'm making any changes there, I check how are they represented in the public one, make the changes. and hit update.

The level of granularity is: “How big does the bucket get until people are excited?” And it can be very small at times. For weird historical reasons, you couldn't download a PNG of charts on a database, and now you can. It took the engineer two to three days, but it had a very large amount of votes on our Github. That goes on the roadmap, because I know that is super exciting for people.

Bruno Bergher

I created this Notion kanban in order to maintain our public roadmap. This makes it easy for me to make adjustments that get populated directly on our website. 

Metabase (the core product) has historically had a 

, available on GitHub. It's been valuable for users and customers of different sizes. As we changed our processes and tools, it's gotten out of date, and we haven't replaced it.

But we still very much want to keep it: it reinforces our values of transparency towards our community, it gives prospective customers more confidence about whether to choose Metabase as their BI tool, it gives us additional surface area for input from our customers and community.

For us, a public roadmap should, in this order:

Articulate the high-level direction we're taking the product.

To help people understand the areas where we're investing.

To give precise timing on granular pet features for different people.

public roadmap should be more like the Promised Land 

– exciting, worth waiting for – and not a land of promises – all talk, bound to lead to frustrations.

Public Roadmap at Metabase

Metabase Public Roadmap

Intro

Goals

Non-goals

Sign up to see more