Derek Ferguson

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.

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.

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.

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.

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.

This question is very similar to the question about knowing that your strategy is successful, but I’m going to look at them through two different lenses. For this question, I’m going to look at it as a strategy for a new product that hasn’t been introduced yet, you have no active users, and you want to figure out if your strategy is the right one before you launch. To validate a strategy in this situation, the approach has to be proactive and thorough. The goal is to ensure that when you deliver the product to users, it gains traction and starts building your user base right from the get-go. Here’s how I approach it: * Market research and user persona development: Before anything else, deep market research is critical. Understand the market landscape, identify gaps, and pinpoint the needs that your product aims to fulfill. Develop detailed user personas to represent your target audience. Knowing who you’re building for and their specific pain points helps tailor your strategy to meet real needs. Writing jobs to be done (JTBD) is a great way to distill what you've learned. * Problem-solution fit: Validate the problem-solution fit early. Engage with potential users through surveys, interviews, and focus groups. Present them with your product concept and see if it resonates. Does your solution address their pain points effectively? Are they excited about the prospect of your product? This feedback is essential to refine your strategy before you even write a line of code. * Competitive analysis: Conduct a thorough competitive analysis. Understand what similar products are doing well and where they fall short. Identify your unique value proposition—what sets your product apart? This differentiation is key to attracting users in a crowded market. * Pre-launch campaigns: Depending on the product and market, run pre-launch campaigns to generate buzz and gather initial interest. Create landing pages, run social media ads, and engage in content marketing to build an email list of interested users. Measure the engagement levels and adjust your messaging based on what resonates most with your audience. * Pilot programs and user testing: If possible, run pilot programs with a select group of users from your target market. This can be done through partnerships or exclusive invites. You don’t actually need to have a real product to show them—wireframes and designs can be enough, at this stage. Collect feedback on their experience, what they love, and what could be improved. Iterate on this feedback to fine-tune your product. * Metrics and KPIs: Establish clear metrics and KPIs to track from day one. These might include sign-up rates, engagement metrics, conversion rates, and feedback scores. Thinking through these before you start to build helps you to focus on what you believe will make your product successful. Once you do have something available for customers to actually use, having these metrics in place helps you measure the initial traction and adjust your strategy based on real-world data. * Minimum Viable Product (MVP) testing: Once you have a good understanding from all of the above, build an MVP to test your assumptions. The MVP should have just enough features to solve the core problem for your target users. Release this to a small group of early adopters or beta testers. Their usage and feedback will provide great insights into what works and what doesn’t, allowing you to make necessary adjustments. * Feedback loops: Create robust feedback loops to continuously gather user insights. Use tools like surveys, in-app feedback, and user interviews to keep a pulse on how new users are interacting with your product and what their pain points are. This ongoing feedback is crucial for making iterative improvements. * Alignment with business goals: This is the same as when you have a product that already has usage. Ensure that your product strategy aligns with your broader business goals. This involves regular check-ins with stakeholders to confirm that your product direction supports overall business objectives. Misalignment can lead to strategic drift, where your product might be developing well, but not in a way that supports the company’s long-term goals. In the end, validating a product strategy for a new product involves a mix of thorough research, proactive user engagement, iterative testing, and continuous feedback. Ensure that your product resonates with its target audience. All of these things will help you build confidence that your strategy will enable you to gain traction and grow your user base effectively once you launch.

This is a great question. Part of it depends on where you are in your career as a PM. It's hard to practice if you aren't given opportunities to contribute to the strategy in your daily job. But, in general, developing your skills here is an ongoing journey that involves practical experience, active learning, mentorship, and community engagement. Here’s how I approach it: * Practice and experience: The most important thing is to keep practicing. Constantly evaluate opportunities, listen to feedback, adjust your roadmap, talk to customers, analyze market data, and conduct competitive analysis. Push yourself to find information that isn’t easily accessible. This hands-on experience is invaluable. If you make a bad decision, learn from it and move on. Don't get stuck and feel like you've failed. Every PM has made bad strategic calls in their career, so file it away and get back on track. * Market engagement: Stay deeply engaged with your specific market. Don’t just rely on your sales team to bring customer insights to you. Attend meetups, conferences, and industry events. Ask questions and listen to the challenges and needs of your target audience. This direct engagement keeps you grounded in the realities of the market. The more you know, the easier it is to evaluate opportunities and develop the right strategy. * Mentorship: Find a mentor who has more experience in product management. Run your strategies and ideas by them and ask for their insights. When they suggest changes, ask why until you fully understand their reasoning. And don’t just take their word for it—validate their advice with data and see how it applies to your situation. I don't know a single good mentor who hates their mentee asking more questions and bringing more data to the table. * Educational resources: Invest time in reading books and attending courses. These resources can provide you with a strong theoretical foundation and expose you to different perspectives and strategies. However, remember that real-world application is key. The examples and exercises in courses can only go so far—you need to apply what you learn to truly understand it. Personally, I found the Pragmatic Institute’s courses and becoming a Certified Product Owner very helpful, but they were just the beginning of my learning journey. These things are especially important if you are just getting started as a PM. * Community involvement: Join a product management community. Ask questions on Sharebird. Find a group on LinkedIn that you can bounce ideas around in. Platforms like these can be great places to ask questions, share experiences, and learn from others. If you’ve taken any courses, see if the organization has an alumni group or message board. The more you interact with other PMs, the more you can learn from their successes and mistakes. * Financial responsibility: If you get the chance, take on responsibilities related to managing P&L or budgets. There’s no faster way to learn than when you’re directly responsible for the financial outcomes of your decisions. Being responsible for and truly understanding the financial implications of your strategy is an amazing way to ensure you are making informed, impactful decisions. No one wants to be irresponsible with someone else's money. While I'm sure that there are things that I've missed here, doing these will help you to continually refine and improve your product strategy skills. Remember, it’s a never-ending process of learning, adapting, and applying new knowledge. Stay curious, stay engaged, and never stop pushing yourself to grow.

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.

