Founder Chat: How do we prioritize feature development, and how has this process changed over time?

When a product is actively growing, what’s the first thing that breaks?

For us, it was the feature prioritization process. Previously, we had a good overview of what to build month by month. Now, with 600+ open issues and new ones coming in, it’s a big challenge to decide what to prioritize next.

We know that our community is interested in knowing how we manage this process and how we decide on the requests shared here in the forum.

Today is the day to get all the insights on how we prioritize feature development at Baserow and how this process has evolved over time.

@bram, we’re all ears. :relieved:


Feature prioritization is always difficult to do, especially if there are 612 open issues when writing this answer. In the early days of Baserow, it was much easier because there were fewer issues, less community activity, fewer users, and no customers. This made it easy for me to keep an overview of which big features were needed most, which bugs were important, but also prioritizing some small features on the spot.

Since then, our team has grown, taking over responsibilities for me. Many people in the company speak with users, the active users have increased significantly, and there are many customers who want different things. The old system, of me keeping a lot of that information in my head just didn’t work anymore. We had more unanswered questions during our monthly planning meeting, and realized we needed to change things.

We always had a good idea of which big features we wanted to develop. While the issue list kept increasing, we needed a way to prioritize the big features, smaller changes and bug fixes as well.

To get a better overview, we wrote a script that synchronizes all GitLab issues with a table in Baserow. This gives us more flexibility in adding tasks that are not an issue, mixing in feature requests, and storing additional information like which customer has requested a feature.

We also came up with a scoring system where we score every issue, from one to six (higher is better), on adoption, revenue, strategic, dev effort, operational and risk. Next, we figured out how much each score must weight. Because we’re in an early stage and have limited development resources, we think that adoption and dev offer are more important than the rest. The Baserow formula looks like this:

(field('Benefit: Adoption')/6)(25) +
(field('Benefit: Revenue')/6)(15) +
(field('Benefit: Strategic')/6)(10) +
(field('Cost: Dev effort')/6)(25) +
(field('Cost: Operational')/6)(15) +
(field('Cost: Risk')/6)(10)

If we want to focus on a different metric, we can adjust the weights to fit our needs.

Because we want the community to be able to see this score as well, we’re synchronizing the score back into the weight column in GitLab. This allows everyone to see a prioritized list of features: Issues · Baserow / baserow · GitLab.


Thank you for sharing the backstage :slight_smile:

Some more questions if I may:

  • If I understand well, you are doing this scoring during your monthly meeting?
  • Could you tell us how many people are involved into Baserow development?
  • What is you process about accepting merge requests from the community? There are many and it can help the development, but I guess it is a lot of work to review them…

I like the roadmap view on the webpage. :slight_smile:
Keep going, you rock! :muscle:


Hi @Govi, of course, happy to answer your questions.

Feature scoring is something we try to do a bit more often than monthly. Because scoring can be a bit monotonous sometimes :sweat:, I prefer to score for not more than an hour, but this is a personal preference. After the release, which happens roughly every 5 weeks, we have a planning meeting where we discuss new feature requests, sometimes even score them, and go over the highest scored issues. This can sometimes result in changing the score because we think issues are not scored correctly. Based on the ones that are scored highest, we decide what the priorities will be in the next week.

We’re currently with 10 developers (including me) working on the product. But in the end, all our other team members also contribute to the product by creating UX/UI designs, writing tutorials, testing features, making sure that the right features are prioritized, etc.

The contributing process is defined in our file ( · develop · Baserow / baserow · GitLab), but it’s quite simple in practice. All merge requests are welcome, but they need to match our quality standards in terms of both code, documentation, UX, but also if it does what the issues described. We don’t accept merge requests if they don’t match our goal. We have a rule that at least two internal developers must be involved in a code change. That means if an internal developer submits a merge request, at least one other internal developer must review it. If an external developer makes a contribution, it means that two internal developers must review that code before it can be merged.

Thanks for your kind words!

1 Like