How to define a PM? I build my answer on the book, and also on my own experience running product at small startups (Vimes and WindBorne). A caveat: both my past roles have been at early-stage companies (one I founded and another at Series A), which means that I’ve had more experience with ambiguity and hacky 0-1 processes and very little experience with formal structure and scalable systems.
Influence without authority
LeMay emphasizes on that PMs are accountable for outcomes (product success, alignment between business + users etc), but don’t usually have direct formal authority over many of the people and teams they depend on. You depend on engineering, but you’re not Head of Eng. You depend on designers, but you have no direct authority over the design team. Thus, you have to persuade and facilitate.
In my product-adjacent role at WindBorne, I’ve worked with colleagues who are older than me and definitely not under my authority — for example, our CTO (past leader at SpaceX, Harvard Physics PhD) or our Head of Meteorology (25 years experience, built IBM’s global weather model). What I’ve found is helpful in influencing without authority is approaching every room and team with a service mindset. By leading with “how can I unblock you” or “how can I roll up my sleeves to be most helpful for you right now”, you win trust and a seat at the table.
Glue, architect, shock-absorber, amplifier, unblocker…
LeMay writes that the role is less about building (actual coding or designing) and more about being an enabler: bridging gaps between business goals, user needs, and technical execution. PMs translate among different perspectives, eliminate friction within or between teams, and help amplify what works.
In my experience, I like to think of it this way:
- Glue: connect teams. For example, at WindBorne, I translate between the business language and the Deep Learning team’s language to align priorities between the two teams
- Architect: build systems that scale. Could look like creating a user insights machine to consistently generate customer feedback
- Shock-absorber: When something goes very wrong, dampen the blow, put out fires. Could be responsive or proactive (by architecting better systems, for example)
- Amplifier: unlock everyone’s best
- Unblocker: be a knife. Identify the “unsynergy” and surgically remove it
Questions for the author
- What are strategies for influencing without authority, especially when you are the newest and most junior person in the room?
- “That’s not my job” isn’t in the PM vocabulary, but how do you protect boundaries? There’s temptation to bite off more than you can chew, especially for high-agency people with a can-do attitude. How do you protect your energy and remain discerning in what’s worth tackling, rather than getting lost in the idea/priority maze?
- In such an unstructured role, it’s often good to pick a priority/vision, make it yours, and execute it amazingly. Especially when you’re just starting out, it’s a good way to win trust and prove yourself. Any tips for identifying the right project to demonstrate your value?
