Great question. It's really hard to prioritize small, iterative product improvements against large new features/bets. In my experience you need both, as well as a few other aspects. The way we do it in my teams is to think of it as balancing investment levels between different buckets, and to dedicate capacity to each of these buckets. Otherwise it's a constant struggle. We've tried to describe it in this section of the Atlassian product discovery handbook talking about ideas, and that one about prioritization. A couple of different types of buckets: * Boulders, rocks and pebbles * Boulders: large investments with potentially big payoff but high uncertainty, too. E.g. one or multiple teams over one or multiple quarters. * Rocks: medium sized investments with fewer risks, but potential for delighting users. E.g. one team for a month. * Pebbles: Small, typically straightforward change. E.g. one person for a week. * Don't underestimate the impact of rocks and pebbles! In my experience users LOVE to see the app they use get better every time, that's a great way to create fans. * RUF: Reliability + Usability improvements + new Features. Think of the RUF framework as a pyramid: * At the base of the pyramid there's Reliability. Reliability is about building trust. Trust takes a long time to build, but can be destroyed very quickly — a single event of data loss or security breach can be a serious source of churn, let alone repeat incidents. So you need to invest in your product's reliability first and foremost. * Usability Improvements comes second: a feature is rarely “done” — it’s part of a system and that system needs constant tuning. In your roadmap, it is important to allocate budget and resources to keep investing in improving your current feature set. * At the top of the pyramid is new features, both large and small. Then you decide how you want to invest in each: E.g. for a super early stage app you might be spending all your time on boulders and rocks, and little in reliability or usability improvements. For a more mature product you might spend 50% in the reliability bucket and only 10-20% on new features. Then how you actually implement that in your team can vary. In my teams we look at it at investment over time: we might be focusing on a boulder for a quarter, then go back and tackle a few rocks and pebbles. Some of the teams have a rotation where 1 engineer is focusing on pebbles each week. etc. But the important part is to have a strategy and make it a conscious choice, vs something that you react to every time you get a new request from a customer or stakeholder.

In my opinion, building influence with your engineering team boils down to these 3 things 1. Understanding engineering complexity even if don't quite grasp all the details eg. do you understand the cost (experience implications, impact to future team velocity etc.) of having tech debt when you ask your engineering team take short cuts? 2. Being able to represent the engineering considerations in forums where your engineering team is not present eg. discussions with the sales team where they ask for specific delivery dates features on the roadmap. 3. Empowering the engineering team to understand the product context and take shared ownership for outcomes rather than just being a delivery team. A good litmus test for this is to assess how comfortable your engineering team feels about making product decisions and keep making progress when you are on leave. If you invest time and effort in doing these 3 things, you will build significant trust and influence with your engineering team.

Of course they do! It's always a balance between those two sides. Mixing personal contributions with coaching other product managers can create tension if you’re not mindful. Setting clear boundaries around your schedule, defining what success looks like for both you and your team, and communicating these goals openly helps manage these two aspects. Things to Think About 1. Dedicated Coaching Time: I try and dedicate time each week to ensure my team is getting what they need and that I am providing them the opportunities to grow and gain exposure (to new skills, new teams, etc). If the team feels disconnected from their leadership, it's difficult to motivate them and keep them moving forward. 2. Defining Ownership: Whenever possible, I clarify what parts of the product I’m responsible for and what the team needs to own. When PMs clearly know what’s theirs to drive, it reduces the urge for me to dive in and micromanage. We play to our strengths, which allows me to contribute where I add unique value (eg: shaping high-level strategy or unblocking critical issues) while allowing each team member to do the same in their areas. 3. Regular Reflection: Every week and month, I reflect on where I’ve been spending my time. Did I neglect my direct product work because I was too hands-on with the team? Then I need to adjust next week. It's a constant balancing act. As I said, I work to carve out space, define ownership and teach PMs to solve problems independently, All of these ensure that your individual contributions and coaching efforts reinforce each other rather than work against each other. Over time, your team grows, and you free yourself to have a broader, more strategic impact.

I currently work in the intersection of enterprise security & AI and it is incredible to see the use cases that have emerged for AI in this space. * User research: As I mentioned in one of the earlier questions, AI tools can be a fantastic source to understand user trends, market, and competitive trends. For example, you can take a look at online user reviews for your product to understand key functionalities and usability gaps. * Product functionality: Within security SaaS we often use the framework of detect, investigate, and resolve. AI is changing each of these experiences from a product development perspective. For example within ‘detect’ AI is enabling us to develop product experiences which help organizations more proactively understand attacks their orgs are more vulnerable to. Leveraging machine learning and external data sources we can provide scores to attacks to help understand how significant a vulnerability truly is. Within remediation AI helps to develop automated playbooks based on other similar playbooks that can help users more quickly resolve issues and get external data about how other orgs are resolving the issue. * AI experiences: In addition to augmenting the security workflow to make it more productive and effective, gen AI is also enabling us to create net new experiences for prospects and customers. For example if an organization doesn’t have the security skillset to complete one of the tasks across detect/investigate/resolve - what is the role AI could play here in filling the gap? How can AI be leveraged to empower shift left security in an organization so that developers are encouraged to incorporate security from the get go in their designs? There is so much potential for how AI can fundamentally change the product development process and excited to see all the innovation organizations bring to their products over the next two years.

