AMA: GitLab Group Manager, Product, Derek Ferguson on Product Roadmap & Prioritization

At GitLab, we say that everyone can contribute. This is true even when it comes to input into the roadmap. Our product managers know that the best ideas can come from very unexpected places. Anyone can meet with us and give us their opinion or write up an issue and ask us to look over it. As far as real stakeholders go, customers, sales, product leadership, and executives have the most influence over the roadmap. Engineering, UX design/research, and security are also incredibly important to listen to, since they have insight that other groups often lack. However, the only one who actually controls the roadmap at GitLab is the product manager. Every product manager is expected to be able to synthesize multiple inputs from multiple sources, apply a prioritization framework, and manage the roadmap themselves. There are special circumstances, like security vulnerabilities or infrastructure issues, that will always take precedence, but that is all accounted for in the framework. GitLab has always been a product-led company, so everyone understands the role and authority of the PM in setting the course of their area of the platform. I think that there are a couple of very important things to establish when setting expectations of influence vs. control. 1. The most important thing in allowing influence from stakeholders vs. direct control is that your company's policies support the PM as the directly responsible individual for the roadmap. * Company leadership needs to set the expectation that product owns the roadmap. If the product organization is not supported by company leadership as a whole, it is going to be very difficult for product managers to balance the expectations of influence over control. This is especially true in organizations where a specific group has historically had more influence in roadmap decisions. Sales or engineering heavy organizations that don't have explicit policies about product being fully in control of the roadmap will almost always run into the problem of someone else trying to control the roadmap. So, support from leadership is key to success in having a product-led roadmap. 2. The product organization needs to have transparent and explicit policies for how prioritization and roadmap decisions are made. * If other groups think that product is making decisions without a real plan, that will lead to distrust in the product org. Once trust is lost, other groups who believe that they have a better handle on what the company needs to succeed will try to exert control over the roadmap. The truth is that if there's no transparency about how product decisions are made and it seems like product is ignoring the real needs of the company's customers, who can blame them for trying to step up to make the company more successful? * Transparency with other groups needs to be a top priority if product managers want to gain trust. If they disagree with you, it gives them a chance to voice the reasons for their disagreement. When you have data that you can show them from your prioritization framework exercises to back up your decisions, you can show them why you believe your decision is correct. If, for example, sales is unhappy that the feature their top customer wants is not getting prioritized, you can show them the impact of the feature for the one customer vs. the feature you prioritized that has broad appeal to a lot of different customers, leading to greater (and less risky) recurring revenue. When you have leadership support, have an explicit process for making decisions, and are transparent about that process, it is easier to maintain a culture of collaborative influence. As long as everyone involved is going towards the same goal of making the company successful and solving problems for your customers (i.e. there are no power struggles happening solely for sake of gaining power), you can balance the expectations of influence and control through mutual trust.

