A company / org / team’s power dynamics, specifically the default influence of Product Management, provides the foundation for how PMs & PM leaders can work effectively with other functions (Design / Eng / Analytics / Sales / etc.)
A thread & framework to better understand this:
Note:
The observations here are just that—they are observations
They are not a wish for how the world ought to be, nor how you must run your team/org/company, nor a prescription of the One Right Way for every company.
Read this thread accordingly, and adapt it to your context.
From interviewing 100s of PMs, the top question I’ve gotten from PM candidates (besides “what makes PMs successful here?”) is some version of “so, who really runs this place? is this place PM-driven, eng-driven, sales-driven, or something else?” (often asked a bit indirectly)
This makes it clear to me that most PMs care a lot about working in a place where their execution, insights, impact are going to be valued—a place where they can make a difference & get recognized.
But what does that mean concretely?
And how can you discern your org’s culture?
There are many ways to indirectly assess this: stage & size of company, size of org, variance in power structure across orgs / teams, background of the org leader / CEO, type of product (technical / platform / consumer / b2b / etc), default ownership of key processes, etc. etc.
Here’s a litmus test that has helped me best understand power dynamics as a PM leader:
In this org, how much influence do highly competent PMs have on product decisions & direction?
And how much influence do less competent PMs have on product decisions & direction?
Based on the answer to these questions (which can only be formed via close observation of the goings-on of the org), we get these 3 types of cultures for a team / org / company’s product work:
1) PM-serviced
2) PM-dominant
3) PM-guided
1) PM-serviced:
The litmus test of a PM-serviced culture is that even very competent PMs are unable to consistently have a significant influence on product decisions. Another function (usually Eng/Sales, sometimes Design or Marketing) is dominant in most product decision-making.
In such a culture, Product Management is viewed as a service function that helps out the dominant function. PMs often do project & program management for a significant portion of their time. To get ahead, a PM has to be viewed highly favorably by people in the dominant function.
Here’s a PM-serviced culture, summarized:
For a more visual representation, we can plot the 2 criteria (the Degree of PM Competence & the Ability to Influence Product Decisions) on the X and Y axis respectively.
Here’s where a PM-serviced culture falls in this 2-D space:
2) PM-dominated
This is the opposite of PM-serviced. The litmus test: even an incompetent PM has a high degree of influence on product decisions. The PM title by itself provides a default “right” to PMs “to run the show” or to disproportionately dictate product decision-making.
In such a culture, Eng/Design/Analytics/etc. may still be deemed important, but are also expected to “stay in their lane”. As the company gets really large, most of the really passionate folks resign (literally or figuratively). Product quality in such a culture tends to be so-so
Here’s a PM-dominated culture, summarized:
And here’s where a PM-dominated culture is located in our framework:
3) PM-guided
In PM-guided cultures, 2 things must be simultaneously true
- Competent PMs get to have a high degree of influence on the product AND
- Less competent PMs have low influence on the product. In such situations, other functions can & do step in to take more ownership
A PM-guided culture feels most like a partnership of equals between PM & other functions. Such a culture is very energizing for very competent PMs but can be difficult for all other PMs. Passionate debate over product decisions & details is common. Product quality is usually high
Here’s a PM-guided culture, summarized:
PM-guided culture in our framework:
(note that both conditions must be broadly true for a culture to be PM-guided per my definition here. ofc, the extent to which they are true might vary a bit e.g. a given PM-guided culture could be a slightly more lax on its low competence PMs)
So, what can we do with this info?
As a senior exec or PM leader, you can do a lot. Once you diagnose roughly where your PM culture is, evaluate if changing it will help your company & your org better meet its goals. As a PM leader, I’ve often succeeded in changing it for my org
So I’ll conclude this thread with my approach:
Whenever I have found myself responsible for a PM-serviced or a PM-dominated org (whether due to the org’s own quirks / history, or due to the company itself), I have worked hard early on to nudge it towards being more PM-guided.
Why: Too many reasons to list here, but mainly because it is more fun, for me.
Of course, PM-dominated would be more convenient for me as a PM leader (and for PMs on my team). But more convenient doesn’t always equal better, at least for me. You do you.
Now, let’s look at how.
How:
PM-dominated → PM-guided is easier. Have an honest discussion with your xfn counterparts (they’ll welcome it), identify folks in Eng/Design/Analytics/etc who are really insightful about the product & amplify their voices. Also reset any prior expectations of PMs on the team
How:
PM-serviced → PM-guided is harder, but is still possible to do in an org, even if the broader company is not PM-guided. For this, first you must build extremely high credibility with your xfn counterparts, esp those in the dominant function (my experience has been with Eng)
Once done (takes a few months), be super-candid with your counterpart that you aren’t happy with the current role of PMs in the org. Don’t be afraid to be highly assertive, make it known that without this new deal, they won’t get the benefits they’ve seen lately from your work.
I hope this thread will be helpful in better understanding the state of your world as a PM leader and in communicating that state with the PMs & leaders on your team & with your counterparts in other functions. I wish you all the very best, and leave you with this summary:
I want to say a huge thanks to my super follower community (of 1000+ Sr PMs, Product Leaders & Founders) for feedback, questions, and lively discussion of my prior drafts of this framework. This is a complex topic that I wouldn’t have been able to clarify here without their help.
From scrolling on Twitter, one might conclude that it is a terrible idea to work at GAMMA (Google Apple Microsoft Meta Apple) companies & other tech megacorps.
While that might be true for some people, here are 7 good reasons why it is smart to consider working at a GAMMA corp:
1) Thinking Big
If you’re a person with High Agency, GAMMA corps will instill in you the habit of thinking big. Like, really big
I didn’t think much of this while I was at GAMMA corps, but once I left to go elsewhere, it was striking how rare this is at startups & midsized corps
What’s more, founders of the very best startups tend to be extremely ambitious themselves. And post-PMF, they often need to hire leaders who are neither afraid of thinking big nor get intimidated by 10X/100X goals. Working at a GAMMA corp is a fantastic way to build this muscle.
Lack of time is a perpetual source of stress in the product manager’s journey.
No matter how well you’ve prioritized, no matter what milestone your product has just reached, there is a near-infinite list of really important things you could be doing that you just cannot do.
There are many well-known resources & principles for managing time: systems such as GTD, “managing your energy, not your time”, prioritization formulas, Eisenhower Matrix, etc.
These are no doubt useful, but for product managers, these systems leave a lot to be desired.
Why do companies with major resources & distribution make products that are mediocre & often fail to reach their potential?
There are a handful of reasons, many of which you already know. But there is one under-discussed reason: Operators Optimizing for Optics
Thread:
To understand this, let’s start with a story.
START OF STORY
Acme Inc has brilliant, visionary founders (Alice & Bob), amazing culture, has built a well-loved product, and thereby created a business much larger than the early people (including the founders) had ever imagined.
With this growth, they’ve had to hire a bunch of Operators: leaders who are skilled in scaling process, teams, operations, and overall execution. So far so good. As the business & the customer-base grows, it is a no-brainer for Acme to tackle adjacent areas of opportunity.
Some reflections since turning on Twitter’s Super Follows two weeks ago.
800+ superfans have joined 🙌🏾
Biggest benefit:
I am tweeting a lot more freely because I know I am speaking to superfans who understand what I am about. More advanced & nuanced content. Fewer unsent drafts
Biggest surprise:
The community aspect of Super Follows has been A+ thus far.
While not a primary goal, it was 1 of my hypotheses for doing Super Follows. And it has vast exceeded everyone’s expectations. I polled folks yesterday for feedback, and community was mentioned by most
Many super followers mentioned that they are now using Twitter more frequently & are replying/sharing a lot more freely with the community than they might in public, because of shared alignment.
One super follower said it best: people writing without fear of being misunderstood
As they grow in size, teams within megacorps and startups tend to implicitly bias more towards Project Thinking and not enough Product Thinking.
Product Thinking is a mindset and a process that, once you see, you cannot unsee it.
Product Thinking, Project Thinking, a thread:
From my experience working in individual contributor & leadership roles over the past couple of decades, and from my advising work with a number of fast-growth startups, I have often seen myself and founders / CEOs / execs worry about these things:
And, having been in the trenches of product work for a large part of my career, and having managed / mentored / coached hundreds of PMs & PM Managers, I have often seen myself, and other ICs & managers worry about these things: