From the ground up: five years at productboard as a software engineer

I joined productboard in 2015 as the company’s fifth employee. In the five years since, we have grown to over 160 employees, reaching various milestones along the way: from pre-seed funding to our recent $45M Series B. Each stage has had a different impact and brought new opportunities for me as a software engineer.

Before I joined productboard, I worked at a marketing agency where we developed websites and applications. Almost every month, we were working on a new project for a different client. After a few years, I realized I don’t want to do this anymore. I wanted to focus on one product, to watch it grow and have an impact on its development. I decided to look for a new job.

Looking for my next adventure

I started by creating profiles on job portals. Soon after, productboard’s CTO, Daniel, contacted me and explained that they were looking for someone to help them develop the backend for their SaaS application.

He told me that the application helps product companies understand what users need and prioritize what to build. I would join a team of five: Hubert (CEO) in San Francisco, Daniel (CTO), Zuse (full-stack developer), and Majo (designer) in Prague. They were using a tech stack that I was familiar with: Ruby on Rails, Postgres, React.js, and Heroku.

The idea behind the application was interesting to me. It was exactly what I was looking for — the chance to work on one product. And the fact that it was a startup in its early stages meant I would have a significant impact on the product from the beginning.

Of course, there was a little bit of risk and uncertainty. What if the idea behind the application was wrong and no one would use it? At the time, productboard had a pre-seed investment, and the product was in private beta — only ten customers were using it. But prior to this phase, Hubert and Daniel had carried out thorough market research and were talking with product leaders from different industries. This gave them confidence that there was a huge market for a dedicated product management system.

On top of this, Hubert had previously worked as VP of product, so he knew from experience that product managers were missing a dedicated tool. All of that convinced me to apply for the job.

Becoming a productboarder

At the time when I was applying for the job, the productboard team was out in San Francisco. I live in a small city in West Bohemia in the Czech Republic, so all our communications took place through video chat. I had a call with every team member, and they all seemed to be excited about what they were doing.

We agreed that I would do a trial task first, and then, based on the results of the task, we would figure out the next steps. The task was to carry out a code review of the backend application and implement in-app notifications. It was a great opportunity to see the code before I actually joined productboard. Of course, I had to sign an NDA first.

A few days after completing the task, I got a job offer, which I immediately accepted. At the time, I still hadn’t met anyone from the team face-to-face. The first in-person meeting I had was with Hubert when he visited Prague one month after the first contact. Shortly after, the rest of the team returned from San Francisco to Prague, and we all finally met up.

Early days — working remotely

When I started, our development team was based in Prague, and Hubert was based in San Francisco. Since I didn’t live in Prague, I worked remotely from my home office and commuted to Prague when needed. I already had experience with this setup from previous companies, so it wasn’t a problem for me.

The primary communication channels were Slack and video chat. In the office, we had a dedicated iPad with a video bridge to San Francisco. The whole company had a daily standup meeting as well as a weekly all-hands meeting. Right from the start, the company culture was open to remote work.

Getting stuck into product features — and learning lots along the way

The first big product feature I worked on was integrating productboard with other third-party services like JIRA, Trello, and Pivotal Tracker. I am primarily a backend developer, but I had to deliver it with the frontend part also because the team was small, and everyone was working on something different.

The frontend was written in React, and I didn’t have any experience with this framework. But that wasn’t an obstacle, because I was given the time and space to learn about React. So, with the help of my team members, I was able to deliver it as a complete product feature. I liked that there were no deadlines, and we were able to focus on the quality of the code rather than the speed of development. After finishing a product feature, we did demos during all-hands meetings.

As a developer, I was responsible for the entire lifecycle of a feature’s development, from analysis to implementation, deployment, monitoring, and support. We didn’t have a support team yet, so everyone was helping to answer questions on our customer support channels.

I usually picked up tickets that were related to application parts that I implemented or was familiar with. It was interesting to see what problems customers were solving or what issues they were experiencing. It was a great way to get feedback on your work, and I liked being able to help customers in such a direct way. That motivated me to pick up support tickets more often. I hadn’t had this opportunity to communicate with end-users before in my previous companies.

We already had happy customers who liked the product and were willing to start paying for it, so the next initiative I worked on was the implementation of a system for recurring billing and subscription management. We chose Stripe for the implementation. The first customer subscribed in October 2015. As one of the company values is transparency, all employees had visibility of all business metrics right from the start.

Public launch and seed funding

At this point, the product was still in private beta. We hadn’t done any big marketing campaigns around it yet. Our customers either found us themselves or came to us by recommendation. In July 2016, we had 100 paying customers, and the product was becoming more and more popular.

TechCrunch invited us to participate in the Startup Battlefield at Disrupt SF 2016. We didn’t win, but it was a great marketing opportunity to let more people know about our product. I remember watching the live stream and checking the platform metrics in case we needed to scale up resources. Fortunately, there weren’t any platform issues.

