Omar Eduardo Fernández

To get better at framing and articulation as a product manager, focus on being clear about the business and user problems you're solving. This approach is similar to writing a good Product Requirements Document (PRD), where you detail the problem, the target users, and the desired outcomes. It's about breaking down complex ideas into understandable parts and connecting them to real needs. For more detailed steps and examples, refer to the article on writing a PRD at How to Write a PRD. Start by writing a good PRD, then use the output of that PRD to craft the narrative you'd tell executives, colleagues, etc. about "why does this matter to the company? why now? and how we are solving it."

In a nutshell: the product management function is tasked with clarifying and communicating what product investments that will help a company reach its goals, and working across teams to deliver these results. There are a lot of activities that a product manager does, but it will ultimately go back to that premise, at different levels of detail: 1. Product Vision: articulate what the product can achieve in the long term for users, and how that will in turn achieve the company's goals. 2. Product Roadmap: break down the vision into the appropriate sequence of investments (new features, improvements, etc.) that will move the product towards that vision. Account for current competitive landscape, company priorities, and more. 3. Feature specs / PRDs / Epics: take a specific initiative and clarify what specific things need to be delivered as part of it to make progress towards the roadmap / vision goals. 4. Iteration plan: take the initiative or feature spec and break it down further, clarifying and communicating the sequence of smallest changes/steps that should be shipped to drive user value and build towards the vision. To do the above well, you need to talk to customers and have great customers insights, collaborate with UX and engineering, align with cross-functional partners, understand business priorities, communicate a vision and goals clearly, handle conflicts and resolve misalignments around priorities, etc. This is where all the various skills that are required to be a good product manager come in. But, in the end, your job is to clarify and communicate product investments and work to deliver the product changes that will make a company successful.