Pivoting a product is typically a very difficult time for everyone involved. I feel for you! Depending on who has these expectations and the reasons why it is difficult to plan too far out (and what "too far out" means to you), there are several things that you can do. Some of them are pre-requisites before you actually try to set expectations. 1. Have a vision for where you want the product to go. * If you are pivoting, you need to know what you are pivoting to. If you don't have a vision for your product, setting expectations on what you communicate won't be worth much, since you won't really have anything to communicate. If you are struggling with this, how did you decide to work on the current items in progress? Even if it isn't written down, you likely have an idea of where you want to go. You may not know all the details, but you don't need details to have a vision. 2. Have a strategy for how you are going to achieve the vision. * This doesn't have to be specific items on a long-term roadmap, but, once you have a vision, you should begin piecing together the general idea of what will make your product successful. Plan the roadmap for the next quarter, keep talking to your customers, and do market research. Define the jobs to be done for your product. Figure out the broad strokes of what your users will need to be able to do with your product in order to reach your vision. * If there is something blocking your ability to know what needs to happen to achieve your vision, have a strategy for remedying that problem. Do you need more knowledge about the market? Does engineering need more experience with the technologies they are now required to work with? Come up with a plan to unblock the team's ability to execute on the vision. 3. Have a solid roadmap for the next quarter (or the next month, if quarterly planning is too ambitious for you right now). * Planning quarterly can be a great way to provide enough detail to satisfy expectations, while still allowing for adaptability. As the product manager, you and your design team should be working on the details for the next three months while engineering is executing on the current quarter's plan. This gives you enough time to solidify plans, while being flexible enough to react to customer feedback, changes in the market, or evolving business priorities. Once you have these things in place, you are ready to set expectations and communicate your roadmap. 1. Be transparent * Tell people your vision and strategy. Let them know that this is where you want to go, but the details past the next few months aren't completely clear yet. Let them know why it isn't clear and what you are doing to remedy the situation. If it is difficult to plan too far out because your engineering team has had enough experience with the features or technologies you are pivoting to, give them confidence that the team is working through the unknowns and that you will have a more solid plan soon. If it is difficult to plan too far out because you don't know the market you are pivoting to well enough yet, tell them what you are going to do to work towards gaining the knowledge that you lack. This is a temporary situation and everyone needs to know that. You can't be constantly pivoting your product or you'll never have something that is that useful to anyone. If the people you are talking to know that you are executing on a plan to address the challenges, they will be more willing to give you a bit more space to do what you need to do. 2. Schedule updates * If you can only communicate what you are going to do a quarter at a time, let your audience know when to expect the next update. For example, if you have a quarterly roadmap, schedule monthly updates. If you only know what the next month looks like, schedule weekly updates. Even if the next update is that you are still working on the same things and you aren't any closer to the details of the next roadmap item, at least people will have confidence that when something changes, they will know about it. You want to have frequent, consistent, transparent communication, even when nothing has changed. Frequent communications will ease minds that you have things under control. Of course, tailor your communication to your audience, as customers generally don't need to know as many details as executives do. But, giving these updates will let people know that you care enough about the situation and their being informed that you will take the time to communicate with them. 3. Solicit feedback * Involving people in the process can help them understand the difficulties you are facing. It also may make things a bit clearer to you, if they give you some good ideas. Moving from away from you talking at people to an inclusive discussion helps to give everyone a sense of involvement. If they understand the difficulties and are involved in helping to solve them, many people are more willing to give you a bit more leeway in how much you communicate. To reiterate, this shouldn't be a permanent situation. Bring your audience along with you for the journey, be open and transparent with them, but give them confidence that you have a vision and a strategy for moving forward. This should set expectations that they will know as much as you can possibly be confident about right now and that you will constantly be updating them as you get new knowledge or information.

