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.

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.

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.

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. 

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”.

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.

The areas that junior PMs struggle with the most when working with leadership are: 1) communication - An IC PM is in the weeds of their specific charter but not the executive. When asked a question, keeping the response to the right level of verbosity and the right depth is where most junior PMs struggle. 2) Balance between self-reliance and escalation - Many times, when a junior PM is blocked, they either raise concerns too early too often or express concerns in the wrong forums. This can very quickly create noise for the executives losing trust in the ability of the PM to execute.