Just as we are constantly iterating on our product, we are also improving how our company functions. Methods that worked in the past may no longer be effective as the team grows.
In the past two years, we have significantly revamped our approach to product releases, which is the topic we’re diving into in this 4th round of Founder Chat with @bram.
Question for Bram: How far in advance do you plan product releases, and how has this process evolved over time?
In the early days of Baserow, when we were with just three developers, I somehow thought it was a good idea to do a product release a day before I went on vacation. This wasn’t a smart decision because on the first day of my vacation, multiple things went wrong, eventually it cost us quite some hours to fix it, and it cost part of our vacation (sorry Wendy).
During those days, I was speaking with users a lot, so I had a good overview in my head which features were the most important. We aimed of doing a release every month with strict deadlines on the big features we wanted to deliver. This resulted in working many weekends and evenings to meet those deadlines. As founder, you can do this, but this is not something you can ask other team members every month. Eventually, the codebase became more complex, resulting in longer development time, and I was slowly doing less development. It was not feasible to do releases every month.
This made us switch to a system where we choose some features, and do a release when they were all finished. This usually took roughly two months or so, but resulted in delays because if feature A was not finished, it blocked the release of feature B. As the development team, and development capacity grew, this also didn’t work for us anymore. That was combined with me doing less development, other team members also speaking with users, and more requests from our community.
It was difficult to keep an overview of what everyone wanted, and not block the release because one features takes longer to develop. We had to come up with a different system. We’re now doing most of the future planning in Baserow, which is synchronized with GitLab, but that’s a different story.
After a release, we now have a planning meeting to sync on what’s finished, what’s left to do and which features are being prioritized. The development team then works for 4 weeks, and regardless of what’s finished, we prepare for a release. This is then tested extensively, deploy to baserow.io, and a week later, officially released to all our self-hosters. The reason we do that is because it’s easier to prepare the release content if you know exactly what will be released, know that it all runs stable, and it’s much easier to fix a bug on baserow.io than after it’s released to self-hosters.
So far, this is working well for us, but as the company grows, we will run into other problems, and this will change how we do a product release.