AMA: GitLab Director of Product Management, Fulfillment, Omar Eduardo Fernández on Stakeholder Management

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.

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.

When senior executives disagree, you can help getting the situation unstuck by bringing in additional context, information, or factors to consider to the discussion. A few of these could be: 1. Help structure the conversation by documenting arguments in favor and against the strategy. Document what are the arguments in favor and against the proposed strategy, try to do this in a way that's neutral and unbiased. Then focus the discussion on the merits of each of those arguments. 2. Outline a framework to evaluate the strategy. Looking at the arguments in favor and against, you can get a good sense of what are the underlying factors that matter to determining whether the strategy is worth pursuing. One executive may be focused on potential gains (e.g., more revenue) while another may be focused on containing risk (e.g., preserving current revenue). Try to break down the underlying factors that each argument is trying to support , so that it becomes clear what is being used to decide. Then use this to guide the discussion with a focus on the acceptable parameters for the various executives. 3. Look at what others have done. If the strategy has been used by other people, companies, products, do the research and share the examples and any data around whether they were successful and why. Be thoughtful in how you compile the information so that it helps further the discussion. 4. Bring in other leaders to the discussion. Two senior executives can have a lot of context, but there may be other executives or senior leaders (even below their level) that can provide more context or insights that can help move the situation forward. For example, when stuck on a disagreement between a sales leader (focused on revenue) and a product leader (looking to simplify systems) around a revenue initiative, consider involving a finance leader or a customer success leader to weigh in and provide their perspective. In summary, I'd focus on ways to expand the conversation or reframe it by bringing in more context and data or bringing clarity by structuring the conversation into clear criteria that you can focus on.

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.

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.

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.

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.