Personally, I believe in having a very transparent roadmap. Not all companies are going to be able to communicate everything that is on their roadmap for legal and/or regulatory reasons, but, in my opinion, you should try to have as much of it public as possible. The main difference between an internal and external roadmap is that I would advise to never put exact dates on an external roadmap. If you have to put dates down, general timelines of this quarter, next quarter, this year, etc. are good enough to communicate what you are working on now, what you will be working on next, and where you'd like to go in then future. Also, always make sure to include a statement that things will change. Timelines, priorities, known vulnerabilities, and regulations can all change and impact your roadmap. Make sure that your customers know that you reserve the right to change things. Above all, be transparent when things change. Don't lead customers on if you know that the timeline has drifted and you won't be delivering the feature they want until next year. On your external roadmap, I think that it is prudent to include the following information: 1. What the feature is and isn't. * Be clear about what it will do when it is released. * State what problems the feature will address and how it will help your customers. 2. If necessary, general timelines of when you expect features to ship. 3. Dependencies on other work, especially if it is dependent on other teams. 4. If possible, for the features you are currently working on, include designs or wireframes to show what it will look like and how it will be used. 5. Forward looking statements acknowledging that things can change. * Be clear that nothing in your roadmap is a commitment, whether it is the timeline, functionality, or specific design. On an internal roadmap, I'd expect to see more details. 1. Work with engineering to determine an estimated timeline and work towards shipping the feature within that timeline. 2. Define engineering dependencies and capacity. * Externally, your customers don't care about who is working on the feature, but internally, you should be clear about who is critical path to releasing a feature, in case anything comes up that affects the capacity of those people. 3. Communicate the details when things change. * What caused the change? Technical dependencies? Bugs? Security issues? Marketing timelines? UX research? 4. Show how this feature contributes to the company's vision and goals. Of course, when you publish a public roadmap, you are going to have pushback. You are never going to have a roadmap that makes all of your customers happy. Different customers need different things. You should embrace the fact that you will get negative feedback from specific customers when you haven't prioritized what they want. Hear them out, value their input, explain why you are prioritizing the features on the roadmap, and use their input to make future decisions. Maybe there's something that you hadn't understood when prioritizing your roadmap and their input is what you needed to unlock the realization that their issue has broader impact than you had originally thought. The more people you have providing input, the more data you have. The more data you have, the better decisions you can make.

Since this question implies that there is already an existing product and customers that are using it, talk to your customers. Ask them what problems they have. Do research into the market you are in and see where the issues are with competitive products. Do what product managers do best! Understand the problems and customers, then create solutions. If leadership doesn't have a vision for where the product should go as an essential part of the company's vision, create one yourself. If you do have a vision, but you don't know what to prioritize, using a framework like the RICE scoring model will help you to figure out what needs to be done in what order to help achieve that vision. Expanding a bit more on if the issue in this case is prioritization of the roadmap, in my opinion, company leadership helps product managers the most by establishing a vision for the company as a whole. Coming up with a strategy and prioritizing features to fulfill the vision are essential parts of being a product manager. I believe that the C-suite is not there to make tactical decisions like that, you are. If you are relying on them to prioritize your roadmap, take the opportunity to learn strategies for prioritizing and make your own decisions. It will only help you in your future career. Back to the question of vision, if you are the product manager responsible for this product, you should already have an idea of what needs to happen to improve the quality of the product, expand the feature set to be more competitive, or solve new problems in the industry. It has been said that product managers are the CEOs of their product. I don't really agree with that, for several reasons; but, when it comes to creating a vision for where a product should go, there is definitely some similarity. You are the one who should be out there talking with people, reading industry news, going to conferences, and doing competitive intelligence. Engaged company leadership is usually going to make for a better product (although...this can also cause problems, depending on the company and the personalities in leadership), but take the initiative and come up with something for yourself while they are ramping up. If they want to learn (I sincerely hope they do!), you can also see if they would be open to meeting with you and your customers to learn more in a short period of time. As the PM, you are the subject matter expert and are in a unique position to help them understand the product, your industry, and your company's customers. Of course, whether they would be open to this is going to vary depending on the size of the company, the number of products, the number of customers for the product, etc. But, it's worth a try. If they don't, then you have a great opportunity to build your own skills creating a vision and strategy. Just remember to always use objective research and data as much as possible, not your own assumptions.

