The ever-rising bar of being a great product manager
When I first became a product manager, the biggest skepticism I faced was that I didn’t have a technical background. That was important in part because PMs were sort of an extension of the development team, and a lot of the job was focused on scoping problems & solutions with engineers and brokering those tradeoffs with business-facing teams.
Yet over the last decade, I’ve seen the function expand and grow — certainly across companies, but even within. My friend Jon, the VP of Product at Optimizely, has seen the product function evolve across his 6+ years with the company. When we chatted about the changes he’s seen, it became rapidly clear that the “bar” for being a great product manager has gone up.
We are at a moment in time where, with distributed teams and more sophisticated tooling, PMs are simultaneously expected to be technically competent, “data literate” and a compelling writer. This change creates incredible opportunities for people who are hungry to learn, and an opportunity for companies to level-up their product orgs and PMs.
At the same time, the foundations, or hygiene, of an excellent product manager are more important than ever. A systematic way to capture customer and market insight and share context regularly with stakeholders is the only way that distributed teams will be navigate the complexity that comes with all strategic projects.
How has the product function evolved over the 6+ years you’ve been at Optimizely?
The biggest trend we’ve experienced at Optimizely, as practitioners ourselves and as tool makers, is the huge rise in data literacy in product management. When I got started, analytics was hard to find, relatively simplistic, and considered a nice-to-have. Now, even in B2B, there’s been an explosion of user data and it’s increasingly available at our fingertips. This includes engagement analytics (where are people clicking), session recordings, and rich data warehouses for seeing exactly what people create with our products.
We expect all our PMs to have the core metrics for their product down cold.
This trend has changed the expectations for the product manager. We expect all our PMs to have the core metrics for their product down cold. New features should have clear goals set for adoption, based on concrete examples from other things we’ve launched. And particularly in B2C, it’s become standard to only launch a new feature when it improves core metrics, or at least doesn’t harm them. This trend will only continue, and every PM should be thinking about how to build their data skills to ride this wave.
The product-leader role varies so much company-to-company. What’s been most unique about your role recently?
I started out focusing much more on engineering and design, but in the last year my role has skewed much more toward the go-to-market/business side. Most recently, my focus has been on improving our sales funnel which means I’ve spent most of my time with our sales, marketing, and finance teams rather than traditional product/engineering work.
Unlike shipping a single feature, a project like pricing is massively cross-functional
My latest initiative has been revamping our pricing. What’s interesting about a project like that is that much of the process is the same as traditional product management. I started out by interviewing a ton of users and internal stakeholders, doing quantitative research, and looking into how competitors operate.
“Designing” a pricing model means thinking through the user experience and the long-term maintenance implications, just like a software engineer would do.
But unlike shipping a single feature, a project like pricing is massively cross-functional. I need to present to a wide array of audiences across the organization, and I’m not the sole decision maker by any means. Instead, it’s an extreme version of the standard PM role of herding cats and getting execs on the same page — in this case, our entire C-suite. I’ve had to give up my instinct to move fast and make a lot of decisions myself, and instead play a more consultative role collating information, presenting clear options, and focusing on making sure that a decision gets made quickly.
And then PM-to-PM there’s a lot of variety in how people work. How does that influence how you manage the team?
I lean very far on the “empower” side of the spectrum and don’t really care much about standardization. The PMs on my teams have such different skill sets and personal styles, and I want to take advantage of that variety rather than forcing everyone into a common way of working. Coming from bigger organizations, I’ve seen cases where a well-meaning process can actually stifle creativity and prevent people from trying out new approaches or bold ideas.
Having strict standards on these steps actually empowers people to approach the “how” differently, knowing that they just need to achieve certain outcomes.
That said, we do look to standardize certain outcomes and work products. We use templates for PRDs to ensure everyone’s answering the same questions around problem definition, and we try to set up common “gates” in the development process to make sure we’re going through design reviews, involving the right stakeholders, and setting measurable adoption targets. Having strict standards on these steps actually empowers people to approach the “how” differently, knowing that they just need to achieve certain outcomes. So I always encourage teams to find the right amount of lightweight coordination to keep them in sync, and let their people roam freely within that framework.
What’s been your experience transitioning to a remote working model?
Oh man, I find it *so much* harder to be a PM remotely. Everyone’s experiences will vary, but I find it’s just so much more difficult to operate without being in person. I think solo work tends to be easier, but product management is so collaborative.
I’ve found that good writing is much more powerful in remote work
Our job is to gather context on a huge number of initiatives across our company and our user base, keep people informed at all times, and keep our pulse on all the development and design work happening internally. This was much easier for me when I could do it serendipitously, by wandering up to whiteboards and dropping by people’s desks, and I’m finding I have to be much more intentional about creating those moments.
One suggestion for adapting: try to make more of the job asynchronous.
Don’t just try to replicate face-to-face meetings in a remote culture. Instead, re-orient your work to be more efficient and require fewer of those interactions. I’ve found that good writing is much more powerful in remote work, so spend more time on great PRDs and presentations that speak for themselves. Short-form recordings are also a great tool for this, and I’m excited to see all the new tools like Loom taking off to support this.
