站在用户产品经理理角度分析——针对青年用户,本产品有什么更好的修改意见

来源：蜘蛛抓取(WebSpider) 时间：2020-08-13 09:30 标签： 用户产品经理

用户产品经理理的工作目的就是為了讲好一个故事让听者信服，如果故事没有说好就容易变成事故。

对于用户产品经理理而言我们需要向不同角色的人讲述一个需求，可能是老板可能是研发，可能是运营也可能是你的投资人， 在沟通中你有没有这样的经历：为什么对方就是不明白“这么简单嘚一件事情”？这头你急得直跺脚那头听你说话的人依旧是一头雾水。

比如你如何去叙述“分享到朋友圈”这个功能呢你会怎么描述這个需求呢？是不是需要一个分享功能让用户分享到朋友圈吗？当我们看到某篇文章时非常喜欢这篇文章，希望把有帮助或者有趣的信息推荐给朋友但是，如果这需要我们很费力地复制粘贴那么大家可能就不愿意这么做了，因为实在太麻烦了当朋友看到一长篇密密麻麻的文字时，也会疑问发的是什么东西。这样的话我们需要一个分享功能，能够直接非常简单地将某篇文章传递给朋友并且他們看到的，和我们看到的是一样的

所以，分享至朋友圈并不是一个需求，而是两个①分享出去②能够在外部被访问。

很多时候我們沟通不顺畅的原因，不是因为不明白做什么而是不明白为什么要做，怎么做在产品里，基本不存在完全独立的功能每一个功能之間必然会和其他的功能产生呼应，这一点会直接反映到我们的需求里对于分享而言，研发并不是不知道如何做分享而是不知道，为什麼做在哪里做，怎么做互联网团队里，每一个人都是具备创造性思维的不仅仅是产品而已，切勿将研发或者其他环节的角色定义为執行机器

一个完整的需求故事，会遵循一些原则：

除了必要的描述尽量避免多余的叙述，这会干扰大家的思绪产生不必要的争论。避免不确定的词汇比如，可能也许，这会让他人感觉这个需求是不确定的故事完整，这是避免需求衍生的核心点如果无法对你的需求故事进行提问，这就是最好的故事了一个完整的故事，是指听故事的人能够从头看到尾，而不产生疑问似乎一切就如故事里讲述的那样，顺理成章

user： 故事的主人公是谁

scene： 故事的背景是什么

want： 他想要什么

我们再来看看，关于分享至朋友圈的需求故事：

scene：当我们看箌某篇文章时非常喜欢这篇文章，

want：希望把有帮助或者有趣的信息推荐给朋友传递给自己的朋友。

defect：如果这需要我们很费力地复制粘貼那么大家可能就不愿意这么做了，因为实在太麻烦了朋友在看到一长篇密密麻麻的文字时，也会疑问发的是什么东西。

action：我们需偠一个分享功能能够直接非常简单地将某篇文章传递给朋友，并且他们看到的和我们看到的是一样的。

用户产品经理理还会经常遇见這样的场景：对方会不断的向你提问目的在于索要更全面的信息，而这个过程中我们会展开原本不必要的争论。避免这个情况的办法呮有一个完整的向对方描述一个故事，让沟通能够基于故事本身而展开而不这是一个很小的需求沟通技巧，但却不仅仅是被应用在这樣的场合里通过设计需求故事，也能让我们更清晰用户想要的是什么

很多用户产品经理理在做需求分析这一步时，由于没有一套合理嘚知识结构导致很多时候需求分析变成了空想问题，从下面2步入手让你的需求分析时更加专业化。

1.无针对性的用户访谈

一般来说特萣的用户是主要需求的提出者，而产品设计是为特定用户服务在这种情况下，我们有机会与特定用户进行深度的沟通如果特定用户不圵一个，一定要区分“最终拍板的用户”和“产品的直接用户”通过区分用户身份，理清楚用户需求和产品需求

明确用户想要什么，洏不是用户想做成什么

用户想要什么，是用户的原始需求；而用户想做成什么是用户将原始需求经过自己的理解得到的需求。所以茬你提出一个问题的时候，不妨再加上一个为什么往往会起到意想不到的效果。

使用通俗的语言避免专业词语

如今社会，每个人都对互联网有不同程度的了解作为用户你无法预估他的专业程度。在访谈过程中用户产品经理理要尽量用通俗、严谨的语言去谈话而不是┅堆专业词语去显示自己的专业度。一旦用户的理解有偏差你收集的需求将会把你引向歧路。

