How we handle our roadmap for Mergify

Whatever you’re building — a company, a product, or a house — a time comes where you need planning. Pushing random buttons to move forward does not work anymore. You need to take a step back to think about what the optimal move to do next.

This arrangement of your future intentions can take different forms, but it often boils down to a simple thing: a roadmap.

At Mergify, we’re building a product to optimize your GitHub workflow. As our creation grew, we started to be overrun by feature requests, bugs, support questions, etc. Like everyone out there, we went ahead and decided to build a roadmap — and we’d like to share here how we did it.

Constraints

We’re a young and tiny startup — our team is composed of only two people. That puts sharp limits on our structure, and it boils down to one primary constraint for us: time.

Time is always a precious resource, whether you work in a young company or a well-established brand. The discrepancy is that in a large organization, your survival might not be challenged by one planning error. In our case, we can’t afford to work on the wrong item because it might kill the company. We have to focus on the most promising candidate, or the cost of spending a large portion of our lifespan on the wrong aspirant might drown us (definitely).

Consequently, our primary goal has been to avoid seeing our time sucked into meaningless projects. Here’s the strategy we adopted.

Triaging The Flow

As soon as our product started being used, we received dozens of feature ideas, bug reports, questions, and whatnot. We collected way more tasks than our allocated time could allow us to handle. Like an uninterruptible flow, new requests keep coming every day with every user.

The first reflex is to react to those and act upon them. Rather than blindly doing so, we collected each of these and wrote them down in a table.

We use Notion to generate the table, but any other tool (e.g., Google Sheets or Trello) would work as well. We increment the number of times that we encounter the issue or request in the Number of Users column. This gives a rough estimation of how a particular point might be painful might. Right now, the #1 issue reported by users is our documentation, far above everything, as you can see by the number of points. That is the next item on our roadmap.

The WOW Effect

In each entry in the table above, we write down the references of any user that reported the issue. This might be a link to an email thread, a GitHub issue, a survey response, etc. This is important as it gives the entry more value.

First, it allows retrieving the context that created the initial requirement. A one-line long sentence is not enough to understand a pain point or how to reproduce a particular issue. Being able to dive back into the source of the problem is a crucial factor in saving time and implementing the right solution.

Second, it allows giving feedback to the users. I’ve been a massive fan of Capitaine Train support team. If you don’t know Capitaine Train, it was a French startup (acquired by Trainline a couple of years ago) that sold train tickets online. Jonathan, the Head of Customer Experience, wrote a lengthy blog post and book (both in French, sorry) where he describes their strategy around customer support.

One of the things they did is never to promise any date to customer feature requests. They wrote them down, noting who requested what and prioritizing based on various criteria. Once the feature was implemented, they emailed every customer that requested the feature to announce that their feature request has been completed. Sometimes, years could pass before the functionality was implemented. Imagine the surprise the customer got when they received a personalized message, replying to their initial requests, sometimes years after they requested it.

Surprising customers that way creates what Jonathan calls a WOW effect — which directly comes from one of Zappos core values. People are astonished that you are following up — without making having made any promise — on something they asked you only once.

We apply this mantra to our support service, and that includes our roadmap management. Each time a new feature is implemented and released, we reach out to each of our users that asked for it, letting them know that it’s now available for them to use.

And we only get compliments in returns.

Picking up candidates

Most of the candidates on the roadmap come from user feedback. The need of our users drives them.

However, we still have many items to work on that are not part of the roadmap. For example, there might be backend work to do, technical debt to tackle, external service to set up, etc. Many of those items are invisible to our users but are needed to maintain and evolve the platform.

As we’re only two engineers working on this, we decided on a simple rule:

We work on no more than two items at the same time, at least one being user-visible.

User-visible means any feature that will impact our users directly. By always working on at least one item from that category, we’re sure to roll out new features continuously, keeping our user happy, maintaining that WOW effect — while making sure we do what’s needed to keep the service afloat in the background.

Publishing our roadmap

Today, we’ve decided to publish our roadmap publicly for the first time. We also use Notion to generate and maintain it — it’s quite a handy tool to do so.

We keep it simple with three columns: Not Started, In Progress, and Complete. We move cards as items evolve, which only takes a minute.

Each item comes from the general user gathered roadmap. We don’t publish internal and private issues — they would not be that exciting for users anyway.

Publishing a roadmap is quite essential as it is a form of public commitment. By making this available to anyone, it’ll get harder our team to back down on what we publicly promised we would do and keep us on track and committed. That might seems like a detail, but keeping morale afloat and engagement high when you’re a small team can be quite challenging. Consider this as a Jedi mind trick.

There is plenty of moments where you can get lost by the multitude of details and menial tasks reaching you. Having a small but powerfull process to keep you on track is essential. It has been a critical factor in our successful management of the product so far.

The last thing you want is to end up like Alice.