Product Management
I came across a Twitter thread authored by Ken Norton, a former Google Product Manager who coaches and writes about product management, this morning. The thread explores a sentiment that I’ve been feeling quite a lot recently, with an exciting proposal to actually enact something I’ve been telling my friends and peers that I’ve been wanting. I started to reply on the Twitter thread before realizing that I had more words to say, so I figured I’d share my thoughts here.
I’m a Senior Product Manager at AWS. I’ve been here for about three months, and before joining Amazon, I was a Staff Product Manager at Mozilla (Staff is above Senior at Mozilla, but job titles are weird and made up). For the past two and a half years, product management has been my primary focus in my roles at these companies – and I’m still trying to figure out what that means.
Product management as a discipline is fuzzy. The borders of the responsibilities of a PM aren’t clear: your job, as it’s explained to you, is often some combination of business, engineering, finances, marketing, QA, and design. You work across these teams to “manage a product”, which usually means launching something to make the company you work for money. Product management culture at different companies is often what dictates how you manage a product, and what combination of the above responsibilities make up your day to day work. Some product managers do a lot of project management, and sit between product and engineering. In my experience, this tends to be especially true earlier on in the role – you’re responsible for features, or a specific component of your product. As you become more senior, you start working more closely with marketing and QA to ensure that there’s a specific story that your feature tells, so that your customers can understand what it is that you’re building. Once you really start to get into product management as a career, you get into the business side. At that stage, the way that you manage your product is more abstract, because time is a finite resource. Ken’s blog post on the topic articulates this beautifully.
I’ve managed small teams in the past. I don’t mind management, but at the time, I felt far too early in my career to effectively be able to help my team grow. They deserved more from the person who was managing them and their work. Moving back into an individual contributor role was a relief. A lot has changed in the past few years, and I’m thinking more about that now. I’m always, constantly, evaluating the way that I look at what I’m doing, learning, and how I can be most effective in my work. Reading this post from Ken was a refreshing reminder that I’m not alone in feeling a bit stuck as a mid-level product manager trying to figure out what “forward” looks like, and unsure about how much people management will end up in my future.
This has been especially impactful is in the way that I’ve been thinking about graduate school. I recently applied for a part-time MBA program because “product is software engineering and business” and I already have an engineering degree. I’m not especially well-versed in P&L and business strategy. My go-to-market approach is soft, community-driven, and driven from idealistic, Silicon Valley startup-based experience. Startups get millions in funding without having to demonstrate real, accurate revenue strategies; while I’ve never been at the cap table, so to speak, I suspect that this is where the power in VC firms lie: they have all of that market financial data, and they find the product and engineering teams who have the skills and idealism to build innovative products that roughly map onto a future-facing trend. But in any case, I’m wondering if I’m interested in an MBA because I really want to learn about business administration, or if I feel like I’m “supposed” to know about business administration.
In startups, product is often driven by the CEO. Sometimes, it’s driven by the COO, because apparently at executive levels, operations and product leadership are rolled up into one big bundle. It’s often messy. Product is a constant balance of bottoms-up and top-down decision-making, sprinkled in a lot of cross-functional communication, and at the end of the day, your success as a PM is tied directly to how well other teams do their job. And yet (or perhaps because of this), you still end up with people fundamentally misunderstanding what the role of a PM is.
One thing that makes it hard to envision how product grows as a discipline is that it is a role that is dependent on so many other teams. It’s a “glue” role. There will be individual deliverables: papers to write and documents to share and strategies to create and teams to lead and conversations to unblock people, and prioritization exercises, and testing of the product, and understanding the customer — but the asks that a team will have of their product leadership is so dependent on the company culture, the state of the product, the values the team holds, the market that the team is in — that it’s hard to define the responsibilities even as an individual member of a team, much less as an entire discipline and career ladder.
But all of that said — I’m hopeful, reading Ken’s blog post. I’m hopeful that people who choose product management as a discipline have more opportunities to grow in different ways in the future. When product managers are given flexible frameworks to help their teams and their product be successful, everyone wins.
Now I just need to figure out what that means for me, and where I hope to grow in the future.