头脑风暴是比较常见的需求收集方式作為用户产品经理理，你更多的起到监督和控制的作用

第一，确保会议围绕你提出的话题展开而不是漫无边际地聊天。

第二不要对任哬一个人员提出的话题进行评价或者议论。

最后控制时间、控制时间、控制时间。

用户反馈分为主动反馈与被动反馈两种

用户在客服、官方微博、QQ群、贴吧、论坛、留言板、投诉等场合提出的意见都可以算是主动反馈；而调查问卷、有针对的用户访谈、用户回访等方式昰被动反馈。

一般来说主动反馈属于更紧急需求，被动反馈属于重要需求并可以以此来定义优先级。

4.内部需求（领导、运营、运维、愙服）

一般来说用户产品经理理是对产品结构、流程最熟悉的人，面对内部需求你需要做的是明确需求提出的目的，并提供解决方案

数据是客观反映产品的重要指数，也是收集需求的重要来源前期是收集的数据是可靠、客观的。数据是零散的在进行数据分析前一萣要有明确的中心，划定一个界限收集同一个框架内的数据。单独的数据是死的有对比的数据才有意义。为了避免主观意识的影响哃一份数据参考其他人员的分析结果。

处理需求的阶段也是用户产品经理理将需求进行筛选，梳理业务流程设计产品架构的阶段。

尽管我们保持严谨的态度收集大量的需求其中还是有很多需求是“伪需求”，甚至是不合理的我们第一步就需要将这些需求进行“清洗”，择优去重、去伪存真

由于在这个阶段，用户产品经理理不仅要定义目标用户、产品使用场景还要确定核心功能，产品流程等等洇此通过竞品来辅助处理需求是一种很有效的方法。通过相似竞品的用户定位、功能反推竞品的需求与自己的需求进行对比；将自己的需求代入竞品中，看流程是否符合逻辑；与竞品进行对比分析需求的异同。

一般来说从需求类型来看，基本型需求>期望型需求>兴奋型需求；

从需求来源来看战略性需求（领导提出）>功能性需求（核心功能）>业务性需求（拉活、存留）>体验性需求（提升用户体验）。做恏最常用的是用四象限法则去评定优先级另外可以使用RICE评定方法，KANO模型等

在这个阶段之前，作为用户产品经理理对于产品应该有了一個完整的模型但仅仅是理论上的模型，确保UI、UE、前端开发、后台开发、测试参与从产品开发流程的各个角度对需求进行拆解、分析。需求评审可以看做是产品开发的初始化或者预开发

迈向一名合格用户产品经理理的第一步，就是说好需求故事一款产品能否走得远、赱得好，关键就是这点是否做了足够充分、足够深入的准备

很多企业的用户产品经理理在打慥超级产品过程中都有一个习惯那就是看到别人家的好产品，总会想方设法去体验一番无论是视觉、交互、体验或者是颠覆了整个行業的模式也好，保持好奇和勇于尝试都是打造超级产品的基础

正是因为看过太多好的产品，体验过不同的设计因此，用户产品经理理茬打造超级产品的时候才会胸有成竹从而明白，用户的需求多种多样只有走到用户身边，挖掘到他们的真正需求才能做出他们最需偠的产品，在一个需求或一个痛点上想出最有价值的解决方案满足不同用户的需求。

其实很多用户产品经理理并不知道该如何打造超級产品，在这里我们可以使用一个方法：“吃狗粮”换句话说就是体验自己的产品，然而很多用户产品经理理在体验完自家产品后，吔只能给出模糊的评价：

1）这款产品还挺好用的

2）这款产品将颠覆市场。

3）这款产品简直糟糕透了

4）这款产品的功能是怎么回事，一點用都没有

看到这些评价，我们会发现模糊的评价对于一款产品而言并不公平很多用户产品经理理并没有意识到，也许正是因为不够鼡心去体验产品所以会用一些借口来为自己辩护。想要打造超级产品是不能找借口的。

无论是哪种分析背后必定存在着一个目的，圍绕着这个目的进行展开的一系列行动正是企业所需要收集的或使用的方法，因此不同的分析思路会有所不同。

想要分析用户需求艏先得确定核心用户群体，其次挖掘用户需求然后提高用户体验，这些是引导企业造就超级产品的动因在这个时候，确定核心用户群體、挖掘用户需求、提高用户体验就是企业的目的

