How to Work with PMs - A Cheat Sheet for Designers

要点：

• 认识到PM担任着帮助团队生产成功产品的连接器工作；
• PM擅长
  • 清晰的沟通技能
    • 向不同的人表述目标、优先级、线路图；
    • 言语透明、清晰、简洁、围绕主题展开；
  • 良好的规划，组织技能
    • 在任何时候都清楚项目情况，是受阻还是已经取消了；
  • 能以不同的身份跟不同的人员很好的相处
    • PM的成熟程度以及换位思考的能力要比组织内的其他人强；（沟通能力同）
• 每个PM都有所擅长，可能擅长
  • 执行力
    • 目标相关
    • 符合预期的前提下按时完成
    • 跟团队设想相关
  • 设计思维
    • 理解、欣赏、帮助提升用户体验（设计师争着要哈哈哈）
    • 不是要求PM会自己设计，只是要求PM对设计规范拥有挑剔的眼光以及懂得设计师的价值即使设计师不同意PM的建议
  • 分析技能
    • 控制变量后（定量数据、任务、用户反馈、过往的经验等等）会出现什么后果；
    • 总是思考哪些事情是可以知道的，哪些是无法预测的，以及找出如何减少不确定性以及增加可预测性；
    • 使用工具帮助设定目标、任务优先级以及一系列的项目；
  • 产品眼观
    • 对市场以及现今技术、问题的解读
• 设计师如果视PM为搭档，资源中心而不是一个任务管理者那么设计师的日子会好过很多
  • 设计师可以从PM那里得到：
    • 相关产品的环境
    • 用户反馈
    • 现今的优先级、最关键事件以及目前的最难解决的Bugs
    • 功能Y的数据测试结果
• 设计师会否定PM的提议
  • 这个产品以及优化到可以上线了吗？
    • 鉴于PM的任务就是让事情在按时保质地上线，因此PM有动机催促设计师，而设计师又往往会过分追求质量。
  • 设计师觉得很渣但是用户测试结果来看却表现良好的的产品体验可以上线吗？
    • 考虑数据的来源是否有缺失；
    • 考虑设计师是否过分强调自己的个人体验；
• 对设计师来说，取得PM信任的最快之路是变得reliable
  • 不要提交工作之后就找不到人；
  • 及时交付；
  • 花时间跟PM沟通自己目前的进展，遇到的困难以及大概何时可以交付；
  • 跟PM解释为何你还在探索，目前你对某功能或者人不开心的原因

Once, a long time ago, I was a product manager. Then, I was an engineer. For the past seven years, I’ve been in design. Every single day, I work with people in all of these roles. Every single day, I find new ways to appreciate the responsibilities, challenges, and art behind each of these three pillars of product development. The PM is a chameleon[善变的人；变色龙] of sorts, constantly adapting to what is needed to ship a successful product. As a designer, how do you handle their affable[和蔼可亲的] charm[魅力，美貌] and their data-gushing[并进的], team-herding, smooth-talking ways? Read on.

Understand that the PM’s job is to be a connector that helps teams ship successful products.

This means PMs are, for the most part, exceptionally good at:

1. Clear communication: as part of helping teams successfully ship great products, PMs need to represent the goals, priorities, and roadmap of a team to many constituents, including legal, marketing, customer operations, sales, and more. This means they need to be crystal[透明的] clear, succinct[简洁], and on-topic. A designer or engineer with a tendency to ramble[漫谈] or mumble[喃喃耳语] can be forgiven—it’s not usually the first thing in the job req, after all. But a PM who does the same will not last long. This is why PMs tend to represent the product to executives or to external press—it’s not because they’re considered more ‘elevated[高层的]’ than design or engineering, but that PMs are on average better at communicating because they won’t get hired if they aren’t.

2. Being organized: in order to successfully ship great products, a PM must understand at every moment how the project is going, and whether it’s on-track or off. She should be able to deliver[交付] the entire map of all the pieces that are required to come together for something to go out the door. This requires ruthless[残忍的，无情的], ninja-level organization skills.

