Melissa Ushakov on GitLab’s post-IPO PM org evolution, async-first collaboration, and open-sourcing internal PM practices

Product State Q&A

Melissa Ushakov is Group Manager, Product Management at GitLab — as well as Board Treasurer at Latinitas. She was formerly a Sr Product Manager at Atlassian, AgileCraft and Rackspace. Previously, she held roles at Deloitte and Microsoft.
LinkedIn

EC: How has your PM org matured and transformed after IPO?

MU: I joined GitLab 4.5 years ago, over a year before IPO, and it has been an exciting ride! There have definitely been changes in the organization since then — but the startup essence of the company has remained intact, which I credit our leadership team with. A couple of changes come to mind:

Depth over breadth: GitLab established itself as a market leader for DevSecOps by providing ‘just enough’ functionality across the entire lifecycle. As the company grew, we began to see clear patterns of adoption and feedback for specific product areas requiring more rich functionality. We now focus on providing more depth in those areas while continuing to expand to new areas with less depth.  

Focus on usability: GitLab is known for its iteration practices and emphasis on creating the smallest minimal viable change possible. While we have kept that at the forefront of how we develop new features, as the company has grown, we have raised the bar on usability for new features. We created the experimental feature category to allow customers to opt into early features — and give us feedback about work in progress.

Transparency: While we have intentionally pushed the envelope for transparency in a public company, there are more laws and regulations we need to abide by now. For example, our company OKRs are no longer public since they may contain forward-looking information. 

EC: I understand your remote team primarily collaborates and makes decisions asynchronously. What’s your process and philosophy to do this effectively? 

MU: Yes, GitLab is a remote and asynchronous-first culture. In my opinion, if you are not primarily leveraging an asynchronous first culture as part of remote work, you are not getting the total value of remote work. There are a couple of practices that I have found helpful:

Async-first—It’s easy to fall into known synchronous communication patterns. However, team asynchronous work will allow each individual to maximize the value of their time and not try to cram an entire work day into the hours when they overlap with their team. Don’t use synchronous time for business-as-usual routines like status updates, which your team can easily do asynchronously. Use synchronous time to align on decisions where there is disagreement or for team building. Read more about GitLab’s philosophy here.

Document processes and common questions—Documentation is crucial to minimizing bottlenecks and accelerating decision-making processes in a remote setting where direct communication may be limited. By centralizing information and standardizing procedures, documentation enhances efficiency across distributed teams. This is why the GitLab handbook is such an important living document that everyone in the company contributes to.

Optimize decision-making—One core tenet of GitLab’s culture is the concept of a Directly Responsible Individual (DRI). This translates into clear and effective decision-making centralized around a few individuals, which is critical for maintaining high velocity when making decisions in a global organization. 

EC: What’s key about product leading open source projects — And how have you ‘open sourced’ your internal ways of working?

MU: GitLab is known for radical transparency, and thankfully, that is not one of the things that has changed dramatically post-IPO. Being a PM at GitLab and working on the open-source components changes the way you approach PM in unique ways.

Our issue tracker is public, which means members of the community or customers can request new features, upvote existing issues, and see what we are working on in any given iteration. It’s initially intimidating to work in such an open way, especially when you have to make tough prioritization calls and say no to requests in public. The pros far outweigh the negatives. Having such a close connection to the community is a game changer as far as having a pulse on customer needs and being able to reach out to your user base at any time to perform quick idea validation. We have a very passionate community, and I am thankful that we can interact with them directly to gain different perspectives on improving our product.

Regarding how we ‘open source’ our internal ways of working, you should check out our GitLab handbook ! Most of our way of working is public, including how we do product management. We’ve heard from many smaller organizations that they have forked our handbook and tailored it to meet their unique needs. In remote work practices, GitLab has created free learning courses through our own learning platform and Coursera. I would encourage anyone who is a ‘ways of working’ geek (like me) to check these resources out!

“Having such a close connection to the community is a game changer as far as having a pulse on customer needs and being able to reach out to your user base at any time to perform quick idea validation.” - Melissa Ushakov