How to Work with PMs - A Cheat Sheet for Designers

要點(diǎn)：

• 認(rèn)識到PM擔(dān)任著幫助團(tuán)隊(duì)生產(chǎn)成功產(chǎn)品的連接器工作揭北；
• PM擅長
  • 清晰的溝通技能
    • 向不同的人表述目標(biāo)具壮、優(yōu)先級、線路圖男娄；
    • 言語透明灭抑、清晰十艾、簡潔、圍繞主題展開腾节；
  • 良好的規(guī)劃忘嫉，組織技能
    • 在任何時(shí)候都清楚項(xiàng)目情況，是受阻還是已經(jīng)取消了案腺；
  • 能以不同的身份跟不同的人員很好的相處
    • PM的成熟程度以及換位思考的能力要比組織內(nèi)的其他人強(qiáng)庆冕；（溝通能力同）
• 每個(gè)PM都有所擅長，可能擅長
  • 執(zhí)行力
    • 目標(biāo)相關(guān)
    • 符合預(yù)期的前提下按時(shí)完成
    • 跟團(tuán)隊(duì)設(shè)想相關(guān)
  • 設(shè)計(jì)思維
    • 理解劈榨、欣賞访递、幫助提升用戶體驗(yàn)（設(shè)計(jì)師爭著要哈哈哈）
    • 不是要求PM會自己設(shè)計(jì)，只是要求PM對設(shè)計(jì)規(guī)范擁有挑剔的眼光以及懂得設(shè)計(jì)師的價(jià)值即使設(shè)計(jì)師不同意PM的建議
  • 分析技能
    • 控制變量后（定量數(shù)據(jù)同辣、任務(wù)拷姿、用戶反饋、過往的經(jīng)驗(yàn)等等）會出現(xiàn)什么后果旱函；
    • 總是思考哪些事情是可以知道的响巢，哪些是無法預(yù)測的，以及找出如何減少不確定性以及增加可預(yù)測性棒妨；
    • 使用工具幫助設(shè)定目標(biāo)踪古、任務(wù)優(yōu)先級以及一系列的項(xiàng)目；
  • 產(chǎn)品眼觀
    • 對市場以及現(xiàn)今技術(shù)券腔、問題的解讀
• 設(shè)計(jì)師如果視PM為搭檔伏穆，資源中心而不是一個(gè)任務(wù)管理者那么設(shè)計(jì)師的日子會好過很多
  • 設(shè)計(jì)師可以從PM那里得到：
    • 相關(guān)產(chǎn)品的環(huán)境
    • 用戶反饋
    • 現(xiàn)今的優(yōu)先級、最關(guān)鍵事件以及目前的最難解決的Bugs
    • 功能Y的數(shù)據(jù)測試結(jié)果
• 設(shè)計(jì)師會否定PM的提議
  • 這個(gè)產(chǎn)品以及優(yōu)化到可以上線了嗎纷纫？
    • 鑒于PM的任務(wù)就是讓事情在按時(shí)保質(zhì)地上線枕扫，因此PM有動(dòng)機(jī)催促設(shè)計(jì)師，而設(shè)計(jì)師又往往會過分追求質(zhì)量辱魁。
  • 設(shè)計(jì)師覺得很渣但是用戶測試結(jié)果來看卻表現(xiàn)良好的的產(chǎn)品體驗(yàn)可以上線嗎铡原？
    • 考慮數(shù)據(jù)的來源是否有缺失偷厦；
    • 考慮設(shè)計(jì)師是否過分強(qiáng)調(diào)自己的個(gè)人體驗(yàn)商叹；
• 對設(shè)計(jì)師來說燕刻，取得PM信任的最快之路是變得reliable
  • 不要提交工作之后就找不到人；
  • 及時(shí)交付剖笙；
  • 花時(shí)間跟PM溝通自己目前的進(jìn)展卵洗，遇到的困難以及大概何時(shí)可以交付；
  • 跟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[并進(jìn)的], 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[陳腔濫調(diào)] 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[執(zhí)行力]: 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[幻想的脆诉；有遠(yuǎn)見卓識的] are like a spark—they ignite[點(diǎn)燃] 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[動(dòng)機(jī)] 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[落實(shí)] 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[堅(jiān)固的] 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.

轉(zhuǎn)自@joulee