A few years ago, I read Principles by Ray Dalio, and I became enamored with the concept of codifying my own. So, I borrowed the idea and started noting them down.
This list—pieced together over the past few years—reflects what I believe are some of the most important principles for product managers. I can’t claim credit for inventing these; they are the summation of what I’ve learned through experience, coaching, and osmosis. This list wouldn’t exist if not for the incredible people I’m fortunate to work with and from whom I’ve learned so much.
Product Management is a broad function, so I’ve tried to distill this down to the top 3-4 across 6 categories: These principles are very much a “living” list. I don’t intend for this list to be exhaustive—nor does it reflect the entire scope of the product manager role—and these principles will continue to develop over time.
Leading Your Team
1. Your team should be able to repeat the vision, goal, and value. If your team can’t, you probably haven’t communicated it enough or aren’t aligned.
2. You should know what game you’re playing, and how you keep score. Credit to Adam Nash for this framing, see here for his fantastic article.
- The game you’re playing: Your vision for the product, your product’s value to the customer, your competitive advantage, and how you’ll win.
- How you’ll keep score: What does winning mean? How will you measure success? What’s your “compass” to tell whether you’re traveling in the right direction?
3. Your team should know the path to reach the goal. You need not detail execution to the point of false precision, but you and your team must understand the high-level milestones. If the milestones aren’t clear because of unknows, these unknowns should be explicit.
4. Decisions should be documented, explained, and widely communicated. It should feel like over-communication. If you don’t feel like you’re over-communicating, you probably aren’t communicating enough.
5. Decisions, and what you prioritize, need evidence. It’s your job to make sure this evidence exists. Inevitably, you will base some decisions on your judgment in place of data. Judgment-weighted decisions are okay, provided it’s explicitly communicated.
6. Stakeholders should be involved early and often, and alignment should be explicit. You’re looking for either a “yes, I agree with this decision, or a “no, I disagree, but I can commit to moving forward.” Escalate quickly and cleanly to resolve misalignments.
7. There is no such thing as over-communication. “Fluff” communication = enough communication.
- If you’re not sick of saying it, you probably aren’t saying it enough. Constant communication might feel like “fluff,” but it isn’t. Evangelism is a critical part of the role—and it’s your job to make sure the organization is aligned and swimming in the same direction.
- Marty Cagan, in Inspired, said it best: Evangelize continuously and relentlessly. There is no such thing as over‐communicating when it comes to explaining and selling the vision. Especially in larger organizations, there is simply no escaping the need for near‐constant evangelization. You’ll find that people in all corners of the company will at random times get nervous or scared about something they see or hear. Quickly reassure them before their fear infects others.
8. You, the product manager, should have a uniquely high communication bar. Most functions have a primary “output” that isn’t communication: Designers design, engineers code, etc. For you, communication is a primary “output,” and it should be exceptional.
9. You have to own the narrative. When there’s a narrative vacuum, people will “creatively” fill in the blanks themselves—and you might not like it. Losing control of the narrative can be incredibly disruptive to your team’s ability to deliver.
Being an Effective Operator
10. Strong relationships enable strong collaboration. “Have strong relationships” sounds obvious, but the importance of relationships “up,” “down,” and “across” can’t be overstated. Without a solid mix of relationships and credibility, you won’t succeed.
11. Don’t be in the weeds managing every nuance of every project; save this for emergencies. Swim in your lane, and give your team space to do their job(s). Focus on:
- Setting the goal, i.e., “what game are we playing?” and lead/help the team in figuring out how to get there (milestones, dependencies, alignment, etc.).
- Leading the team. E.g., establish the communication cadence (updates, Slack channels, syncs), meeting rhythm, high-level project milestones, success metrics.
- Don’t pester. Establish the right communication channels upfront, and let your team keep you updated. See “maker’s schedule” under (12).
12. Greatness is achieved in the agency of others. Product managers follow the “manager’s schedule.” Engineers & designers follow the “maker’s schedule.” Help your team be great “makers”—keep them unblocked; respond effectively to unfolding situations.
13. Your job is to create clarity: This is some sound advice that I got early on (thank you, Greg!). As a product manager, constantly think about how you can create clarity for your team: Clearer product requirements, resolving edge cases, answering questions, etc.
- If you’re drowning in questions, you probably aren’t proactively communicating effectively, or the product requirements lack clarity. Some questions are natural, so use your judgment.
14. Be on top of your shit. Until I figure out how to better articulate this, I’ll say it ineloquently as “just be on it.” Know your business, your product, your team, be responsive, communicate relentlessly, make good decisions, own your results, get 1% better every day.
Managing Your Time
15. 80% of your role is discovering the right product & driving organizational alignment, and 20% is answering clarifying questions for the “makers” on your team. Product teams are in a constant cycle of discovery and delivery, which run in parallel:
- In an ideal world, engineers are ~80% delivery, ~20% discovery; product managers are ~80% discovery, 20% delivery.
- In large complex organizations, this is a difficult target to achieve, but strive to spend 80% of your time on discovering the right product (ideation, validation, testing, etc.) and communication (driving organizational alignment, creating clarity).
- “Organizational alignment” is an intentionally broad term, including everything from 1-1 meetings to executive strategy reviews to product “deep dives” to all-hands presentations.
16. Ensuring that you have time set aside for strategy and “focus” work is your responsibility. Getting sidetracked with 1,000 emails and Slack messages is natural, but it can’t be an excuse. Make sure you have time set aside for focused work.
Running Effective Meetings
17. Send agenda items beforehand. At the start of the meeting, collect input, and align on the goal. Meetings are expensive; when people are meeting, they often aren’t making. Own the meetings you run, and make sure they’re productive.
18. Use “DAD” to help structure and run meetings. Most meetings are a mix of Discussion, Actions, and Decisions: Document any decisions, communicate topics of discussion, and enumerate any action items.
19. “ABFU,” or Always Be Following Up (terrible, I know). Make sure you (or someone else) sends notes to all relevant stakeholders within ~24 hours. They don’t need to be perfect, but make sure they exist and that you communicate them.
20. Be deeply curious, and ask the “dumb” questions. Asking the right questions, even if they seem dumb, is a catalyst for creating clarity. Ask questions openly, in earnest, and let everyone else hear the answer. You probably weren’t the only one with that question.
Running Projects & Other
21. Every project includes a mix of Discovery, Design, and Delivery (and iteration); you should make sure these run in sequence. While we expect and desire some overlap, aspire not to make sweeping changes to design during delivery (as an example).
22. Be responsive; if you’re not, you might be holding things up. As the hub between every other function, and often the decision-maker, you have to keep the wheels greased for your team. One idea: ~2 hours for Slack, ~2 days for email (but much faster for anything urgent).
- Principles, by Ray Dalio, which inspired this exercise.
- Inspired, by Marty Cagan. If there’s one book on Product Management you should read, this is it. At some point, I’ll publish my ~3,000 words of notes from it!