一般情况下，分析用户需求的目的可归纳为这几种：

1）分析这款产品对用户的影响

2）汾析这款产品模式用户是否认可

3）分析这款产品是不是针对用户痛点进行的。

4）分析这款产品有没有为用户带来价值

在这个时候，用戶产品经理理会意识到一个被忽略的问题挖掘用户需求要保持客观、公正、独立的第三方评价，这样得出的结论才具有参考的价值而佷多时候用户产品经理理会带着“自以为是”去进行挖掘用户需求，很容易为了证实自己的主观而往其他方向进行分析但实际上，不够公正客观的分析是没有任何意义的。

在产品推向市场之前自己先体验一遍产品。

体验之前用户产品经理理需要注意：需要在这款产品的使用场景下模拟产品核心用户的行为，并把自己当成用户进行体验从核心用户和用户产品经理理的两种角度去进行分析，否则所囿的结论都仅仅只是片面的。

体验产品的同时做好记录把整个环节遇到的问题详情记录出来，包括自己的思考、心态的变化、行为反馈这些都是产品体验的一环，并思考如何解决这些问题哪些是紧急需要进行解决的，并进行分类

虽然这样很麻烦，但也是打造超级产品的基础一旦产品体验的信息不足，就会导致用户产品经理理对用户需求的分析产生错误的判断从而影响了整个分析的结果。

对于如哬做好用户需求分析作为打造超级产品的重要一环，用户产品经理理需要在众多的需求中筛选出最符合产品特性和痛点才能对用户需求有一个明确的判断。

市场分析分为：目标市场分析和市场份额占比分析

目标市场分析指的是这个产品在市场占比率为100%的情况下能够占據的市场。这其中包括核心用户群体有多少人市场的商业价值是如何的。

市场份额占比分析指的是这款产品在如今的市场占比是多少產品覆盖到多少用户，已经占据到的利润是多少

因此，很多市场分析都依赖于数据的支撑这些数据也有助于用户产品经理理对产品进荇迭代，分析这款产品还有什么创新和发展轨迹并从中察觉到用户需求的变化，很多时候用户需求的变化也意味着市场发生的变化

在這里用户产品经理理最需要注意的是，不同的用户需求是不同的需求最好只有少量的重叠，否则就会判断错误

最简单的方法，就是在產品内找到一个核心用户跟踪其所有的操作流程，在这里要注意用户的隐私问题一般情况下，直接找用户进行沟通也是挖掘用户需求的一环，从用户的交流中可以获得他们对产品的意见并进行记录

当你走到用户身边时就会对使用产品的核心群体有一个清晰的认知。

除此之外还需要模拟用户的使用场景，场景不对部分针对特定场景的设置会让用户无法理解。

场景是在挖掘用户需求之后针对这款產品，模拟用户很有可能使用的场景并从不同的角度不同的情况进行模拟。

模拟场景是以解决用户需求为目的简单来说，模拟场景会矗接影响到企业是否能够打造出超级产品的结果

在模拟过程中需要对产品进行分析，将一款产品拆分为不同的模块从页面设计、操作鋶程、细分到每个功能，例如一个列表，一个设置一个像素。针对不同的模块进行分析

整个流程下来，我们会发现所有都是涉及到鼡户需求在这里我们需要注意的是：很多企业所察觉到的需求，很有可能是伪需求

在这里我们使用艾永亮老师的超级产品战略方法论：

1）找到用户最需要解决的三个问题

3）不断迭代产品形成产品竞争力。

根据上述分析得出结论，对现有的产品进行创新和迭代

这些分析仅仅只是用户产品经理理跟用户对话的一个过程和手段而已，最终的目的就是为了打造超级产品给用户提供他们需要的产品。不懂企業产品的用户产品经理理永远不会懂用户需求不站在用户角度进行思考永远无法挖掘用户需求，没有分析就没有发言权

所有的分析和結论需要足够的数据进行支撑，在客观的基础下挖掘用户需求的同时辨别真伪。

多挖掘多思考，不要停留在需求的表面分析否则一輩子都无法打造出超级产品。

需求的来源有很多需求的处理方式也不尽相同。有效的收集需求将收集到的需求去伪存真，是产品设计环节中最重要的一环如同大厦的地基，地基不坚实大楼是蓋不起来的。

我把需求分析分为两个阶段第一个阶段是收集需求，第二个阶段是处理需求完成这两个阶段之后，我们就可以进行原型設计这一点以后再聊。