Providing feedback or managing the work of someone that doesn't report to you can be challenging, but ultimately doing that well is very similar to managing a direct report. You should: 1. Build rapport: the person should trust that you are competent, that you understand what is important and why, and you'd only ask them to do things that are worth doing. You should care about them and not just come to them simply to "get things done for you." Ask them about their other projects and goals and share your insights on how your ask helps with their goals. 2. Align on goals: nothing will go smoothly unless the two of you have a shared goal. Before asking for something, explain why it is important and how it contributes to the greater team's success, including how it helps their priorities. Help them see how achieving this goal will help them and their teams. 3. Set expectations: be clear on what is needed and by when. Make sure to explain the why behind these expectations - if there's a looming due date, why is it important that the due date is met? If you ask for a specific level of quality, what is the work going to be used for that requires that level of quality? 4. Identify conflicts and help resolve them: the most common conflict will be the time to prioritize the work. See if the person is being asked to work on too many things and, if so, help them prioritize the right work (ideally the one that you're asking for) by working with them and/or their managers to clarify the importance of the competing priorities and align on why this is the most important thing to do now. 5. Recognize great work: make sure that you give credit to others for the work that they do, don't try to take any credit. They earned the recognition for their great work.

GitLab is a fully remote company, we don't have any offices and have team members spread out throughout the world. The projects that my team work on are highly cross-functional. Here is what I've found to help with cross-functional alignment. 1. Regular 1-1 check-ins with key stakeholders from other functions. I have monthly 1-1 (one to one) check-ins with key leaders from other functions that I often collaborate with. In our case as a Fulfillment team, that includes leaders between IT, Billing, Revenue, etc. These are Zoom calls, with a shared Google Doc where we take notes to ensure that we can reference our discussions for continuity. 2. Establish channels for asynchronous discussion for prioritization. As my team puts together the quarterly plan, I make sure to give updates to the leaders in other functions. I do this in Slack, using a public channel where all the leads collaborate on topics that impact our functions. I tag the leaders in updates that are relevant to them, and let them know early if some priorities will change that may impact their areas. Similarly as the quarter goes on and new initiatives come up, we start threads in our public/shared channels discussing the prioritization changes or challenges so that all of those involved, especially those responsible (see #3), can be aware of the rationale of the change and discuss it. 3. Assign clear responsibilities to individuals for cross-functional projects. Every cross-functional project at GitLab has a clear DRI (or Directly Responsible Individual) from each function involved in the project. These DRIs are committed to ensuring that the project will be successful. It is critical to have a DRI from each major function, but only one, so that you have a small group of individuals that are highly plugged into the initiative and can ensure that their functional work will happen. In addition to having functional DRIs, we make sure to have an overall DRI for the initiative. This is the person who will make sure that decisions are made, plans are clear, and each function knows what is expected from them. Having regular 1-1s check-ins, using asynchronous and public channels for prioritization discussions, and assigning clear DRIs / responsible individuals from each function to projects have truly served us well in the many cross-functional, remote projects that I've been involved in so far. I hope this helps you too.

Depends on the stakeholders' seniority and role in the initiative, but here's a few guidelines that I use, which I outline below. However, one important GitLab cultural practice that is very helpful is that for every major initiative we have internally public channels where anyone interested in the initiative can join (the only exception are projects that must remain confidential). That way, as we make progress on the initiative anyone interested (all stakeholders and curious individuals) can join the channel and see the progress that is being made, the challenges, and can chime in with feedback at any point. This is huge for collaboration. Outside of that, here are some specific things that I like to think about: 1. Executive sponsor: Early on, I communicate with them until we are both aligned and agree on the goal of the launch and the plan to achieve it. After that's done, I update them on any major changes around launch dates, feature scope, and depending on their interest in details, changes to the user experience. I don't think of these as "gathering feedback" as much as providing updates. If I run into any launch blockers, I'd immediately let them know. 2. Functions not involved in development but with good insight into users/customers (Sales, Marketing, Support, etc.): I think of them as needing to be involved heavily in certain situations -- solution validation and testing and GTM approach. If you did your job right upfront, you've already been in touch with them and they know that you're developing a solution that you'll be launching, and what the scope of the solution is (e.g., what it will do and achieve). As you get closer to launch, you want to strategically choose moments in which you can validate that what you're building will be good for users/customers once launched. To do this, give demos or request testing/solution validation as the team builds -- when you have enough built that they can appreciate how things will work and provide feedback, but not too late that you can't change anything prior to the launch. For example, for a 3-month project, you'd probably want their input every other week from ~6 weeks in until the end of the project. 3. Other impacted functions that may need to plan around the launch (e.g., Finance updating financial models). For anyone else of interest, I'd make sure that they are aware of what's happening at least the month ahead of the launch and again the week of the launch. For this I focus more on announcing in a public Slack channel focused on that launch when things will be happening, and make sure that those interested folks are looped into that channel. The idea is that they know and can plan accordingly, and if they need to provide feedback they can.

Building partnerships across functions requires: 1. Define a compelling shared goal. Define a clear and measurable goal that all functions involved would consider important and would prioritize. To the extent possible, align them to goals that already exist for all functions, such as your overall company goals. The more alignment and excitement you get around the shared goal, the better the team that you'll be able to build and the results that you'll deliver. 2. Build the right team. Ensure that you have the right mix of skills across the functions and team to deliver the goal. While each function may have specific responsibilities, some skills need to be complemented across groups regardless of the function that contributes it. Excellent communication skills, collaborative approach to solutioning, and a mix of technical and functional expertise will be key for just about any meaningful project. 3. Set up the right communication structure and tools. Working cross-functionally is hard, working within your team is easy due to the ease of using already established communication channels and tools. When you set up a new initiative, make sure that the full group is communicating effectively and using the right tools to collaborate and keep each other up to date on progress. Seeing progress from other functions will inspire further action, and snowball into lots of progress done quickly. 4. Report progress regularly. On a regular basis, I like weekly or every other week, communicate progress against the goal. Make it very concrete and visible. This acknowledges and rewards those that are working on the initiative and inspires and mobilizes those that aren't actively contribute yet. These are the tactical things that you can do. However, you should also consider constantly building strong relationships and trust with other functions before you need to start collaborating. Doing so will help you ensure that when the need arises to collaborate, you have a strong foundation to work on and can focus on delivering results.

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!

The question asks about getting approval, but I'll instead focus on how you gain feedback and improve your roadmap so that there's alignment around it. This distinction is important, you are responsible of the roadmap. Instead of trying to get approval, focus on building the best possible roadmap after incorporating stakeholder input, and then communicate it. To do this, I'd recommend the following: 1. Have a strong grasp and communicate how your roadmap aligns with company priorities. By telling a compelling narrative as to how your roadmap contributes to your division and company goals, you have a much better chance of aligning with other stakeholders. Ultimately, you should all be working towards the greater company goals. 2. Unearth disagreements by asking the right questions. Ask specific questions of other stakeholders, such as "are there initiatives that we aren't prioritizing that would better contribute to our company goals?" By doing this, you show willingness to revise the roadmap, but you also focus the conversation on how the initiatives will help the company. 3. When there's disagreements in priorities, focus on data-driven criteria used to prioritize efforts. When someone thinks that one of their initiatives should be higher priority, be transparent as to how you're prioritizing, what factors matter, and how you see the initiatives stack up. For example, someone from operations may be advocating for an initiative to reduce costs, which isn't getting prioritized. You can be transparent that cost reduction initiatives are not being focused on at the moment because the company leadership is prioritizing initiatives with revenue growth potential. Similarly, if someone is advocating for another revenue growth opportunity, you can look at the data and determine whether there's clear signals that point to one of the initiatives having higher revenue potential and base your prioritization decision on that. If the data is missing, be transparent as to what data you do have and how that's influencing the decision. 4. Involve the right stakeholders in conversations. Sometimes, you'll see conflicting information from various stakeholders that is causing prioritization issues. In these cases, it's important to either (1) drive clarity and alignment across those stakeholders by bringing them together to discuss - either on a call or asynchronously or (2) involve other stakeholders with a broader perspective of the business that could help provide additional context. For example, when I had conflicting requests from different stakeholders in sales about what initiatives would better support our revenue goals, I had to bring in a more senior sales leader that would oversee multiple departments to help challenge and clarify which of them was truly expected to more impactful and why. These are some of the main things that I do to get alignment. It is important to document all these decisions and discussions so that in the future you can reference them. This is why I appreciated GitLab's focus on asynchronous communication, since that leads to more of the discussions being written down and documented. If there are disagreements in the future, it's easy to reference past discussions for context.

I'll share a few examples from my career that I've seen, with some context. In the end, PMs don't just do one thing, so their bandwidth will vary based on what the team needs from them and what support they have. 1. As a new PM at a ~200 people startup, I started by working with 3 engineers. We didn't have a designer on the team, and I had to do a lot of work to write very detailed product specifications, project manage delivery of initiatives, test solutions, etc. 2. As I became more senior at that same start up, got a designer on board, testers, etc. I scaled up to about 10 engineers. Towards the end of my tenure there, I was leading the efforts for 15+ engineers across 3 groups, but that was only possible because we were working on a few major initiatives with a lot of backend requirements (search ranking algorithm updates, etc.) that didn't require a lot of PM input. We had senior engineers and engineering managers that would translate the requirements into very difficult engineering projects so I was free to work on other efforts. 3. When I started working in a smaller team at Google, I started by running one team. I was one PM covering ~4-6 engineers. In that same team I later on moved to cover 2-3 groups, each of ~4-6 engineers. Again, though, this was only possible because I had a mix of teams, some with more backend heavy work that didn't require as much PM focus. Each of the engineering teams had very strong engineering managers, too, that owned delivery timelines, and a technical program manager that oversaw all major deliverables. 4. I then moved to a different team at Google, working first with 5 engineers, later on expanded to ~10 engineers. Half of the team, however, was focused on app reliability and performance and fixing old bugs. 5. The later examples keep repeating the same themes. I'd start with fewer engineers and expand over time, the longer I stayed on the role, but mostly covering a mix of heavy frontend work, rapid feature iterations, and some groups or engineers with heavily backend focused initiatives. 6. At GitLab, we aim for one PM per Group, each Group has ~5-8 engineers, an engineering manager, a dedicated designer, and support from quality and technical writing. With all that in mind, I'd say: strive for 5-10 engineers per PM, taking into account what support the team needs. 1. If the team has a lot of lengthy projects and/or backend heavy initiatives, a PM can typically stretch to cover ~15 engineers. 2. If the team has a lot of frontend initiatives with fast iterations, the PM may be fully consumed with ~5 engineers. 3. However, if you have a strong UX designer and a good engineering manager that owns feature delivery timelines, a single PM can expand to cover 8-15 engineers worth of work. 4. The longer that a PM is on a team, the more groups/engineers that they can typically cover due to familiarity with the product area and established working patterns.

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.