AMA: GitLab Director of Product Management, Fulfillment, Omar Eduardo Fernández on Building a Product Management Team

The first thing that you want to do is to establish the credibility of the PM organization and earn the trust of your peers, otherwise, you risk becoming irrelevant and ignored. PMs need to lead by influence. To do this well, I'd set up a 30-60-90 day plan in which you meet a lot of leaders across the company, understand their pain points, talk to customers and understand their needs and pain points too, and then put together a proposal for how the PM organization will help solve these pain points. Until a product function is built up, often the product direction falls on the CEO and the executive group. As the first PM hire, you should look into what gaps that is leaving from a product management perspective and start to plug the gaps. As you do this, contribute to the product vision and direction and showcase that you can lead it. Over time this increases the responsibilities and influence of the product function.

You can spend too much time setting up "product management processes" and covering a lot of ground. Instead of focusing on creating a product management process, focus on diagnosing what's going well and what isn't in your current team and product output. 1. Do teams have confidence that they are building the right thing? If not, focus on sensing mechanisms and processes to gather more input during problem and solution validation. 2. Are teams effectively collaborating with UX and Engineering to come up with great product solutions? If not, why? Consider clarifying roles and responsibilities, helping the teams better collaborate by creating PRD or UX intake templates, working to ensure that engineering is present during solution validation, improving UXR, etc. 3. Is the team building product to spec and relatively bug free? If not, focus on quality processes -- beef up QA, add bugbashes to your releases, etc. 4. Is the rest of the organization (execs, sales, support, marketing) excited and ready to properly support new product launches? If not, work on upfront alignment with other groups around priorities, cross-functional project staffing, field and support enablement as part of product launches. 5. Are product managers showing the right competencies as PMs? Are they able to properly validate customer pain points, use sensing mechanisms to prioritize, come up with great solutions, iterate and deliver those? If not, focus on team competencies development via coaching, learning/development, hiring, etc. There's a lot more that you could do, but this gives you a gist. I'm a fan of iterating on process changes. Find a problem, then only add the smallest process necessary to fix the problem. And as you add process always ask yourself whether there's other process that needs to be removed. if you just accumulate processes over time you'll stifle the organization and your best PMs will leave.

I'd first focus on setting up a robust planning process so that no matter which PM other teams are working with, they know how to make requests and how they'll be handled. This includes: 1. A clear milestone planning process where each PM summarizes and communicates what their teams will be working on for each milestone. 2. A lightweight intake process for bugs and feature requests, so that requests are captured in the same place and with the same high-level information. 3. A consistent quarterly prioritization process such as OKRs. While there are other key processes, I find that the most important at first is making it easy for other functions to work with product and these 3 cover a lot of ground around how to make an ask, how to know if it's been prioritized, and knowing what major things to expect to be delivered over a quarter.

GitLab is quite transparent, so you can find our structure defined pretty publicly here. We have the overall product that we divide into sections, stages, groups and categories. This is how it makes sense for us to organize our work since GitLab is a product that supports many different feature areas across the software-development lifecycle, which we use as the foundation to set up the org structure. We have section leaders (typically Director/Senior Directors), stage leaders (often a group PM or Director), and each stage has multiple groups, each led by a product manager (intermediate, senior, principal or senior principal). Each group has a dedicated R&D quad (PM, design, engineering, and quality) that is in charge of multiple product categories or feature areas. With this organization the various PMs working on feature areas that belong to the same stage all report to the same stage leader. Those stage leaders in turn roll up to section leaders who in turn roll up to the Chief Product Officer. The UX department is similarly structured, also rolling up to the chief product officer, but each UX designer reports to a UX design manager, etc.

Make or break things when I'm interviewing a PM candidate: 1. Clear and concise answers to my questions. If I need to ask the same question again because the candidate didn't address my question, that's a big problem. PMs need to communicate constantly with many teams, so they should always hone their ability to listen to questions, write them down, and answer those questions without being confusing or too verbose. 1. I often ask a candidate to pick a hobby, project or anything else and explain it to me in 5 minutes. I then tell them that "don't assume anything about I know or don't know about the topic, but after the 5 minutes I should know what is most important about the topic." A great candidate knows how much context to provide and recaps at the end what "the most important thing" is. 2. Self awareness and low ego. A PM must show a willingness and ability to reflect and learn from past mistakes, know their strengths and weaknesses, show they can collaborate with people from all across the company, and adjust their plans based on new information. Lack of self awareness or strong egos often lead to PMs struggling to collaborate accordingly or becoming inflexible in their direction. 1. One of my favorite interview questions is "Tell me about a time that you failed". A great answer usually involved a big failure, not a silly mistake, that the candidate takes ownership of and shows that they learned from. I hope this helps!