做产品，你必须要知道的那些套路.docxVIP

做产品，你必须要知道的那些套路 PAGE 5 做产品，你必须要知道的那些套路 在平时的产品设计过程中，我们会面对琳琅满目的需求，在面对这些需求时，我们需要一个产品套路，对需求进行快速地分析和决策。产品设计中一个重要的套路就是：采用什么方法去解决谁的哪些问题。在这个产品套路中，涉及到三个重要的要素，即：谁的，什么问题，采取什么解决方案。产品的利益相关者利益相关者，不仅仅是用户。首先，“谁的”是要了解需求背后的主体。每个产品背后都会有多个利益相关者，也就是我们常说的 涉众。我们平时工作中最容易想到的利益相关者可能就是产品的使用者，即用户 ；但对于产品经理来说，我们不能只关注用户，我们要能看到并且平衡利益相关者有多少，对他们的了解有多深。比如，在医疗领域，利益相关者会包括患者、医生、医院、药企，甚至还包括一些学会和科研机构等等。再拿我现在负责的项目（为电视台用户提供一些播出素材模板的平台）举例，所涉及到的利益相关者包括电视台机构、合作提供制作素材模板的企业、普通的制作广电素材爱好者以及我司内的销售、财务、客服部门等，这些都是需要关注的利益相关者。除此之外，当评估产品的效率和盈利时，我们还要学会站在投资者的角度去看问题，从投资者角度所关注的具体指标去看产品以及服务。这里的投资者关注的或许不仅仅是财务指标，还有整个产品的健康程度和存续指标等相关指标。比如一款工具产品的日启、日活、留存、传播，或者一款社区型产品的用户数量，用户活跃度等。除了这些容易被漏掉的利益相关者之外，我们最需要关注的依然是用户本身。我们经常提到产品经理要具备“共情能力”，其实指的就是对用户偏好和痛点的深刻理解，理解他们的关注点，并把这些变成指标。不论是用户还是其他利益相关者，我们需要了解他们对哪些事情最为关心，不同的角色所关心的指标或许会有关联，甚至有矛盾，我们要在其中做出平衡和决策。解决什么问题重视要解决的问题。产品要解决的问题，都应该围绕着某一个或某几个利益相关者的具体问题来展开。我们通常在这里投入的精力和时间是不够的，大家更喜欢花时间在解决方案上。映射到我们的日常工作中，产品经理接到的需求通常并不是真正意义上的“需求”。而是提需求的人，针对于某一个需求提出的“解决方案”。这样做并不妥，应该在理解是哪个利益相关者的问题，具体是什么问题之后，才去想解决方案。举一个例子，比如我们接到了用户的产品反馈，“希望增加一个收藏的功能”。如果我们此时只是拿到这个所谓的需求，画个原型，让开发做出来，那么我们顶多是一个需求翻译的机器，而不是一个产品经理。那么正确的做法是什么？正确的做法应该是：把类似所谓的“需求”当做一个线索，抓住这个线索不断地向上追问背后的需求动机和需要被解决的问题。挖掘需求背后的需求，就是穿过解决方案抵达问题的本质。还是拿收藏举例子，不同类型产品的收藏功能背后要解决的问题是不同的，浏览器的收藏可能是为了重复的访问，所以演化为了书签；阅读类产品的收藏可能是为了日后的检索查阅，所以需要具备标签和检索功能；社区类产品的收藏会有聚合功能，所以很多社区的收藏增加了发布和分享的功能，提供了另一种UGC和粘合新用户的方式。深度融入产品的使用场景。场景的概念在理解所有利益相关者的需求动机，尤其是用户的需求动机的过程中是十分重要的。在考虑需求时，不应该只是独立地考虑功能逻辑，而是要把这些功能和流程放到具体的用户使用场景里面去。把需求放在场景中最好的方式是在脑海中把所有的功能过程演一遍，把自己充分地带入到场景中，触达到每个细节。考虑具体利益相关者的情绪、关注点、好恶，以及所处的环境，所用的终端等等。我们要成为产品的重度用户，当我们成为自己产品重度用户后，就不会需要演的过程，不需要“带入”“模拟”或者“共情”之类的过程，便可以全然沉浸在产品的使用场景中从而发现和理解问题。问题的解决方案解决方案是一个产品设计者的最终输出，你的一切思考、平衡和执行，都会在这里被体现出来。出解决方案是产品经理硬技能被提及最多的地方。比如会不会用 Axure，会不会用 Photoshop，懂不懂用户研究，能不能写出漂亮的文档，以及用各种工具来分析流程、逻辑关系等等。我们设计的方案既包括流程上的、逻辑上的，也包括交互和体验上的。提高出方案能力的最好方法就是大量把玩各种各样的互联网产品和服务。但要注意一点，这个把玩的过程不应该是随便用一下、体验一下就完了。我们需要通过看到的特性就能理解背后的问题、用户，尽可能地去抽象考虑同样的问题还有哪些不同的方案。经常去想一想，如果我是这款产品或服务的产品经理，如何去提升现有方案。见得足够多了，理解得足够透彻了，自然出解决方案的能力也就相应地增强了。互联网产品经理主要是