Engineering life at Productboard:
A deep dive into our workflow and team dynamics
After taking you through the hiring process in my last post, I now want to delve deeper into engineering life at Productboard. I’ll be detailing the onboarding process — two weeks of fun dedicated to studying the ins and outs of Productboard, pair programming, and getting to know the team. You’ll also get to know our team dynamics, dev stack, and workflows — well, at least my team’s workflow, but you’ll get the idea!
We’ve got a lot to cover. Ready? Let’s get started…
Onboarding
The first few weeks and months at a new company can lay the groundwork for further development. This started with the onboarding process, where you’re officially introduced to our product and codebase.
On your first day at Productboard, you get a welcome package of things you’ll need: your hardware (a Macbook and accessories), as well as some promotional company items and the book Inspired by Marty Cagan. The book explains product management and attempts to serve as a guide on how to develop good products. Productboard aims to be a standalone tool that puts the know-how discussed in this book into practice. It’s amazing (and super helpful) that the company explains at the very onset of your partnership what its product does and why it’s important. You won’t be handed some code and a task on day one and expected to perform. At Productboard, it’s important to us that you understand what exactly we are trying to achieve before we turn you loose.
A newcomer’s first two weeks at Productboard are exclusively filled with onboarding activities. You’ll be meeting with different people from around the company every day to get a sense of our structure and who you can turn to if there is a problem.
In my opinion, the most interesting part of the onboarding process came surprisingly not from engineering but from the product talks with Michel, Customer Support Team Lead. He went through the whole Productboard application, which includes insights, the feature board, integrations, roadmaps, and the portal. In the end, he also showed me how the user portal works and the actual questions they’re dealing with. His presentation will provide newcomers with some excellent context around the whole product, including parts of the system their team might not necessarily be working on. You’ll also gain a better understanding of the needs of a product manager.
The company has a highly complex and well-done knowledge base in notion.so. There’s a lot of information here that probably wouldn’t be accessible to employees at other companies. But Productboard strives to be very transparent. Information about the number of clients, revenue, interview questions, and many other things can be accessed by everyone. The company is based around data (and strongly promotes an open approach) and uses Looker for measuring every possible data metrics in order to make the right decisions.
The team
The buddy system is an incredibly important part of Productboard’s onboarding. Newcomers are assigned a buddy from their team who helps them work through some of the hurdles they may face during their first few weeks or months at the company. My buddy was Janči, and in the first few weeks, we programmed as a pair intensively, which quickly helped get me oriented with the code.
Pair programming is a strong and very useful part of our team culture at Productboard. Part of our team works remotely, so it’s important to occasionally meet online. For example, I have regular monthly chats with Matěj, a software engineer from Bratislava, where we talk about everything but work, whether it be a debate about the meaning of life or recommendations for running shoes or the best place for a sauna. It’s the same with Julia, who works in Berlin, or Ivo, who works in Sofia.
Once or twice a week, team members may meet up for a short coffee or chat before our standups. We also use the Tandem app for spontaneous meetings. If we have Tandem active, we have our status synched on Slack, allowing others to jump into our discussion if they wish. Often we also do pair programming directly through Tandem.
We practice scrum with weekly sprints. For retrospectives, we use Retrium. Sometimes we will also use Miro, or FigJam for our workshops. For prioritization, we use Productboard 💪. For task management, there is Jira. Our repository is in GitHub, and the pipelines are in GitLab. We have a dedicated team that maintains Continuous Integration (CI) and general Developer Experience (DX).
Joska, our team’s engineering manager, holds weekly 1-on-1 meetings, where we mostly discuss self-development and things that can be improved. During my first few weeks, with Joska’s help, I set up a 30–60–90 plan, establishing my goals for the first three months. This helped me think about what I wanted to achieve at work and what motivates me. As a team, we make long-term growth plans, where everyone can define what they want their roles within the team to be and gradually move in that direction.
We also have game nights, where we meet up off-site and play multiplayer games as a team or whole company. We plan team hackathons to work on things that we consider interesting, but from a product perspective, have lower priority than others.
Double Diamond
As I mentioned earlier, the company’s decisions are completely based on data analysis. There is a public roadmap on the Productboard portal where people can influence the priority of what’s important to them within the company. The product manager then chooses what we’re going to work on next. Within our teams, we define goals (OKRs) for ourselves for each quarter, which help determine how our team means forward.
When developing a new functionality, we use a process called Double Diamond, which allows us to get a detailed view of the problem we’re dealing with and define potential solutions. We test each solution and then work on the best option. Everyone on the team is a part of this process. Working on a problem as a team is definitely better than going at it alone.
The problem with new products, which are redefining the market, is that it’s difficult to imagine what the right solution should look like. We have to try to test and design it ourselves. At the same time, it’s important not to get hung up on things that take a lot of time and don’t bring adequate value. If we did, the competition would catch up, and we would miss an opportunity. So we have to figure out what is most important for our users, come up with the best possible solution, test it, and get feedback. And then repeat, repeat, repeat until we come up with the best solution.
As the great Steve Jobs so eloquently put it:
People don’t know what they want until you show it to them.
Team workflow
Once a week, we have Discovery Insights, where Product Manager Wahab presents findings from user testing. As members of a team who are intimately familiar with the product we’re working with, we’re strongly influenced (and sometimes blinded) by our own knowledge, preconceptions, and way of thinking, which makes user testing an invaluable part of the development process.
User testing delivers new insights for us to focus on, regularly pointing out issues that we hadn’t yet anticipated. In addition to getting this crucial information, it’s also important for our users to know that we depend on their feedback, as we want to have the best product on the market.
When suggesting new functionality, we analyze user requests as well as what our competition offers in great detail. One of the first things our team does is a Design Workshop, where we describe the problem and try to come up with ideas.
During the workshop, we have the opportunity to suggest or describe functionality that we think would work. We don’t concern ourselves with the complexity of the implementation but rather how to best design it from the UX perspective.
Ideally, it’s best to go through this process before the designer creates the first wireframes so that the other participants do not influence our team’s thinking. We use paper or a whiteboard to record ideas and then photograph everything and enter it into a Miro board, where everyone inputs and presents their ideas.
Everyone then has a certain number of evaluation points that they can give to ideas that they think are important. They can even give all their points to one specific idea or just the whole prototype if they choose.
Finally, the ideas are ranked based on how many points they receive.
From this output, the designer can start making wireframes or a graphic prototype that takes into consideration the ideas from the workshop. This prototype is tested again with users and the team and then fine-tuned again and again until the best possible solution emerges. Developers are part of the whole process — they are regularly updated with the testing results and can suggest changes or directly pair up with the designers in Figma.
During every sprint, we have Backlog Refinement, where the product manager presents specific requests for functionality that will be done in subsequent sprints, and we discuss their complexity. Based on these discussions and story points, the product manager gets a more precise idea of the difficulty of the implementation and prepares the planning, which takes place on the starting day of the next new sprint.
Little by little, the new functionality is implemented, moving from the graphic prototype to an implementation prototype and then gradually integrated into the main codebase.
It’s true that our process is much more complicated than just letting a graphic designer think up how a new functionality should behave and then have them program it. But if we want to offer the best solution on the market, and if product excellence is to be more than just a phrase to us, it’s necessary to go the extra mile.
Engineering & Stack
At Productboard, our teams are set up vertically, and each team has its own product manager, engineering manager, product designer, quality engineer, and software engineers (FE/BE/full-stack).
In addition to the product team, we also have teams for the front end of the platform (infrastructure, DX, CI, etc.) and for the design system (Nucleus). Productboard is a frontend-heavy application, as the vast majority of its logic (around 90%) is in the frontend.
The frontend is developed in React and is completely written in Typescript. Flux is used for store management, which isn’t exactly factory standard but does its job very well. You can imagine it as a more low-level Redux where there isn’t just one store.
The application was developed as a monolith, but over the last year, the legacy codebase started to be divided into individual NX modules, which are generally relatively small. Each has its own API and can be tested effectively. Our goal is to also split up the application into independent product domains that can run as standalone micro frontends.
From a testing perspective, the application is well covered by the E2E tests built-in Cypress. It’s a bit worse with unit tests, but they have taken priority recently. Considering the size of the application, Developer Experience is surprisingly good, and developers are shielded from many potential issues by using their own scripts and Docker. It’s also worth mentioning Continuous Integration, which has helped ease the workload for many developers. I was pleased to find there is a bot that takes care of rebasing in the last version of the master. There is also automatic deployment of developer versions of the application, and even automatic team ownership of individual parts of the application.
The backend is built in Ruby, but you don’t encounter it most of the time during development unless you’re working as a Ruby programmer. Productboard’s infrastructure runs on AWS.
At Productboard, there is a Request for Comments (RFC) system, where it’s possible to suggest architectural changes in parts of the application, and let others give their input.
There are also Tribes, which bring people together across different parts of the product (Prioritization & Roadmap, Insights, etc.), and Guilds, which connects people working with a certain technology, like Ruby, React, etc..
Every team at Productboard is in charge of something slightly different. Our team (Blitz) primarily deals with Roadmaps and the Feature Board. Aside from this, everyone can also be involved in different initiatives or have ownership of specific functionality within the application. For example, in my case, I’m the Nucleus Ambassador, so I track and synchronize our team with things related to the design system and ownership and focus on dependencies between features. I’ve also joined a group in the company that deals with hiring, and we strive to provide job candidates with the best possible experience during the interview process. Nobody pushes anyone to do anything, but there are no limits to what you can do at Productboard. And it’s awesome!
Many companies push their programmers into management positions over time, as they don’t have anywhere to grow in engineering. Experienced programmers can then be pulled away from what they like (programming) to a position they enjoy less (management), and the company will begin to have a shortage of experienced programmers on its front line. At Productboard, we set up a Career Ladder, where it’s possible to grow both as a Manager and a Software Engineer.
Parting words…
I know, this is a lot to take in. I could have written full-length separate posts on each of these types, but really, who has time to read all that? I hope this gives all of you who are eager to join the ranks of Productboard a snapshot of what it’s like to work here. And yes I know I’m biased.
What are the workflows in your company? Do you have an idea of how we can improve? We are eager to find it. Let us know in the comments!
If you are ready to apply, check out what positions we are currently hiring for.
In the third and final installment of this series, I’ll be diving into all the benefits offered at Productboard.