Our growing customer base forced us to pay more attention to platform stability, performance, and security. We introduced an incident resolution process. There was always at least one developer on duty, with a weekly rotation. We also passed our first penetration test — something we have repeated twice a year ever since.

In the same month, we raised our first round of capital — $1.3 million in seed funding. This milestone propelled the company forward, allowing us to hire more people and speed up development.

Time to split teams

In 2017, as the team grew, our daily standup meetings and collaboration started to become less effective. We decided to split the engineering team into two smaller teams and work closely on specific goals in six-week cycles. The teams were not fully independent, as some people were part of both teams — we shared a designer, for example.

The two teams were given the freedom to decide how they wanted to work, collaborate, and plan. They could have one-week or two-week sprints, use Scrum, Kanban, or anything else. It was up to the team to work in a way that suited them best.

We also established a customer support team and started building a marketing team. That helped us decrease response times on our support channels.

Series A and continued growth

In 2018, we grew from 14 to 48 employees, had 1000 paying customers, and raised $8 million in Series A funding. We hired people from different fields and built specialized Data, QA, Sales, and People Ops teams.

Even though I was in a product team, I had been helping out with various projects that weren’t related to the product itself, such as internal integrations (Salesforce, Marketo, etc.), analytics, and our data analysis pipeline. With the establishment of these new, specialized teams, I was able to hand over some of my responsibilities.

In late 2018, we changed the structure of our product teams. Each product team now consisted of a product manager, a product designer, engineers, a QA engineer, and an engineering manager. The engineering manager was a crucial part of the team and helped build a vibrant team culture, optimize processes, and help teammates with personal growth. As a developer, it meant I could discuss my personal goals during regular 1-to-1s.

We also built more specialized engineering teams — an Integrations team, a Platform team, and an Infrastructure team. I moved to the Platform team, whose responsibilities were to focus on platform stability, performance, and improving the developer experience by building internal tools.

We were running on Heroku, but it started to limit us. It was getting harder to investigate performance issues because we didn’t have visibility to all the metrics we needed, and the platform missed some important features. So another responsibility was to prepare for migration to AWS infrastructure.

Reaching the 100-employee milestone

I hadn’t had much experience with AWS infrastructure, so the migration was a great opportunity to learn more about it. Our team was collaborating with the Infrastructure team and helping migrate a backend monolith application to AWS. We used Kubernetes to deploy and manage the application. After several months of preparation and testing, we were able to fully switch to AWS.

My next challenge was helping a product team replace Postgres full-text search with Elasticsearch. The team only had one backend developer, and as the initiative required more, they asked me to join the team. I hadn’t worked with Elasticsearch before, so it was another great opportunity to learn something new. I agreed to transition to the new team and started to learn how Elasticsearch works. This was the last time I changed teams.

At the company level, we reached a huge milestone — we ended the year with over 100 employees. For the first time in my productboard journey, it was a challenge to know all my colleagues well, especially across offices. Thankfully, we have initiatives in place that are helping with that. Every employee has an opportunity to go to our San Francisco office or, in the case of US employees, to the Prague office. In both cities, we have company flats where we can stay. Another initiative is a Slack bot that randomly pairs people and connects them. They can then meet in person or remotely via video chat.

The biggest initiative, however, is our yearly offsite, where all productboard employees meet in one place and spend a few days together. I remember my first offsite. There were 4 of us, and we rented a flat in Lisbon, where we spent most of the time coding. It’s not possible to compare the first offsite with the most recent one, where over 100 employees spent five amazing days together.

With so many people, the event required a huge amount of organization. It had a defined program featuring presentations from different teams and departments. We shared our achievements and plans for the future. There were also team activities that helped us get to know each other better.

Series B and the future

2020 started with the announcement of a $45M Series B funding round. That was the first time I saw productboard in the news on major TV stations in the Czech Republic. It was an amazing feeling to be a part of something big.

In the engineering department, this year will bring significant changes. We want to move towards a microservice and micro-frontend architecture and build independent teams. Each team will be fully responsible for their services and will have an opportunity to choose which technologies they want to use. This will help us with hiring because most of the backend code is currently in Ruby, and it is getting harder to hire Ruby developers in the Czech Republic.

Other goals are to get SOC 2 certification, build our first engineering team in the US, and build a completely remote engineering team in Europe. Oh, and the Prague-based team is moving to a brand-new office in August.

When I look back, it has been an amazing ride. Every year has been different and brought new opportunities to learn and work on personal growth. I have had the chance to work with great teammates and have learned a lot from them. It has been an amazing experience to see a startup grow from 5 people to over 160, gaining over 2500 customers along the way.

With customers and data growth, there are new challenges before us, and I am looking forward to all of them. The work at productboard is never dull or predictable, and that is what I like most.

Interested in joining the Czech Republic’s hottest startup? We’re always on the lookout for talented engineers. Check out our careers page for the latest vacancies.