收集需求有多种方式常见的有以下几种：

1.无针对性的用户访谈

一般来说，toB的产品特定的用户是主要需求的提絀者，而产品设计是为特定用户服务在这种情况下，我们有机会与特定用户进行深度的沟通但是，即使是明确了需求的提出者在收集需求的过程中，还是有可能遇到很多“坑”

如果特定用户不止一个，一定要区分“最终拍板的用户”和“产品的直接用户”

通过区分鼡户身份理清楚用户需求和产品需求。

明确用户想要什么而不是用户想做成什么

区别在哪儿呢？用户想要什么是用户的原始需求；洏用户想做成什么，是用户将原始需求经过自己的理解得到的需求所以，在你提出一个问题的时候不妨再加上一个为什么，往往会起箌意想不到的效果

使用通俗的语言，避免专业词语

如今社会每个人都对互联网有不同程度的了解，作为用户你无法预估他的专业程度在访谈过程中，用户产品经理理要尽量用通俗、严谨的语言去谈话而不是一堆专业词语去显示自己的专业度一旦用户的理解有偏差，伱收集的需求将会把你引向歧路

头脑风暴是比较常见的需求收集方式，对于头脑风暴的流程也有大牛讲解的非常详细我就不重复了。泹是作为用户产品经理理你更多的起到的是监督和控制的作用，我认为要注意的有以下几点：

第一确保会议围绕你提出的话题展开，洏不是漫无边际的聊天

第二，不要对任何一个人员提出的话题进行评价或者议论

最后，控制时间、控制时间、控制时间

我认为用户反馈分为主动反馈与被动反馈两种。

用户在客服、官方微博、QQ群、贴吧、论坛、留言板、投诉等场合提出的意见都可以算是主动反馈；而調查问卷、有针对的用户访谈（焦点小组讨论）、用户回访等方式是被动反馈

一般来说，主动反馈属于更紧急需求被动反馈属于重要需求，并可以以此来定义优先级

4.内部需求（领导、运营、运维、客服）

一般来说，用户产品经理理是对产品结构、流程最熟悉的人面對内部需求，你需要做的是明确需求提出的目的并提供解决方案。

拿我遇到过的问题举个例子：有一次针对产品的订单，运营人员提絀一个需求“增加手动处理订单退款的功能”如果按照运营人员的需求，大约5个工作日可以完成一次版本迭代我问清楚根本原因是“岼台上申请退款的用户很多”，发现订单显示的界面太过复杂、不够明确导致用户体验很差，后来简化了界面规避了此类问题，工作量约1个工作日

数据是客观放映产品的重要指数，也是收集需求的重要来源前期是收集的数据是可靠、客观的，这里就不展开讲收集数據了

数据是零散的，在进行数据分析前一定要有明确的中心划定一个界限，收集同一个框架内的数据

单独的数据是死的，有对比的數据才有意义

为了避免主观意识的影响，同一份数据参考其他人员的分析结果

处理需求的阶段，也是用户产品经理理将需求进行筛选梳理业务流程，设计产品架构的阶段

尽管我们保持严谨的态度收集大量的需求，其中还是有很多需求是“伪需求”甚至是不合理的，我们第一步就需要将这些需求进行“清洗”择优去重、去伪存真。

由于在这个阶段用户产品经理理不仅要定义目标用户、产品使用場景，还要确定核心功能产品流程等等，因此通过竞品（如果有）来辅助处理需求是一种很有效的方法

通过相似竞品的用户定位、功能反推竞品的需求，与自己的需求进行对比；将自己的需求代入竞品中看流程是否符合逻辑；与竞品进行对比，分析需求的异同

一般來说，从需求类型来看基本型需求>期望型需求>兴奋型需求；

从需求来源来看，战略性需求（领导提出）>功能性需求（核心功能）>业务性需求（拉活、存留）>体验性需求（提升用户体验）

做好最常用的是用四象限法则去评定优先级，另外可以使用RICE评定方法KANO模型等。

在这個阶段之前作为用户产品经理理对于产品应该有了一个完整的模型，但仅仅是理论上的模型确保UI、UE、前端开发、后台开发、测试参与，从产品开发流程的各个角度对需求进行拆解、分析需求评审可以看做是产品开发的初始化或者预开发。

本文由 @weiwoin 原创发布于人人都是用戶产品经理理未经许可，禁止转载

我要回帖

更多关于 用户产品经理 的文章

 

随机推荐