February 20, 2022
This is the second post in a three-part series chronicling my reflections on what went well, what could have gone better, and what I learned in my first year as a manager.
The first post begins with a bit more preamble on the motivations behind this series, so without further ado, let's jump into what I think could have gone better.
Like the post on what went well, I decided to pick my top three reflections (in no particular order) to share for starters. More may follow over time.
I recently stumbled across a great set of essays from Gibson Biddle (ex-VP/CPO of Netflix) on how to define and articulate product strategy. I wish I'd found these earlier in my career as they (IMO) lay out an easy to understand, and hence easy to communicate, framework for strategy. They also stress the importance of repeating your strategy as often as possible, something that I'm not certain I did well as a new manager.
My team's mission statement was to delight Edge users everywhere and empower developers to achieve their vision on the web. For brevity, I've chosen to focus my reflections on the customer-facing end of our mission, but I think many of the reflections below apply to the strategies devised to meet the needs of developers as well.
On the customer-facing end of our mission, one strategy I leaned into soon after becoming a manager was to leverage my team's platform expertise and Microsoft's extensive offering of AI/ML models and services to build durable productivity-focused differentiators in the browser.
Putting this into the framework described by Biddle, this strategy ticked all three boxes in the DHM matrix: research suggested that users struggled with certain aspects of productivity in the browser and would be delighted if they had better tools to help; differentiating at the service level by leveraging Microsoft's wealth of offerings in this space created a hard to copy advantage; and numerous opportunities (which I won't get into here) existed to increase margins as well.
As Biddle shares in subsequent essays, overall product quality metrics like acquisition, engagement, and retention were nearly impossible to causally move with individual projects. As a result, the team brainstormed easier and faster to move proxy metrics. The idea was that moving these proxy metrics would eventually lead to movements in overall product quality metrics, even if causality was hard to prove.
From there, the ideal thing to do would have been to spend time with the team brainstorming ambitious proxy metric targets that could then be translated to key results. This would have ensured that individual PMs felt ownership over the outcomes measured by their proxy metrics without feeling like a solution was explicitly being prescribed. Unfortunately, I didn't facilitate this process as well as I could have. Action-oriented KRs creeped in, reducing that level of autonomy and muddying the clear line of sight to the measurable customer and business outcomes we were driving.
Another thing I could have done better is articulating this strategy (specifically the cascade from top-level user and business outcomes down to individual projects) more frequently with the rest of the team. Looking back, I'd often stop short of the full cascade, emphasizing the importance of quantitative proxy metrics in understanding how user behaviors were changing in response to our experiments, but rarely articulating that even though proving causal changes in overall product quality metrics was hard, we had conviction that we were on the right track because of what movements in our proxy metrics actually represented.
Spending time researching/formulating my own framework for communicating strategy certainly would have made this easier, but even despite the fact that I didn't have a clean framework, I still don't think I sufficiently tied the work we were doing back to the overarching "why" as often as I could have.
Beyond communicating strategy, I was also fairly focused on the here and now, rather than spending time focusing on the 3-5 year vision for the team. I particularly like the GLE model that Biddle proposes for this and I look forward to continuing to better my skills in this space as I take on bigger and bigger challenges that necessitate this type of principled, long-term thinking.
When new hires joined my team, I spent a decent chunk of time creating individualized onboarding guides that would help bring them up to speed as quickly as possible. These guides started broad, with an introduction of who was who in the Edge organization and a deep dive into each team within our Web Platform organization. From there, they'd narrow in on how Edge shipped, how work was planned, and the mission our team was on before outlining individual areas of ownership + related OKRs. They'd then conclude with a list of resources (permissions to request, telemetry dashboards to check out, OKR cascades to internalize, wiki pages to read, etc.).
While I received plenty of positive feedback on how these guides improved folks' onboarding experiences, I still had the nagging feeling that they only scratched the surface on how to quickly ramp up as an effective product manager on the team: navigating our disparate telemetry/data/experimentation systems, something too complex to type up neatly in the guide, was still largely a mystery; internalizing the way that code flowed through the various release branches of Edge, something required for ensuring the right changes reached the right users at the right times, required several offline discussions; and our process for building both customer- and developer-facing product, from product discovery through to delivery and optimization, was barely mentioned at all. All of these shortcomings in a guide that was already almost 10 pages long.
Before I announced that I was leaving the team, I had a grand vision for a PM bootcamp that would help address these shortcomings. I knew that reading was not everyone's preferred learning style and had brainstormed ideas with my directs ranging from recorded deep-dive/Q&A sessions on a specific topic to TikTok-esque shorts that would succinctly explain a common workflow or scenario.
Beyond onboarding, I also started (though could have developed much further) a SharePoint site that I wanted to turn into a learning curriculum for PMs, making it easy for folks on the team to share resources with others, and for PMs looking to grow specific skills to find a vetted set of resources that they could leverage to grow.
I wish I'd dedicated more time to these initiatives, as I think they would have greatly benefited every PM across the organization and contributed to a stronger product culture. If there are any folks from Edge reading this far, please feel free to steal this idea 😉
While on one hand (see the previous post in this series), I'm glad that I took the time to think deeply about what the team needed for long-term success and hired a diverse set of folks who helped build a truly magical culture of customer-focus and collaboration, I'm also painfully aware that I had positions on the team that were open for months before being filled.
The most direct impact of these open positions was the fact that I was spending more time being an IC and less time being a lead. This came with both benefits and drawbacks. On the one hand, spending more time as an IC helped me ramp up in our team's data and experimentation systems, allowing me to coach others through the challenges they faced when they went through the same process and giving me the opportunity to model the customer- and data-first culture I wanted to cultivate on the team. On the other hand, this IC work took time away from the deep focus time I should have carved out as a manager to think more broadly and strategically about where the team was going or to help build out programming to develop other PMs on the team at scale.
Reflecting, I should have made hiring a bigger part of my day, actively sourcing candidates through my network and LinkedIn rather than letting candidates trickle in through applications and recruiter sourcing. Beyond increasing the collective throughput on the team and freeing up more time for ICs to conduct more exploratory user research, rounding out the team more quickly also would have given me the opportunity to continue to increase its collective expertise and diversity. While I'm generally pleased with the progress made on this front, there was more I wanted to do in terms of growing team diversity in different, less-obvious dimensions.
Overall, I'd boil my reflections down to the fact that I should have focused on growing the team more rapidly so that everyone (including myself) had more time to focus on higher-leverage work and to benefit from the collective strengths/experiences of as many close peers as possible. If you have thoughts on effective sourcing techniques, defining/communicating strategy, or standing up onboarding/development programs at scale, I'd love to pick your brain and learn more about approaches have worked well for you!