I think that the answer to this is: it depends. The specifics of how you go about introducing roadmapping, promote a product-based mindset, and establishing a consistent strategy for educating teams on product practices is going to depend on your organization, your industry, your leadership, and your customers. There are a lot of different strategies and frameworks out there that you can decide to adopt for your organization. However, I do think that there are some things that could be called "best practices" to help with deciding exactly what your product-led organization is going to look like. It is going to require a lot of thought, work, and transparent communication, but it is definitely doable. Here are some things that I think would help. 1. Understand the current state: 1. Conduct an assessment of the current project-based approach and existing practices. * Why was the org operating the way they were before? * What was the main motivation for deciding on which project the teams were going to work on? * Who had the most input into those decisions? 2. Identify pain points, gaps, and areas for improvement in the current processes. * Are there things that were working well or that only need a little tweak to improve? It isn't always necessary to completely throw out everything that is currently happening. 2. Establish the Why: 1. Why is it important for your company, specifically, to move towards a product-led roadmap process? * Answering this question is going to be key to getting people on-board with the mindset. Saying that you are moving to a product-led roadmap without establishing why it is necessary for the future success of the company will only look like you are trying to build your empire within the organization. Without the why, it will be incredibly difficult to bring people along with you in the journey of transforming your org. 3. Define a product vision and strategy: 1. Clearly articulate the organization's product vision and strategy to align teams towards common goals. 2. Communicate the importance of transitioning from a project-based mindset to a product-led approach. 4. Educate teams on product mindset: 1. Conduct training sessions to educate teams about the fundamentals of product management. 1. Define what PMs are responsible for and why. If you are taking responsibility and authority away from other roles and giving it to PMs as a part of this transformation, make sure they understand the reasons for it and why it will help the company as a whole. 2. Emphasize the shift from project-based thinking to a continuous product lifecycle mindset and why it is necessary for the company's success. 5. Establish a common product language: 1. Develop and disseminate a glossary of product management terms and definitions to ensure a shared understanding across teams. * GitLab's product handbook is an excellent example of this. Teams can't have consistency if there is no single source of truth of how things are done. There can still be flexibility within some of the specifics, but the broad terms and definitions need to be agreed on by all the teams. 2. Use consistent terminology in communication to minimize confusion. 6. Create a standardized roadmap framework: 1. Design a roadmap framework that aligns with the organization's product strategy. 2. Clearly define key components such as themes, initiatives, milestones, and dependencies. 7. Customize roadmap templates for individual teams: 1. Tailor roadmap templates for different teams or product lines while maintaining a standardized structure. 2. Allow teams the flexibility to include specific details relevant to their products. 8. Implement roadmap review and alignment sessions: 1. Conduct regular roadmap review sessions to ensure alignment with the overall product strategy. 2. Provide a platform for teams to share their roadmaps, discuss dependencies, and identify potential conflicts. 9. Foster cross-functional collaboration: 1. Encourage collaboration between product managers, designers, engineers, and other relevant stakeholders. * Emphasize transparent and inclusive communication. Everyone has good ideas. Everyone has bad ideas (even PMs!). No one is perfect and everyone should be comfortable admitting when they have made a mistake. Establishing a shared set of values (like GitLab's values) can ensure that everyone has a shared framework for understanding how communication should happen. 2. Facilitate cross-functional workshops to build a shared understanding of product priorities and challenges. 10. Integrate feedback loops: 1. Establish mechanisms for continuous feedback on roadmaps and product priorities. * Talk with your customers! Don't rely on only on sales to let you know what customers are saying. Sales has a great idea of what their specific customers need, so you should always listen to what they are saying, but you should talk with the customers yourself. This is especially true if your product spans multiple industries and verticals. Sales will almost always promote what their customers need the most and don't always have insight into how you can evolve your product to meet needs for customers in multiple areas. 2. Iterate on the roadmap based on real-world feedback and evolving business needs. 11. Celebrate success stories: 1. Showcase success stories resulting from the adoption of product management practices. 2. Highlight instances where the product approach led to positive outcomes, reinforcing the value of the transformation. 12. Provide ongoing support and training: 1. Offer continuous support through mentorship, coaching, and additional training as needed. 2. Address any challenges or resistance promptly and adapt the roadmap and practices accordingly. * Listen to what people in your org are saying. Even if you don't agree with what they are saying, try to find a way to make them feel heard, answer their concerns or issues, and include them in the process. They are a part of your organization and deserve to be heard and understood. A lot of times, hearing an opposing point of view can help you refine your process. 13. Measure and iterate: 1. Define key performance indicators (KPIs) to measure the effectiveness of the product management practices. 2. Regularly review metrics and iterate on the roadmap and processes based on lessons learned. * Always use objective research and data. When you are questioned on why certain features have been prioritized or why the roadmap looks like it does, you have actual data to back it up. It's hard to argue with data and numbers...although people try to do it all the time. In the end, introducing a product management-led roadmap process and getting everyone on-board with a product mindset is about a lot more than just saying that PMs now make roadmap decisions. There has to be a reason for it, you have to be transparent about what is working and what isn't, you have to be inclusive to make sure that everyone feels like they have a chance to contribute, you have to be willing to iterate when improvements can be made, and you have to have data to back it all up. It is a lot of work, but it is absolutely worth it.

Moving items in priority on the roadmap is going to happen. This is especially true if you are required to have a long-term roadmap. However, even with short-term roadmaps, it will happen. While I don't know the exact reasons why your company requires you to write long docs and create decks to explain this, I believe that the general intent is probably to make sure that everyone knows why things moved, what the impact is, and how it will help the company as a whole. I think that there are a few things that you can do to help alleviate the pain product managers in your company are experiencing. 1. Make prioritization decisions based on data as much as possible. 1. If you are making decisions based on gut instincts, it is going to be extremely hard to communicate and defend your decisions. 2. Use some sort of prioritization framework for deciding what to prioritize when planning your roadmap. This will help to minimize how often this happens to your roadmap. When it does inevitably happen, though, you will have the framework to use as a defense. Personally, I like to use the RICE model. It allows you to efficiently and effectively show why you prioritize certain things. But, find something that works for you and your company, but shows exactly why you are making the decisions. 2. Create a template for the collateral you need to produce. * Using the information you are required to document and present, have a standard doc and presentation template that all PMs use. This should save you a lot of time by only needing to fill in the justifications, rather than making each product manager come up with it on their own. Of course, the exact structure is going to depend on what you are required to explain, but my suggestion would be to include the following sections: 1. What is the decision that was made? * Be brief and specific. "We have moved X feature out by X months in order to prioritize development on Y feature." 2. Why was the decision made? * Be clear on what made you moved things around. "After conducting more research on the impact of the two features, we came to the conclusion that Y feature will have a greater impact on ARR if we can deliver it sooner. Here's why." * Establish your goal in making the decision. You are all in the same company, executing on the same vision, and wanting the same outcome (for your company to be successful). How does your decision support the vision of the company? * Provide the data you used to make the decision. Show why prioritizing the new feature will be best for the company. Whether the reason is ARR, a new regulation, a security vulnerability, a shift in the market, a new competitor's feature, etc., you will be able to defend your decision. Be transparent, even with customers (as much as is legally allowed). 3. What is the impact of the decision? * Show that you understand what the change means to your company and customers. You didn't make the decision in a vaccuum (I hope), so you should be very aware that some customers were relying on the feature that you moved further out on your roadmap. Be empathetic to what this means to them, the sales people in your company, and the marketing and executive teams that may have been promoting the upcoming feature. 4. What is the new timeline for the feature you moved out? * Make sure that everyone understands that if you moved the feature out, you are still planning on implementing it. If you removed the feature from the roadmap completely, make sure to be very specific about why you removed it. 3. Document decisions as you go. * You should already have the work you did with the prioritization framework. That is your main supporting work for your decision. * Figure out the new timeline for the feature you moved out and make sure that is documented somewhere before the decision is final. Again, I don't know any of the specifics for your company or the cases that happen there, so I hope that some of this will help out with efficiently communicating your decision. However, in my opinion, if you do all of this, none of the information needed in the doc or presentation should take you very long to produce. If you made your decision based on data, most of your work has already been done. At that point, it is down to getting the information communicated in a format that is acceptable for your company. Having an established template for presenting that information should help with the time it takes to create the collateral.