New ideas can come from anywhere, but the best ones usually emerge from those who truly understand the challenges within a specific space and are constantly listening to the people experiencing these problems daily. Apart from product managers talking with customers, I've seen great ideas come from engineering, design, sales, and executives. Conferences and user group meetups are also fertile grounds for new ideas. Customer advisory boards are amazing sources of great ideas, as these customers are so invested in your product that they are willing to meet with you on a regular basis to give feedback. Honestly, I’ve rarely encountered an industry where good ideas are lacking. If you’re willing to listen and humble enough to acknowledge that you might not always have the next great idea, you’ll find them. The real challenge is deciding which ideas to pursue. This is where decisions matter most. There are many prioritization strategies out there. I often use the RICE framework (Reach, Impact, Confidence, Effort) and modify it to fit whatever product I'm working on. But, even after I massage it for my needs, it doesn’t always capture all of the necessary details to cover everything. You need to consider your business, customers, market, and team. Aligning ideas with your company’s vision is crucial. Sometimes, a great idea might not align with the company’s direction, so you need to drop it. Other times, a feature requested by a single but major customer might be worth prioritizing due to its significant impact on your business, despite its limited reach. No single framework fits all situations. There isn’t a one-size-fits-all answer. It's important to test each idea against your vision, business strategy, customer interest, and delivery capabilities. Over time, the most impactful ideas will rise to the top. One word of caution: be very careful not to overemphasize the most recent customer feedback; all ideas should be evaluated objectively. Recency bias is a real thing and should be avoided at all costs. Remember, all reasonable ideas are valid initially. Keep them equal in your mind until tested and let the ones with the best outcomes win.

Balancing this is a delicate act that requires constant reassessment and a strategic approach. It's essential to recognize that both competitive differentiation and customer retention are critical to a product's success. Differentiation makes you stand out in the market, attracting new customers, while retention ensures that your existing customers stay satisfied and loyal. One approach I use is a cyclical evaluation process. Every month, I reassess priorities to see if anything has shifted. This means regularly checking if new information or changes in market conditions should alter our focus. It also means checking in with strategic customers to ensure that their priorities are still the same. For less mature products, it can be difficult to differentiate when there are table-stakes features that aren't implemented. Definitely not impossible, but difficult. In these situations, it's important to focus on features that deliver the highest ROI and have the broadest appeal. These features might not always be differentiators, but they are essential to build a solid foundation. However, even at this stage, I believe that you should allocate some resources to developing innovative features that set you apart in the market. In more mature products, the balance might shift. A significant portion of your development efforts can then focus on differentiation. These could be features that only apply to a small number of current customers, but grow your ability to reach new customers. Still, customer retention should never be neglected. For the more mature products, here’s a practical breakdown (the actual numbers are going to be different for everyone): if 15% of your sprint is dedicated to maintenance and tech debt, and 20% to bugs, you have 65% left for new feature work. How you split this remaining time between retention and differentiation depends on your current priorities and business needs. For example, if you have a groundbreaking new feature that could dramatically increase your ARR by expanding your total addressable market, it might be worth dedicating 50% (or more) of your sprint to it, leaving 15% for retention-focused features. On the other hand, if customer satisfaction is slipping because you haven’t delivered on requested features, you might flip those numbers to ensure you keep your current users happy. However, it's important to always keep some capacity for innovation. Make sure part of your iteration is dedicated to differentiating your product. Plan for this in your sprints, even if it’s just at the proof-of-concept or validation stages. Think of this balance like balancing spinning plates while standing on a board balanced on a pipe—it's a constant struggle, with the ground always shifting beneath you. But with careful planning and continuous reassessment, you can maintain that balance. It might shift one way one month and a different way the next month, but you can do it. Keep evaluating your strategy regularly. Align your feature development with your company's vision and current needs. By balancing short-term customer retention with long-term differentiation, you can ensure your product not only stays relevant but also leads the market. And remember, never get too comfortable—flexibility and constant reassessment are your best tools in maintaining this balance.