3. Working well with a variety of people in a variety of roles: it’s not uncommon for a PM to talk with dozens of people across different teams throughout the course of a single day. Since PMs don’t typically have the authority to make something happen (they can’t directly hire or fire engineers or designers, for instance), they need to demonstrate[示威] and earn trust. If a PM is an asshole, it generally comes out rather quickly and cripples[削弱] their effectiveness. Everybody knows the old cliches[陈腔滥调] of the eccentric[古怪的], curmudgeonly[小气的；不和悦的] engineer and the unreliable, Don-Draper-esque designer, but I have a hard time coming up with a similar caricature[嘲讽] for a career PM. Again, a pretty big generalization here, but I’d posit that on average, PMs have higher levels of maturity[成熟] and empathy[移情作用；共鸣] for others in the organization than engineers or designers.

At the same time, any specific PM, like any specific designer, will have their own unique set of strengths.

Being communicative, organized, and easy to work with isn’t enough. A good PM must also demonstrate some combination of the following skills:

1. Execution[执行力]: how well does the PM ship products that are 1) successful relative to goals, 2) on-time relative to expectations, and 3) smooth relative to how the team feels about it? The more senior the PM, the bigger and more ambitious the project they’re expected to execute. (For instance, a junior PM may take on a project like add feature X to product Y whereas a senior PM may take on a project like build a new mobile app suite Z). Executing well is like captaining a tight, smooth-sailing ship. You need to make sure that everyone knows what they need to do and then does it, that the crew hums together in unison, that you estimated the journey well enough to have packed ample[丰富的] supplies, and that when you set out for X marks the spot on the map, you don’t end up at the sea monster instead (who will probably eat you all alive.)

2. Design thinking: how well does a PM understand, appreciate, and help drive a successful user experience? A PM with this strength will be one that designers clamor[喧嚷；大声的要求] to work with. This isn’t to say that she has to be good at designing herself, but that she should have a critical eye for what is or isn’t a strong design proposal, and understand a designer’s values even if she doesn’t always agree with the suggestions.

3. Analytical ability: how well does a PM plan for and then draw conclusions from known inputs (quantitative data, tasks, user feedback, past experiences, etc) in order to craft a well-rationed plan for the future? An analytical PM considers all the ways something can be known and unknown, and figures out how to gain more certainty and predictability for the future. A strongly analytical PM will use all the tools at her disposal to figure out how to set goals, prioritize tasks, and sequence projects in a way that inspires confidence.

4. Product vision: how well does a PM read the market and current technologies, problems, and attitudes to come up with new and innovative solutions to problems? This is generally a more senior-level PM skill. PMs who are visionary[幻想的；有远见卓识的] are like a spark—they ignite[点燃] and inspire entire teams of people to chase after bold, sometimes very risky new directions.

As a designer working with a PM, it’s important to keep in mind that the overall team must be well-balanced and well-suited to the task at hand. This means, for example, PMs who are weaker on design thinking should probably avoid heavily design-centric projects like redesigns or some major new user product, or be paired with senior designers who can help fill that skill gap. Similarly, designers who need more structure around goals and timelines may do well to have a strong executor PM to keep them focused on the most important things.

Your job will be easier if you treat your PM as a partner and a resource, not a taskmaster.

Need context on some related product area? Your PM’s got that. (And if they don’t, they’ll hook you up with somebody who does, or keep digging until they find the answer themselves.) Want feedback from customers, or salespeople, or your users? Your PM can make it happen. Want to know the current set of priorities or fires or what the worst-offender bugs are? How about what the latest data teaches us about Feature Y? Surely you’d appreciate some additional perspective on how to prioritize the 7 design ideas you just came up with and which ones you should explore first.

Your PM can arm you with context, with data, and with insightful feedback so that you can do your best and most impactful design work. Your PM can shield you from 85% of the distractions that’s going on around you so that you can focus on the work. Just don’t be afraid to ask.

