【作者】流年

【来源】人人都是产品经理

【编辑】善小倩

产品设计中一个重要的套路就是：采用什么方法，去解决谁的哪些问题。在这个产品套路中，涉及到三个重要的要素，即：谁的，什么问题，采取什么解决方案。

 

一、产品的利益相关者

 

利益相关者，不仅仅是用户。

 

首先，“谁的”是要了解需求背后的主体——每个产品背后都会有多个利益相关者，也就是我们常说的 涉众。

 

我们平时工作中最容易想到的利益相关者可能就是产品的使用者，即用户 ；但对于产品经理来说，我们不能只关注用户，我们要能看到并且平衡利益相关者有多少，对他们的了解有多深。

 

比如，在医疗领域，利益相关者会包括患者、医生、医院、药企，甚至还包括一些学会和科研机构等等。

 

再拿我现在负责的项目（为电视台用户提供一些播出素材模板的平台）举例，所涉及到的利益相关者包括电视台机构、合作提供制作素材模板的企业、普通的制作广电素材爱好者以及我司内的销售、财务、客服部门等，这些都是需要关注的利益相关者。

 

除此之外，当评估产品的效率和盈利时，我们还要学会站在投资者的角度去看问题，从投资者角度所关注的具体指标去看产品以及服务。

 

这里的投资者关注的或许不仅仅是财务指标，还有整个产品的健康程度和存续指标等相关指标。比如一款工具产品的日启、日活、留存、传播，或者一款社区型产品的用户数量，用户活跃度等。

 

除了这些容易被漏掉的利益相关者之外，我们最需要关注的依然是用户本身。

 

我们经常提到产品经理要具备“共情能力”，其实指的就是对用户偏好和痛点的深刻理解，理解他们的关注点，并把这些变成指标。

 

不论是用户还是其他利益相关者，我们需要了解他们对哪些事情最为关心，不同的角色所关心的指标或许会有关联，甚至有矛盾，我们要在其中做出平衡和决策。

 

二、解决什么问题

 

重视要解决的问题。

 

产品要解决的问题，都应该围绕着某一个或某几个利益相关者的具体问题来展开——我们通常在这里投入的精力和时间是不够的，大家更喜欢花时间在解决方案上。

 

映射到我们的日常工作中，产品经理接到的需求通常并不是真正意义上的“需求”。而是提需求的人，针对于某一个需求提出的“解决方案”。

 

这样做并不妥，应该在理解是哪个利益相关者的问题，具体是什么问题之后，才去想解决方案。

 

举一个例子，比如我们接到了用户的产品反馈，“希望增加一个收藏的功能”。

 

如果我们此时只是拿到这个所谓的需求，画个原型，让开发做出来，那么我们顶多是一个需求翻译的机器，而不是一个产品经理。

 

那么正确的做法是什么？

 

正确的做法应该是：把类似所谓的“需求”当做一个线索，抓住这个线索不断地向上追问背后的需求动机和需要被解决的问题。

 

挖掘需求背后的需求，就是穿过解决方案抵达问题的本质。

 

还是拿收藏举例子：

 

不同类型产品的收藏功能背后要解决的问题是不同的：

 

• 浏览器的收藏可能是为了重复的访问，所以演化为了书签；

• 阅读类产品的收藏可能是为了日后的检索查阅，所以需要具备标签和检索功能；

• 社区类产品的收藏会有聚合功能，所以很多社区的收藏增加了发布和分享的功能，提供了另一种UGC和粘合新用户的方式。

 

深度融入产品的使用场景。

 

场景的概念在理解所有利益相关者的需求动机，尤其是用户的需求动机的过程中是十分重要的。在考虑需求时，不应该只是独立地考虑功能逻辑，而是要把这些功能和流程放到具体的用户使用场景里面去。

 

把需求放在场景中最好的方式是在脑海中把所有的功能过程演一遍，把自己充分地带入到场景中，触达到每个细节。

 

考虑具体利益相关者的情绪、关注点、好恶，以及所处的环境，所用的终端等等。

 

我们要成为产品的重度用户，当我们成为自己产品重度用户后，就不会需要演的过程，不需要“带入”“模拟”或者“共情”之类的过程，便可以全然沉浸在产品的使用场景中从而发现和理解问题。

 

三、问题的解决方案

 

解决方案是一个产品设计者的最终输出，你的一切思考、平衡和执行，都会在这里被体现出来。

 

出解决方案是产品经理硬技能被提及最多的地方。比如会不会用 Axure，会不会用 Photoshop，懂不懂用户研究，能不能写出漂亮的文档，以及用各种工具来分析流程、逻辑关系等等。

 

我们设计的方案既包括流程上的、逻辑上的，也包括交互和体验上的。提高出方案能力的最好方法就是大量把玩各种各样的互联网产品和服务。

 

但要注意一点：

 

这个把玩的过程不应该是随便用一下、体验一下就完了。我们需要通过看到的特性就能理解背后的问题、用户，尽可能地去抽象考虑同样的问题还有哪些不同的方案。

 

经常去想一想，如果我是这款产品或服务的产品经理，如何去提升现有方案。

 

见得足够多了，理解得足够透彻了，自然出解决方案的能力也就相应地增强了。

 

互联网产品经理主要是做产品的功能设计，所以有的时候会本能地想通过增加功能解决一些问题，其实我们还要学会通过改变业务规则、流程去解决问题。

 

比如，优化退货流程体验这样的具体需求，我们可以经过一些基本的数据分析后，去承担一些潜在的业务方面的风险，可以去研究一下各大平台的退货流程，有很多都是通过业务手段去优化体验的。

 

比如，高等级的用户闪电退货，或者星级合作企业享受优先退货处理等之类的功能。

 

这样的优化不是通过把退货页面设计得更简洁更美观，或者减少提交退货的操作步骤之类的功能完成的，而是抓住了退货流程的体验核心，用业务的方式解决问题。

 

技术——互联网产品的铸造工艺。

 

作为产品经理，对技术知识的了解在一定程度上也支撑着我们给出具体的解决方案。就像工业设计师要了解基本材料的铸造工艺一样，我们也应该了解必备的互联网技术知识。

 

我们应该知道，自己的设计方案，从无到有是经历怎样的过程的。

 

比如，我们在界面上设计了商品的列表，包括排序、筛选的功能。

 

我们应该清晰的知道如下内容：商品的属性包括那些，商品的数据来源，商品数据如何进行更新维护以及更新维护的方式，商品排序的字段内容，商品筛选的字段内容。

 

除此之外，我们还应该明确的知道，排序功能的实现方式：在数据库的商品表中增加要排序的字段，比如浏览量，每次进入商品详情页时浏览量字段数值+1，当用户点击“按浏览量排序”时，执行SQL语句，按照从高到低对商品进行排序。

 

筛选功能的实现方式：在数据库的商品表中增加筛选的字段，比如VIP商品，并且默认值为0（非VIP），用户点击“VIP商品”时，执行SQL语句，在商品表中查询出VIP字段值为1的商品显示在界面上。

 

四、总结

 

总结一下，做产品的一个套路就是：采用什么方法去解决谁的哪些问题。

 

在“谁的”部分，我们要考虑到所有的利益相关者的需求；在“什么问题”部分，我们要深入挖掘需求背后的需求，同时要学会深入产品的使用场景；在“解决方案”部分，我们要学会通过业务的手段去解决问题，不局限于做功能，同时也要掌握一些基本的互联网技术知识。