22 Principles for Great Product Managers

栏目: IT技术 · 发布时间: 4年前

内容简介:A few years ago, I readThis 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 e

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. Feedback? Leave a comment!

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.

Making Decisions

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.

Communication Effectively

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).

Further Reading

  • Principles , by Ray Dalio, which inspired this exercise.
  • Inspired by Marty Cagan. If there’s one book on Product Management you should read, it’s this. At some point, I’ll publish my ~3,000 words of notes from it!

以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

代码大全(第2版)

代码大全(第2版)

[美] 史蒂夫·迈克康奈尔 / 金戈、汤凌、陈硕、张菲 译、裘宗燕 审校 / 电子工业出版社 / 2006-3 / 128.00元

第2版的《代码大全》是著名IT畅销书作者史蒂夫·迈克康奈尔11年前的经典著作的全新演绎:第2版不是第一版的简单修订增补,而是完全进行了重写;增加了很多与时俱进的内容。这也是一本完整的软件构建手册,涵盖了软件构建过程中的所有细节。它从软件质量和编程思想等方面论述了软件构建的各个问题,并详细论述了紧跟潮流的新技术、高屋建瓴的观点、通用的概念,还含有丰富而典型的程序示例。这本书中所论述的技术不仅填补了初......一起来看看 《代码大全(第2版)》 这本书的介绍吧!

Base64 编码/解码
Base64 编码/解码

Base64 编码/解码

URL 编码/解码
URL 编码/解码

URL 编码/解码

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具