You are going to disagree with your PM.

This is certainly going to happen. Most of the time it’s okay, it’s just the natural system of checks and balances between the three pillars of product development (product, design, and engineering). There are a few common ways this disagreement manifests:

1. Is this product good enough/ready to ship? Since PMs are responsible for getting products out the door successfully and on-time, they have a natural incentive[动机] to push for aggressive milestones so they can ship and then iterate quickly. Since designers are incentivized[刺激] to produce the very best user experience they can, they prefer to have more time on the design, implementation[落实] and polish stages. Taken to the extreme, neither of these are reasonable positions. Nobody wants to ship something tomorrow that’s shitty. Nobody wants to spend 10 years designing the perfect registration flow. Real impact is made by shipping something good in a timely manner.(Most people get this, and the actual debate is about what, precisely, constitutes good and what constitutes timely, but for some reason the argument often devolves into these unproductive extreme caricatures[讽刺]). So, what can you do to resolve this? You can explain your position calmly and rationally. You can do an analysis of what you stand to lose or gain by delaying the launch. You can agree to escalate to an authoritative decision-maker. You can get opinions from other people that both of you trust (my favorite method.) You can do some user testing, vet out whether anyone’s assumptions are wrong. On the whole, if you work with reasonable people, even if this disagreement comes up again and again, it’s not that big of a problem.

2. Can we ship this experience that feels qualitatively bad to the designer but performs well according to the metrics we track? This one is tricky because there are two ways it could play out. The first is that the designer’s point is fair, and the metrics are not tracking actual user value correctly (maybe they are too short-term, maybe they are too incomplete—i.e. good for this one thing, but bad for something else that isn’t being tracked, etc.) In which case, as a designer, you should figure out if there are other metrics to look into that would shine light onto this being a bad experience. The second way it plays out is that the designer is overvaluing their individual experience at the cost of network experience. For instance, maybe it’s not such a great individual thing for a user to be presented with an ‘invite your friends’ flow so early in their session, but long-term, the more friends they have, the more value they’ll get out of the product.

3. We fundamentally don’t agree on the product strategy. This one I talk more about in How to work with Designers, and is the prime case in which I think the designer and PM should seriously reconsider working together.

Regardless of the disagreement, it’s a hell of a lot easier to disagree on tactics[策略] when everyone is in staunch[坚固的] agreement about the end goals. (And if you’re not, as in the case of #3, then it may be time for a change.) I find it helpful to record such debates and return to them after-the-fact. Usually, they’re enlightening, and there are some lessons to be learned for next time. Sometimes they seem silly in retrospect. (We argued so much over that little detail? It didn’t even matter in the end!)

The quickest way to a PM’s heart is to be reliable.

Don’t be the Don Draper that disappears after lunch to find his “creative mojo[魔咒，魔力]” and doesn’t return until Thursday afternoon. Seriously. The creative realm is not some higher plane that excuses you from making commitments and doing your damned best to meet them. Yes, it can be difficult to predict when you’ll come up with something that meets the high quality bar you uphold. But notice I said reliable and not meets every deadline. You may not always know exactly when a good design will materialize, but you should take the time along the way to communicate what you’re doing, why you’re doing it, and when you think it’ll be done even if that’s still changing. Share your in-progress work and your process. Explain why you’re still exploring, and the reasons you’re not happy with what you have so far. The fact that you sought out your PM to talk it over gives you instant reliability cred. It helps her do her job effectively. More than that, it helps her understand you and the way you work, so that you guys will have a stronger relationship in the future.

Because at the end of the day, you, dear designer, shouldn’t just own the goals of your design. You should own the whole of the thing that your team is building. Together. Which is the only way anything great is ever done.

This is Part 2 in the installment, following How to Work with Designers: A Cheat Sheet for PMs and Engineers. Part 3 is here: How to work with Engineers.

转自@joulee