Market trends can be a good indicator of what will matter to users, investors or stakeholders. Don't ignore them, but also don't let them distract you from the fundamentals. * Do you think this trend will drive a permanent shift in the market you operate in? If so -- consider how you can position yourself for success in the long term and the pros / cons of investing in alignment. If not, consider whether there are short / mid term changes you want to make to take advantage, or whether you just want to ride it out. * Identify where the trend is coming from. Is it driven by macroeconomics? A technological innovation? And are you and your org well positioned to take advantage of it? * Are you moving early enough vs other competitors? If you have an opportunity to be out in front of the crowd -- can you position yourself as a leader in this trend and drive marketing value from doing so? * Does it genuinely drive economic advantage for you, either directly or by second order effects?

Using a clear, published framework that aligns to the organizations broader goals or strategy is important to prioritizing any set of work. Without this, it will be difficult to build confidence with your team that decisions will hold up and they won’t have the context required to make sound decisions in their execution of the tasks they are assigned. A prioritization framework doesn’t need to be complicated - in fact its often better if its so simple that it can be committed to memory. In many cases the best discussions I’ve had with my leaders focus on aligning on the prioritization framework over a whiteboard, with the output often being a simple bullet list or table calling out the characteristics of projects that will fall into each bucket. It’s also advisable to test your prioritization framework by running a few examples of actual work items and seeing if the team leads align on how the framework is applied and the priority outcomes for each. Setting the framework is usually simplistic when running a small team with clear goals or OKRs, as those can easily map directly to the priority framework you define for the team. As you take on more strategic roles where there are difficult calls to make balancing resources across competing priorities, I’ve found that the “Core Context” model by Geoffrey Moore helps me form my first cut at a priority framework for delivering on that strategy. 

PMs are able to help engineers with: * talking to all different types of customers and prospects, so that we constantly have informed/holistic insights into most impactful problems we should be solving for our target customer * taking the set of problems we have to solve, strategically sequencing them (roadmap), and pitching this to leaders internally to ensure buy-in + resources to fund this work * take the lead on solutioning - working with engineering, product design, content design, user research, and data science - to ensure that we are building a feasible/impactful solution for the right problem * evangelising the products that we are building and collaborating with GTM stakeholders (Customer Success, Account Executives, Solutions Consultations), pricing teams, business development, legal, product marketing - so that the product is not only built, but well-loved and highly adopted by our customers * and so many more things Engineering leaders could drive all of that, and they are capable to. But oftentimes they are focused on managing large organizations of engineering staff and driving technical/architectural vision. And good PMs have years of experience and training on this work specifically, as opposed to having to focus on people management.

1. I like to start with the product stage, context, and strategy. From these, and your customer data you should be able to determine your priorities * With an early stage, pre-PMF product, you may be prioritizing learning about your customer needs and how well your product is meeting those needs above all else. * When you know your product is meeting some people’s needs or providing some valued entertainment, you can focus primarily on increasing engagement and retention. How can you make your product better in ways that result in longer user sessions, more repeated user sessions? * When your retention curves look good for 30+ days (and ideally 90+ days), it may be time to focus more on growth. 2. You may have a more complex product though. E.g. one with a creator or developer or seller ecosystem and a 2-sided marketplace dynamic. * In these cases, you should be aligned on a strategy that includes sequencing (e.g. how are you getting high quality content to begin with in order to engage consumers? Or, how can you increase awareness and users enough to become an attractive marketplace for producers?) 3. Funnels also make great lenses. * New user acquisition (by channel and campaign, and the UX flow for each) * Retention over time * Conversion or upsell funnels * Social growth (if any) 4. Things like speed of learning, speed of improvement, and iteration velocity also matter to winning in the long run. So you may need to think this through as well. * Example: Is your tech debt getting so high that you’re wasting a ton of time dealing with regressions? Is this driving customers away or leading to low review scores?

You should try to split your stakeholders into two categories: * Primary Stakeholders - The ones which will be directly benefit or impacted by your work. These should not just be your customers who will use the product, but also the teams who will help get this work to the finish line, upper management who need to report this work to higher above. Primary stakeholders can be of various functions - PMs, eng partners, user researchers, design, PMM, leadership * Secondary Stakeholders - These are the ones who will be indirectly impacted by your product. The teams who are at the tailend of the consumption pipeline of your product. How to decide if something should land on the roadmap - There are a few factors you should consider while building a roadmap: 1. Business impact - How much value it is delivering to the business. How does it map to the top level business objectives and key results 2. Level of effort - Sometime the feasibility and level of effort can help you make a decision 3. Tactical Vs Strategic - Sometimes tactical work is throwaway work in the long term, sometime it's not. You need to gauge that and decide accordingly If you want to use a framework for prioritization, I would recommend RICE - reach, impact, confidence and effort.

Generally, the most logical approach is to divide up KPIs according to the user journey, and reserve a few top-level KPIs as shared KPIs. For instance, a generic user journey looks something like: Awareness of the feature -> Understanding its value/use-case -> First Use of the feature -> Repeated use -> Advocacy. In this case, Product marketing would own Awareness and Understanding, and Product would own First Use and Repeated Use, and you may both own Advocacy. Breaking that down further, it might look something like this: * Top level KPIs (shared): * Feature adoption rate * Feature-driven revenue * Feature impact on NPS * User-feedback / sentiment * Product Marketing KPIs: * Email campaign engagement rates * Landing page visits * Documentation/guide views * Feature announcement engagement * Product Management KPIs: * First-time feature usage rate * Time to first use * Repeat usage / Feature Retention Rate * Technical Performance Metrics The key here is that there are some very clear boundaries for ownership, but also to consider that you are a team with the same goal. If you are launching a new feature or just trying to drive adoption of an existing feature, its important that you spend time to establish the shared and individual goals to make sure everyone is pushing in the same direction.