Sirisha m

“Data depth” is a core competency for any PM and unlocks “data informed’ strategy. However, how much data analysis a PM will need to do will depend on the maturity of the organization & available resourcing. At the core, every PM must know where the data is logged and in what format. 1. In organizations, where there is an organization wide data platform that democratizes data access & there are analysts on the teams, every PM should still be trained on using this platform and run lightweight queries. ‘Knowing your data’ helps the PM ask the right questions to the analyst and prevent being stuck in ‘analysis paralysis’. Data empowered PMs are also able to leverage their data analysts for more strategic thinking rather than mundane daily reports. 2. In organizations where there are no dedicated analysts, PMs can try self serving with data but for complex scenarios, if the PM is being pulled away from defining the “what” (data is only 1 aspect of identifying the aspect), then I would encourage the PM to share the need to find someone with that skillset in the organization or raise the staffing constraint to their leadership. This doesn’t have to be a dedicated analyst but at the least a shared pool of analysts. All of the above assumes that the required amount of data is available in a centralized data platform with an ability to query the data. If this doesn’t exist, I would say start with building such a data platform first.

Prioritization is a key PM competency. When there are constraints you need to deal with, “ruthless prioritization” becomes even more important. Some guiding principles to keep in mind when balancing with limited resources: 1. For any investment you are making, articulating “the why” and “why now” is an important exercise to drive confidence in your investments & timelines around them. This will help select the right priorities at the right time. 2. Always have a stack ranked list of OKRs and projects that map to these OKRs. When constraints come up, an already stacked ranked list will help drive funding towards the most important projects. This ranking should be made on all levels of product leadership - from head of product to an IC PM. 3. Keep your stakeholders informed when resourcing constraints arise and the impact it will have on the roadmap. Lack of transparency on changes in resourcing can very quickly break the trust equation with your stakeholders.

“Managing up” is core to being a successful PM given how front and centre product development is for a business to grow. “Communication with the right level of detail” is key to making these communications meaningful. When communicating, expectations need to be set both in terms of projects in flight as well as new opportunity areas as they surface up. For projects in execution: 1. A progress check in in how the committed projects are progressing - this can be a monthly discussion forum so there is an opportunity to discuss open questions (avoid making this is a FYI meeting, rather create space for discussion) or a newsletter of sorts sent out on a bi-weekly/monthly cadence across your product portfolio for offline reading. 2. If it is mainly to keep one person updated, have a running document of updates so that the/she can refer to as needed. When it comes to new opportunities, some guiding principals when engaging with your leadership: 1. Once you have something meaningful to share along with a open question or an approval from your manager, schedule a “discussion” time with your leadership. 2. As an IC PM, target having these periodically throughout the year or at the least, for large initiatives leading to your planning cycles. These help evangelize your concepts with your leadership.

Success metrics should be front and center of every conversation from the get go. Success metric is what I would refer to as ‘impact number’ or key results in an OKR. When defining the "why" behind every opportunity, a PM should identify the impact first. This impact helps not only drive prioritization but should also be used by development teams to understand the impact that their work has on the business and users. So my recommendation is that there is not a good time to talk about these metrics but every conversation should start with these metrics.

QA should always be an ongoing effort and be treated as a team effort. There might be spikes in QA efforts based on the complexity of the project but it should never be treated as 1 person responsibility. 1. Engineering is the first line of defense with unit testing. 2. Having a test environment where integrated end-to-end testing can be done is crucial for any development team. 3. PM + Design + EM should periodically be in the test environment testing an integrated experience. 4. For complex products, there sometimes might be an end to end usability testing team but by the time this team starts testing the product, trivial bugs must have already been identified and fixed via activities #1 and #2 listed above. 1. “Testing party” is another forum that is worth organizing for complex rollouts or more 0->1. Think of this as a dedicated testing room/slot and include non-development teams (e.g., business, customer success etc.) and sometimes stakeholders/early customer groups as well. 5. Additionally, creating a QA metric such as number of post launch bugs can also help drive accountability & quality as a development culture. For a small team, make QA a culture rather than a process to enable quality products being “shipped at desirable velocity”.

Engineering should be part of your planning journey and not be brought in only when scoping. Couple of ways to driving the understanding to your engineering team: 1. Throughout the year, create a forum to discuss new opportunities with your engineering as you discover them. This will make sure nothing is a surprise when planning comes by. This also helps engineering start the thinking around engineering requirements sooner than later. 2. When planning activities begin, I would strongly suggest at the least, a 1-pager on the what & why that you can have engineering use to help with scoping. Written communications always drive alignment faster. If you have talked about this with the team earlier, the 1-pager should throw no surprises but will unlock further discussion needed for scoping. 3. When drafting a PRD, have your engineering sign off as an approver on completion of PRD, which also drives accountability and clear handoff on the scope of work. 

Let’s break this down into 2 workstreams - 1) how to create the complete opportunity space & 2) the process to select the right opportunities to go after. 1. Creating the opportunity space - Assessing problems always starts with customers/users. As a PM, always factor time week over week to shadow/talk to your customers. If you have a user researcher on your team, they are your partner to start with. Also, problem identification can come from anywhere in the organization - as a PM, you should create channels/forums for the organization to surface these ideas e.g., weekly discussion brown bag sessions with engineering/design. When you have the right partners involved upfront in helping build the complete landscape, you are set up to drive bigger outcomes. 2. Picking the right ones - The right ones can be picked up based on different scenarios: * For qualitative insights, lean on voice of the customer insights such as inbound support tickets, account management team. B2B products leans on this methodology predominantly. * For quantitative insights, work closely with your data analysts. B2C products generate stat sig data and hence quantitative insights can be leveraged. * There might be top down priorities that dictate your roadmap e.g., your company decides to enter a new market in which case the problem you choose will be about unlocking this new market. * Roadmaps can also be driven by mandatory legal & compliance requirements. E..g., EU is making a change to their data proivay guidelines, which means you have to update your product portfolio in a given timeline to adhere to the new guidelines.

Making any discussion data driven helps drive meaningful outcomes. Start with understanding why a different team thinks they own the decision, which helps with your conversation. Given decisions lead to outcomes and hence impact KPIs, leveraging that correlation helps with alignment. Clarifying who owns the KPI, which is impacted by the decision helps identify ownership quickly. Once alignment is reached, always make sure to capture the decision/engagement model as a written artifact for future reference.

When you are stuck between the disagreement of 2 executives, there is no prescriptive playbook to help resolve this since the solution depends on the people involved, the phase of the company and the complexity of the problem. Some guiding principles to adopt to resolve the gridlock would be: 1. Take time to understand the “why” behind the respective leader's feedback. 2. Add as much context and data on your preferred approach as you can and document everything in written format to drive discussion. 3. Avoid emails for discussion and use synchronous conversations to resolve. 4. If there are other people who can help with reaching an agreement, get their support/feedback. 5. Explore if there is a middle ground strategy that might drive alignment.

As a PM, you are always “influencing without authority”. The main factor that helps with influencing is identifying shared goals. Once you have shared goals, the discussion is on even ground. The shared goals could be KPIs around a project or around completion of a job. If there are no obvious shared goals, then make time to understand create one. Ability to connect the impact of the feedback to these goals creates quick action.