Ojus Padston

The key mistake new PMs make is focusing on delivering over impact. It is inevitable that PMs hit a point where the backlog runs dry. The instinct in this moment is to panic to get something ready for dev, push forward the first idea that jumps to mind. The problem is this reduces the level of rigor, making it likely the work will not have sufficient reach or impact to matter. It also increases execution risk, increasing the likelihood specs are incomplete and engineering has to work with partial requirements, like building without design, that result in rework. In the panic to get this new feature out the door, the PM likely won't have time to build a proper backlog and be in the same spot a sprint later. Instead, the PM needs to take the painful step of admitting fault and chart a sustainable path forward. They can follow my process in a different question for building a roadmap. Knowing that process will take time, the key is being clear with engineering and product leadership on the process and rough timeline, so that the team can be best utilized while the backlog is being built. This also creates an opportunity for individual engineers to see the backlog building process from scratch, giving them higher confidence and motivation when the work is dev ready. I should call out that it is not just new PMs who make this mistake. I've made it myself many times in my career, so I know it is much more easily said than done.

These 3 principles are presented in rank order, because each one only matters if the ones above it are following 1. Empowerment - Everyone on the team feels ownership, understanding the problem space and context to really make an impact. Without empowerment, the team will inevitably be risk-averse or overly deferential, which is the opposite of the motivated, go-getter attitude needed. This can occur either because the team is not staffed or scoped appropriately, limiting what bets they are able to take, or management is overbearing and doesn’t cultivate independent thinking. 2. Rigor - Bets are thoughtfully taken, informed by data and strategic thinking into crisp hypothesis. They develop end-to-end solutions, thinking through the entire relevant customer experience. For a new feature, this spans presenting information to customers contextually in a compelling framing, providing easy actions that minimize cognitive load, and keeping the customer on a journey that remains compelling and relevant throughout. A team can be as empowered as they want, but if they take bets that are too small, just strategically don’t make sense, or they aren't resourced to cover the full user journey, their impact will be limited. Practice is the best teacher, but process accountability can accelerate this by making sure all initiatives have basic sizing (reach, impact, and effort) and execution risks (dependencies, order of operations) are planned out before work begins. 3. Agility - The team is scrappy, making a surprising amount of progress in a short period of time. Speed to learning is of the essence. A team can be effective if they just have the top two principles, but they’ll move slowly without agility. Management can support this through pushing on speed without rushing. My favorite question is “How could you learn [x] even faster?”

The skill sets for growth and non-growth PMs are about 85% overlapped. The key differentiator is analytical sense. While all PMs need to ensure the team is focused on driving customer and business impact, growth PMs always have a direct tie to driving business KPIs. This requires a more advanced level of understanding trends in the data to identify areas of leverage. On the flip side, it is important to know what a Growth PM doesn't need to be great at in a given role. For example, I hired a PM who led a mobile app working with a small, dedicated team. That means the bar for collaboration skills didn't need to be as high as other roles. Another time, I hired a PM who work on core site conversion with a clearly defined scope, so they didn’t need as much depth in product sense.

Focus Area > Problem > Hypothesis First, the focus area for the team must be defined. This starts by mapping out the possible areas the team could focus. My recommendation is to assess the opportunity size using the product of "What's the business value if [x] area was improved?" times "What's the likelihood of that happening?" Next, you want to align on what problem you are tackling. For example, when I first started at ezCater we decided to improve initial landing experiences for visitors. I leveraged the Google Ventures style Design Sprint. That meant working closely with stakeholders to map the customer journey, bringing in analytics and data insights, inventoring customer research, and auditing competitors. Consolidating that all in a Miro board, I could walk the working group through these materials over a multi-hour session and come together on facts and insights to identify the most fruitful opportunity areas. Last, you generate solutions. To avoid group think, have people generate solutions individually. From there, the PM can take lead organizing the ideas and ensuring they have crisp hypothesis that tie back to known insights and there’s a sizing of projected reach, impact and effort to inform relative prioritization. I think this process works best to do quarterly, providing enough fuel for the team to run for a period while giving a recurring blast of fresh context and ideas!