如果您是产品经理，或者您自己可能正在扮演产品经理的角色，那么在某些时候，您可能需要向不太熟悉该领域的人解释您的工作…
正好，这里有一个适合所有朋友的产品管理定义。
什么是产品管理？定义
用最简单的术语来说……
产品管理正在决定下一步要构建什么。
产品的存在是为了解决世界上的问题。这适用于实体产品，如滑板，以及数字产品，如微信、QQ。这些问题不只是漂浮在以太坊中。它们是现实中的人们所面临的问题。因此，为简单起见，我们将它们称为用户需求。
用户需求包括功能需求，比如我需要准时上班，或者情感需求，比如我需要得到朋友的尊重。
实际上，满足用户需求的是产品的功能。滑板的轮子允许它运送它的主人。特斯拉的美丽而自信的轮廓让拥有一个人感觉像是一种自我表达的形式。
数码产品也不例外。奶奶有协调与孙子孙女聚会的功能需求，因此她屈服并注册了微信。（经过 5 小时的培训，她学会了让添加好友，并成功发送了她的第一条文字消息。与此同时，她的孙子孙女有一种被同龄人接受的情感需求，可能会选择通过在社交媒体产品上培养在线角色来实现这一目标，这些产品的功能是专门为该任务量身定制的。
物理产品与软件的主要区别在于，它们的功能必须在销售之前很久就确定下来。软件，尤其是网络应用程序和移动应用程序，总是随着新特性和功能的增加而不断发展，以供用户使用。在这种情况下，特别公平地说，产品经理的工作是决定接下来添加哪些特性和功能。
所以下次当你向朋友解释你的工作时，你可以说：“你知道抖音是如何把你的脸变成各种特效的吗？只有当产品经理认为这是一个好主意，并付出血汗和泪水带领一群人（即设计师和工程师）将其变为现实时，才有可能实现这一功能。”
当你刚被朋友插话说：“产品经理如何决定一个功能是否是一个好主意？”时，你甚至会知道该说什么？
我回想起国外一本书中看到这样对产品管理的定义：
“产品管理就是发现有价值、可用且可行的产品。”
好的，如果产品（及其包含的功能）有价值、可用且可行，那么构建它们是一个好主意：
- 价值在于他们必须解决某人的需求
- 可用，因为人们必须能够在不放弃的情况下学习如何使用它们，并持续使用它们而不会感到沮丧
- 可行，因为新功能不需要太多资源（时间、金钱、精力、物理材料），否则产品背后的公司将破产（或在市场上被更精明的竞争对手击败）
总而言之，产品经理决定下一步要构建什么，他们通过确保他们构建的功能有价值、可用和可行来做到这一点。我们将在接下来的部分中探讨其中的每一个。
产品经理决定下一步要构建什么，他们通过确保他们构建的功能有价值、可用和可行来做到这一点。
我们还将研究产品经理的其他一些职责，这些职责使这个角色变得如此多面、如此容易被误解、如此有趣。
了解用户需要什么
在产品经理决定下一步要构建什么功能之前，他们通常首先考虑什么对他们产品的用户（和潜在用户）最有价值。为此，他们必须深入了解用户的需求。请记住，需求可以是功能性的，也可以是情感性的，所以这比听起来要难。
考虑到我们经常不了解自己的需求这一事实。我们为从未使用过的订阅和实际上并没有让我们变得更好的产品（你去年穿过的那件漂亮的毛衣）支付了大量的钱。与此同时，我们每天都在使用的一些新产品我们从来不知道需要什么。
产品管理就是在问题（用户需求）和解决方案之间架起桥梁。产品管理工作的核心职责是深入了解问题的一面，以决定最佳解决方案。几乎总是有许多可能的解决方案，因为解决方案有许多不同的形式。它们不仅仅是精美的抛光产品。有时它们是用户为自己设置的解决方案（例如手写的购物清单）。如果您是开发智能购物清单应用程序的产品经理，它至少需要与自制解决方案一样好。事实上，如果您希望人们不遗余力地发现它、学习如何使用它、支付它并养成在计算机上使用它的习惯，它可能需要 2 倍、5 倍或 10 倍。定期。
产品管理就是在问题（用户需求）和解决方案之间架起桥梁。
花点时间让这个想法深入人心：对于每个问题或需要，都有一些解决方案，在开始尝试解决之前确定您正在解决的问题很重要。这似乎很明显，但这是大多数业余产品经理（甚至许多有经验的产品经理）迷失的第一种方式。我们人类倾向于关注解决方案（例如新的 PDF 导出功能），因为它们非常具体。我们可以想象它们的样子，以及它们将如何工作。它们比用户 需要的模糊和抽象的概念更容易让我们思考（比如需要与我的老板共享数据）。但要注意过早地关注解决方案！即使用户请求导出 PDF 以与他们的老板共享数据，他们后来也可能同意将其作为嵌入在电子邮件中的折线图 PNG 发送会更好。只有正确分离问题和解决方案才能让您有机会发现这一点。如果不这样做，就有可能提供一个次优解决方案，或者一个最终根本不会被使用的解决方案——即使您完全按照用户的要求构建了！考虑到您的团队即使在开发最小的功能（更不用说可能需要数月的工作和数千工时的新界面）上付出的努力，当 PM 花时间仔细分析用户需求时，每个人都会获胜。
稍后我们将更多地讨论 PM 在确定、设计和开发最佳解决方案的过程中的作用，但现在的关键问题是……
数字产品经理如何确定用户真正需要什么？
最好的产品经理经常从事以下所有活动：
- 设置系统和流程来收集传入的用户反馈：无论您的团队使用QQ、微信、邮箱还是其他工具与潜在客户和客户沟通，他们都有可能以您的方式自愿发送反馈。PM 负责建立系统以积极寻求这种反馈，并收集和分类功能请求、改进想法、错误报告、可用性投诉、问题、建议的黑客和解决方法，以及对现有功能的好评。关键是对用户提供的这些黄金洞察进行分类，这样他们就不会迷失在团队中各个产品经理的电子表格、收件箱或印象笔记中。
- 从面向客户的同事那里收集见解：谁比在营销、销售和支持方面花费所有时间与他们一起工作的同事更了解您的用户？鼓励他们收集功能请求并提出探索性问题，以便他们可以报告用户的潜在需求。通过这种方式，它们就像您的用户研究团队的延伸。
- 走出大楼：在自然环境中采访用户，观察他们现有的解决方案，观察他们的日常生活，并直接研究他们的痛点。
- 在用户面前验证你的想法：一旦你对用户的需求有了一些了解，模拟简单的解决方案——甚至草图或纸上原型都可以——然后问“这能解决你的需求吗？” 这里的目标是使用潜在的解决方案来确定您是否正确理解用户真正需要什么。
- 采访你失去的用户：当用户离开你的产品使用其他解决方案时，或者决定不首先成为客户时，问问他们为什么。他们更喜欢什么解决方案？哪些特征（或缺乏特征）对他们的决定影响最大？您的产品中是否缺少某些破坏交易的东西？
好的，您已经收集了反馈、记录了采访、验证了想法并进行了一些损失分析。您甚至发现了一些围绕用户真正需要的趋势。但肯定有很多需求。这本身就存在问题......
数字产品经理如何跟踪用户需求？
可悲的是，许多人没有。现状是将此类信息保留在您的脑海中，尽管这几乎不可能确定不同用户所拥有的微妙而复杂的需求重叠。
更常见的情况是，产品经理在冗长的功能待办事项列表中捕捉解决方案想法（将解决这些需求）——你有一天想要开发的功能列表——通常存储在电子表格、任务管理工具（例如 Trello、Asana）中，或开发计划工具（例如 JIRA、Pivotal Tracker）。如果您还没有注意到这个问题，如果您所做的只是捕捉解决方案的想法，那么您就有可能得出结论。很多时候，在你确定它应该解决什么问题之前，你会专注于一个特定的解决方案想法。这就是为什么拥有一个适当的系统来记录您希望解决的用户需求以及在它们之下的相关解决方案想法（功能想法）如此重要的原因。
即使您开始捕捉功能创意，在这个阶段保持高水平仍然是值得的。正如我们将在下面讨论的那样，用户体验设计师和工程师专注于为您认为最有价值的问题开发最佳解决方案。试图为他们做他们的工作并不能很好地利用你的时间和专业知识。它还可能会给您的团队带来不必要的压力，并导致解决方案欠佳。
决定构建什么（并计划何时构建它）
到目前为止，我们已经根据用户的需求仔细研究了确定哪些功能最有价值的过程。现在我们将更多地了解产品经理的其他核心职责：确保功能可用且可行。
一旦您组织了您有兴趣解决的用户需求并产生了一些功能创意，您就需要开始决定构建什么。此阶段称为功能优先级。如果您考虑对数百个甚至数千个功能进行优先排序以决定下一步要构建哪些功能，这似乎非常令人生畏。这就是为什么优先排序最好随着时间的推移而不是在单个会话中完成。
产品经理在确定构建内容的优先级时会考虑什么？
以下是一些提示，可帮助您在确定下一步构建的优先级时为成功做好准备：
定义您的目标用户：大多数产品服务于许多不同类型的用户，其需求和目标略有不同。提前决定你的目标用户群是谁——对你的产品的成功最重要的用户群。你不能让他们都满意！当迫在眉睫时，如果您能做出优先级决定会更好，因为它们最适合您的目标用户，即使这样做意味着放弃其他人的需求。
专注于具体目标：除了功能如何满足不同类型用户的需求之外，构建某些功能也有战略原因。也许新的入职流程不是很受欢迎，但这是推动产品购买的绝佳机会。或者，您可能决定将工程精力花在增长黑客上，以帮助现有用户从他们的网络中邀请其他人开始试用您的产品。提前决定您将使用什么标准来评估功能创意。现在对您的产品和您的公司最重要的战略是什么？留住现有用户？获取新的？提升用户体验？提高平台可靠性？您的目标可能会因季度而异，
分阶段确定优先级：在初始阶段，您可以根据用户本季度最常请求的内容对您的功能创意进行排序。这可能会帮助您了解有多少想法与帮助用户更快地掌握您的工具相关，这反过来可能会激发本季度改进入职培训的举措。反过来，这将帮助您将目光投向支持此目标的其他功能。
验证你的假设：即使某些功能创意被优先考虑为候选者——你正在考虑构建的重要功能——将它们直接发送给设计师和工程师开始工作也是不明智的。执行高保真设计和编写生产代码需要团队中高技能成员的时间密集型工作。最好采用您正在考虑使用的功能并由客户首先运行它们 - 特别是那些首先要求它们的人。他们还需要这些功能吗？您是否正确理解他们的需求？他们是否设想了与您相同的最终解决方案？如果存在差异，是否表示误解了潜在需求？在开始研究某个解决方案之前，尝试回答所有这些问题。
冠军 将 用户的 需求：最终，产品经理和用户体验设计师（或‘交互设计师’）共享的深刻理解用户需求的责任，并确保任何提议的解决方案将使用给定用户的背景知识，技能，和经验。这通常涉及用户测试特定的解决方案想法，以确保用户轻松了解他们的工作方式。这通常可以在编写一行代码之前在原型上完成。产品经理应尽可能参与此过程，因为与工程和营销方面的其他同事共享用户上下文通常是您的责任。
知道何时将您的优先排序过程置于现实中：在深入了解您正在解决的问题之前，从工程团队的代表那里寻求特征复杂性估计会适得其反，但是一旦您将它们缩减为少数几个以进一步研究（这个过程通常称为产品Discovery），您将准备好生成特定的解决方案想法。这意味着您团队的技术成员将能够评估每个人的开发难度。这并不总是非黑即白。经常会附带一些意外情况。（例如工程师：“如果我们在开发此新功能时必须支持 Internet Explorer，则需要 2 个月。如果我们不支持，则需要 2 小时。”）关键是要明确权衡，以便您知道何时走捷径，何时进取构建复杂功能，
熟悉流行的产品优先级框架：有许多不同的方法可以确定最重要的标准并使用它来评估要构建的功能。例如，RICE规定了一个特定的公式，用于根据预计的覆盖范围、影响、努力和置信度来判断功能优先级。另一种思想流派支持Kano 模型，它将功能分为满足基本需求的功能（如果您的产品不提供这些功能，可能会破坏交易）与积极取悦用户的功能。
与设计人员和开发人员清楚地交流上下文和约束：当产品经理准备将功能发送到开发中时，确保设计人员和开发人员了解他们正在构建的内容及其原因很重要。这意味着对于每个功能，产品经理必须传达以下详细信息：
- 战略目标
- 需要解决核心用户（和目标用户群）
- KPI（如果此功能成功，将移动什么指标以及移动多少？）
- 功能启用的用户场景
- 约束、要求和其他成功标准
传统上，此信息以功能规范（或“规范”）的形式呈现。值得补充的是，近年来这种方法受到了一些反对。太多的产品经理将规格视为与团队沟通的最终目的，即使他们缺乏帮助设计师和开发人员了解他们正在解决的真实用户需求的关键背景——真正的原因在他们正在研究的功能背后。从产品到工程的“把规格扔在墙上”的过程也有一些不人道的东西——用几十（甚至几百）页来详细说明需求，而没有让工程师站在用户面前，用他们自己的眼睛看到相关的需求。当然，工程师不可能采访每个用户，但有一个快乐的媒介，其中规范清晰详细，但点缀了更多用户上下文，所有团队成员都花更多时间与最终用户互动。
PM 如何计划何时构建和启动功能？
分阶段发布以最大程度地降低风险：有时可以自行构建功能并为用户提供很多价值。这可能是高度要求的特定功能的情况。其他时候，如果您要以更实质性的方式推进您的产品，则必须一起开发和发布互补功能。例如，您可能会开发一个由许多功能组成的全新界面，以满足管理员用户角色的需求，他们需要能够更好地管理组织中的用户，以便他们成功使用您的产品。需要一个全新的管理控制台来帮助他们在基本级别管理他们的产品。
在后一种情况下，我们已经超越了一次性功能优先级来评估整个计划。这是一个棘手的领域，因为它要求团队在对用户进行测试之前冒着投入大量精力开发许多功能的风险。始终尝试通过开发和启动尽可能小的功能组来最小化这种风险——即使这是更大计划的一小部分。这样，您将尽早开始收集用户的反馈，并且如果您学到一些令人惊讶的东西（例如，管理员实际上并不需要审计日志，如果有更好的版本控制，他们可以在没有它的情况下工作）。您始终可以通过稍后发布功能的后续阶段来完成计划。最小可行产品。它是精益方法的核心，适用于优先级和计划的几乎所有方面。
调整你的团队
到目前为止，我们已经回顾了产品经理如何负责确保产品有价值、对用户有用和可行建立。虽然大部分工作都是预先进行的，但一旦将特性规范发送给工程部门，产品经理的工作就不会完成。开发一开始，围绕基于用户需求设计特定功能的最佳方式就会出现一系列问题。即使是有史以来最好的书面规范也无法涵盖所有意外情况。产品经理的工作是在产品设计和交付过程的每一步都支持用户的需求，确保成品满足用户的需求、按时发货并成功推出。同样，产品经理还必须清除不可预见的障碍和障碍，以便团队在将新功能带入生活的同时尽可能提高工作效率。
请注意，此执行阶段与项目管理最相关，这门学科听起来可能类似于产品管理，但实际上只是其中的一部分。毕竟，产品经理必须在管理交付过程之前了解用户的需求并决定构建什么。项目管理本身仍然可以是一个专业领域，一些组织聘请项目经理（专注于执行）与产品经理（专注于优先级）一起工作。但在大多数组织中，产品经理仍然负责从项目管理到功能发布，并确保所有团队成员都对构建该功能的原因保持一致。
