【翻译】本文由陈大菜学习并翻译自Marty Cagan的文章《Common PM Problem Areas》，供产品爱好者交流使用。有些翻译的地方觉得还是不尽人意，希望读者多多指教。
产品经理的困境
由Marty Cagan 2018年11月30日发布
最近我在和几个产品领导的餐桌上，被问到，我在产品团队中遇到的最普遍的疑惑是什么？
这是个好问题，我描述了几个场景，至少从他们的反应中可以看到，这些问题也在他们的组织中发现过。
所以我想，把这些问题摆到台面上以便被看到、更主动地有意地解决他们。
证实想法 vs 解决问题
关于快速辨别和验证猜想的技术方法有过不少讨论。很多团队已经懂得了如何把这件事情高效完成。
当然，在很多组织，大部分想法依旧来自高管和股东。但是现在，比起进行设计和建造，产品团队知道他们有义务确保解决了深层的问题，而不是做些浪费企业的时间和金钱的东西。所以他们分析风险、构造测试（通常是通过快速制作原型，来获得关于这个想法的定性或定量的反馈）。不出意料，他们经常发现这不是一个好想法，所以他们回头就向股东汇报，这个想法行不通，所以他们开始这个项目。
但几次之后，股东很快变得很受挫。毕竟他们在努力经营自己的部分业务，却一直被告诉“不可以”，这让他们很心累。最后，股东和高管受够了，他们告诉团队要么去做，要么他们会找其他人来做。
我想要解释的问题是什么呢？产品团队的目的不是作为门卫，仅仅辨别接过来的需求；而是去找行得通的解决方式。
一个好的产品团队要理解他们需要解决的深层问题，尝试很多个想法或途径，直到发现这件事确实行不通。股东将会把一个强大的产品团队视为问题的解决者，致力于寻找提供必要结果的方法。
规划 vs 原型设计
有很多工具可以用于构造和计划创造类的工作。我在自己的书里推荐过一些。但是，这些方法需要很敏捷，因为我们的大部分时间需要用来寻找可以实际解决问题的方法。
我经常看到团队花很多时间在评估不同想法和方法的优点（通常被描述为优先级），但实际上没有足够时间去找创意和方法。这里有部分就涉及到了一个核心的产品原则——知道你所不知道的。人们并没有去真正充实这个想法，而是浪费时间在假装他们能够预测到一个想法或方法的效率。真正的学习才刚开始，当我们与设计师合作创造一个原型放在他们面前：1）我们自己；2）使用者；3）工程师；4）股东。
产品经理能力
我之前写过很多次，关于跨职能产品团队与他们的产品经理一样强大，但是作为一个行业，产品经理们还未能胜任。
我总结了产品经理的能力有：深入了解 1）你的使用者和顾客；2）产品的数据；3）行业；4）业务如何运转。
最后一个是我看到的产品经理遇到的最大麻烦。他们对于他们业务的多个方面没有完成必要的学习，市场、销售、服务、金融（回报和支出）、商业发展（特别是合作关系）、隐私性、安全和合规性是最常见的视角。所以结果是，他们不能给团队（特别是设计师和工程师）提供必要的背景和约束，让他们去找到最好的问题解决方式。
道德观与产品经理
今天很少有关于这方面的讨论，我们的行业还没有做到足以阻止破坏商业和社会的坏人。好消息是，而今我遇到的大多数企业中，这成为了一个重要的话题。更普遍地，道德的任务在更多的企业中已经变得越来越明确，虽然它取决于高层领导，但产品经理可以最先在产品中发现其酿成的事件。
处理道德问题从来都不容易，产品经理需要有真正的技能才能与高层领导进行关于潜在问题和解决方法的建设性讨论。如果产品经理对业务的运行方式没有很好的理解，特别是就货币化而言，那么在高层领导中就很难有足够的可信度。这回到了产品经理能力的话题。
作为产品CEO的产品经理
你们知道我一直在推崇这个比喻，特别是强调产品经理理解业务不同方面的重要性。你们可能也知道这个比喻的对立观点是，产品经理决定扮演团队的老板。
最近我撰写和发表了很多关于团队活力的文章，确保每个团队成员足以胜任，而不是混蛋。我逐渐明白，当产品经理是个混蛋时，人们反应很消极。
有些人反驳说，产品经理的角色吸引的不仅是公平分享的混蛋（同样也有很多人这么说CEO），但我相信这是真实的问题，而不仅是产品经理的角色。
【这段翻译得不够确定，可对照下方原文的斜体引用部分。欢迎提出意见哈】
训练产品经理
上面所讲的都是一个观点，产品经理的导师需要加强训练向他们汇报的产品经理。这被长时间视作次要的责任，对很多人而言甚至不是。
我认为，对于每个产品经理、产品设计师、工程师的经理来说，这绝对是最重要的责任。当产品团队没有胜任的成员，我们就需要对他们的经理负责。
我一直推崇一种训练和发展产品经理的工具。但我觉得还有很多我可以和我应该撰写的关于辅导的重要话题，我计划未来的几个月去做。
【原文】
Common PM Problem Areas
by Marty Cagan Nov 30, 2018
Recently I was at a dinner with several product leaders, and I was asked what the most common areas of confusion I encounter in product teams today?
I thought it was a good question, and I described several situations, and judging from their response at least, these seem to be problems they had seen in their organizations as well.
So I thought it would be useful to get these problems out on the table so we can watch for them, and more aggressively and intentionally try to tackle them.
Validating Ideas vs. Discovering Solutions
There is a lot of discussion about the many techniques we have for quickly identifying and testing our assumptions and validating product ideas. Most teams have got to the point where they can usually do this pretty effectively.
Of course, in many organizations, the majority of ideas still come from execs and stakeholders. But now, rather than just proceeding to designing and building, product teams know they have an obligation to make sure they’re not wasting the company’s time and money by building something that fails to solve the underlying problem. So they identify the risk, and craft a test – usually by quickly creating a prototype and getting either qualitative or quantitative feedback on the idea. And no surprise, very often they find the idea is not a good one, so they go back to the stakeholder and report that they aren’t going to build this because the idea was not going to work.
But after doing this several times, pretty soon the stakeholders get pretty frustrated. After all, they are trying to run their part of the business, and getting told “no” all the time gets old quick. Eventually, the stakeholders and execs have had enough and they tell the teams either build this or they’ll find others that will.
What I try to explain to the product teams is that their purpose is not to serve as gatekeeper and just validate the requests that come in; their purpose is to discover solutions that work.
A good product team ensures they understand the underlying problem to solve, and then will try out several ideas or approaches until they discover one that does work. The stakeholders come to view the strong product team as problem solvers, that are committed to finding a way to deliver the necessary results.
Planning vs. Prototyping
There are several good techniques for framing and planning our discovery work. I advocate for several of them in my book. However, they should be quick, because most of our time needs to be going to figure out a solution that actually solves the problem.
I often find teams spending far too much time stressing over evaluating the relative merits of the different ideas and approaches (usually described as prioritization), and not enough time actually trying out the ideas and approaches.
Partly this gets to the core product principle of knowing what you can’t know. I tell people they are wasting their time pretending they can predict how effective an idea or approach might be without actually fleshing that idea out. The real learning happens when we collaborate with our designer to create a prototype and get it in front of a) ourselves; b) users; c) engineers; and d) stakeholders.
Product Manager Competence
I’ve written many times before that cross-functional product teams are only as strong as their product manager, and as an industry we have a real problem with product managers that are not yet competent.
I summarize competence as: deep knowledge of your users and customers; deep knowledge of the data that’s generated about your product; deep knowledge of your industry; and deep knowledge of how your business works.
It’s this last one that I see product managers having the most trouble. They have not done the homework necessary to learn the various aspects of their business – marketing, sales, service, finance (revenue and costs), business development (especially partnerships), privacy, security, and legal are the most common dimensions. So the result is that they’re not able to provide their team – especially their designers and engineers – with the context and constraints necessary for them to come up with the best solutions to the problems they’re tackling.
Ethics and the Product Manager
There is little debate today that our industry has not done nearly enough to prevent bad actors from causing damage to our business and our society. The good news is that now, at least at most companies I meet, this is a much more prominent topic than it was. More generally, the role of ethics is now becoming an explicit topic at more companies, and while this falls primarily on the company’s senior leadership, the product managers are often the first to see the brewing issues in the products being created.
Dealing with ethical issues is never simple, and it takes some real skills for a product manager to have constructive discussions with senior leadership about potential problems and solutions. If the product manager does not have a strong understanding of how the business works – especially in terms of monetization – then they simply don’t have the necessary credibility with senior leadership. This gets back to the PM competence topic.
Product Manager as CEO of the Product
Many of you know that I’ve been advocating this metaphor especially to emphasize the importance of the product manager understanding the different dimensions of the business. You probably also know that the main objection to this metaphor is the product manager that decides to act like the boss of the team.
Recently I’ve been writing and speaking more about team dynamics and the need to ensure that every member of the team is both competent and not an asshole. What I’ve come to realize is that what I think people react negatively to is when the PM is an asshole.
Some have argued that the PM role attracts more than its fair share of assholes (and the same has been argued about the CEO), but I’ve come to believe that’s the real issue, and not so much the PM role.
Coaching Product Managers
All of the above is really an argument that the directors of product management need to significantly step up their game in terms of coaching the product managers that report to them. This has for too long been viewed as a secondary responsibility, and for many, not even that.
By my reasoning, this is the absolute top responsibility for every people manager of product managers, product designers, and engineers. And when product teams don’t have competent members, it is their managers that we need to hold accountable.
I have long advocated a tool for the purpose of coaching and developing product managers.But I think there is much more that I can and should write about this all-important topic of coaching, and I plan to do so in the coming months.