一个失业的产品经理，回顾一下这8年的产品生涯（一）

产品野狐禅 2023-08-06 02:04:42

一、前言

1. 找工作

本来，对今年的就业环境的情况，已经有了一个心里预期，没想到真正去找工作的时候，发现郑州这边的环境，比我想象中的还要恶劣。

开始找工作有一个月了，简历优化了好几次，boss上主动沟通了很多公司，只得到一次面试机会，再无下文了。

31岁，大专学历，毕业证还是非统招的，没有大厂经验、没有知名成功项目，我感觉我的产品职业生涯似乎要结束了。

2. 最近两年

找不到工作，跟学历有关、跟能力有关，也跟最近两年的工作经历有关。选择很重要，选错了，很要命。

最近两份工作经历，简直一塌糊涂。两年换两份工作，一个外包，一个跟无头苍蝇一样的创业公司，都是混乱的项目，拿不出任何成绩。

18年的一天，跟朋友一起吃饭，一个朋友做网络算命的，说给我算算。本来是嗤之以鼻，但是想想挺有意思，就让算了算。卦象显示，庚子年后，人生会有些不顺。

回想一下这两年为什么会把自己的职业生涯搞成这样，只能说人无远虑，必有近忧。

混的不好的人，喜欢炫耀自己过去的辉煌，我现在混的很不好，我也想炫耀炫耀。回想15年到20年那5年，应该是31年人生中最辉煌的时候了，目前职业生涯中最大的成就，赚的最多的钱，也是在那个时候。

当时在一家金融公司负责互联网产品工作，很得BOSS器重，不到一年，便让我负责起技术部门的全部工作。原因有很多，当时自我归结为能力、态度，现在回想起来，应该是和BOSS的性格很符，按照游戏三国志的设定，我们的相性应该一致。在这件公司围绕着主业务做了很多项目，不良资产、电商、供应链都有涉及，而且都成功，现在回想起来，那时候公司的势很足，个人的势也很足，做什么都很顺。

负责项目业绩最巅峰时期，也有很多人来挖我，当时感觉自己很厉害，公司呆的也很舒服，我也会在这公司干一辈子，没有考虑过自己的行业经验壁垒，感觉自己能力很强，就算不在这公司干了，凭自己的能力，哪不能去？

18年之后，公司主营业务开始下滑，一发不可收拾，中间尝试各种续命、甚至换方向，都没能挺过。挺了两年，大BOSS又因为一些其他的事情入狱，又赶上疫情，终于坚持不住，倒闭了。这个时候，突然发现，自己的一切骄傲，似乎都是平台带给我的，当平台崩塌后，我好像什么都没有了。

3. 工作选项的失误

20年初，疫情期间，携手5年的公司宣告破产解散，自己开始搞一个自己的小项目，正好朋友介绍了一个政府消防项目，当时想着这样接着项目，自己搞点自己的事业，也是不错的，比上班强，还自由。但是政府项目两个月完成了，交付完之后，自己的项目也没有太大的起色，随后的几个月，陷入了无比的焦虑当中。

想了想，开始找工作。

说实话，刚准备开始找工作的时候信心满满，毕竟自己是做个几年产品总监、负责过上亿项目的人，找个工作还不手到擒来，但是开始投简历的时候，看到JD各种行业壁垒、各种学历壁垒的时候，有点慌了。

投了几份简历，迎来了第一次面试，也遇到了羞辱般的碰壁。那是一家做外贸供应链产品的公司，HR给面的。简单的自我介绍完，HR的第一个问题就把我问自闭了。HR说：你没看我们岗位要求的最低学历是本科吗，是谁让你过来的？当时感觉浑身都燥热了起来。

之后找工作的时候就陷入了一种自我怀疑怪圈，只敢投一些学历要求低，JD没有明确要求行业的岗位，然后就遇到了一家人力外包公司。

这个专门为我们当地一家客车企业提供人力外包服务的公司，当时其实我并不知道什么是人力外包，只知道项目外包，面试是甲方的人，通过了，项目是这家客车企业的金融业务系统，离家特别近，几分钟路程。

当时想着毕竟是行业龙头企业的大项目，我这种一直在小公司厮混的野狐禅，正好去学习一下大公司的项目经验。报道之后，签了一堆三方明白书之类的协议，才知道原来还有人力外包的项目。

进去之后，发现所谓大公司项目也非常混乱，同事水平水的一批，干的大多数也都是传话筒的活，不过也有收获，一些管理和制度，让我之前不成体系的产品知识系统化了，干了一年，感觉不行，钱也不多（走的时候才知道外包公司拿走了将近6成，年终奖也被克扣了），也学不到什么了。

然后换了一家公司，这也是职业生涯中最累，让我上班最痛苦的公司。现在也不想太详细说了，后面回顾项目情况的时候再说吧。

回顾这两年的经历，只能说一步错，步步错。人的信心很重要，找工作不要轻易降低你的标准和定位，无论是因为能力还是运气，达到某个高度之后，就不要再往下跳了，一旦降低，就可能回不去了。

在小公司，尤其是业务不清晰的小公司，很少有合理的晋升制度，入职时给公司给你的定位，会造成你在公司决策权和信息获取方面的缺失，很大程度将决定你在该公司职业生涯中的长期定位。当公司又没好的业绩和长久的发展空间时，只能又累又背锅。

接下来的内容，我就从自己的经验、技能、方法，项目经历、职业生涯做一些回顾，本篇内容主要集中在个人经验积累的产品工作方法论上面，项目经历、职业生涯的情况将分批讲诉。

二、我的产品生涯中的经验和技能

本来列大纲的时候，这部分的内容，我一开始命名叫《我的产品方法论》，梳理完之后，感觉还不配叫方法论，只能说是一些经验、技能和工作方法的回顾，接下来主要从商业需求分析、用户研究、需求分析管理、产品设计、项目推进、产品迭代、团队管理、学习方式方法这8个方面进行一个总结。

1. 商业需求分析（从0开始的需求分析）

在从0到1的产品，产品经理最先接触的应该是一个商业雏形的概念，这个时候还并没有形成标准的商业模式，我们的团队还不知道接下来该怎么做。我们需要进行的是商业模式和商业需求的分析。

虽然商业模式、商业方向这些更多的应该是老板考虑的事，但是我觉得，作为一个产品经理，应该有基础的商业嗅觉，起码能判断出，一个商业模式，是怎么样赚钱的。

我这里提到的商业雏形，也是最原始的需求雏形，也是需求分析的第一阶段。

（1）提升商业需求获取的能力

①行业经验、兴趣的积累

企业要深耕一个领域，人也一样，孰能生巧。你在某个行业领域待得久了，你就是专家，有些问题就能发现，形成商业雏形。
当然行业经验这种客观条件，很难有捷径或者方法论去达成，只能学习，实践、积累。但是兴趣不一样，是有方法快速积累的。
qq群、贴吧是个好东西，只要你想的到，再奇葩的同好人群都能在里面找的到。然后需要做的就是多了解，多互动，多参与活动，

②头脑风暴思想的碰撞

很多人反感频繁的开会，扯淡。但是产品经理一定不能反感，爱好广泛一些，多扯淡，很多时候很多好的想法都是扯淡扯出来的。

③保存对新事物的好奇

有时候，到了一定年纪，就会形成固执的世界观，对于产品经理而言这是很可怕的。
对于新的事物，可知内心的反感，也去尝试一下，比如说，新出的系统版本，一些新模式下的产品，哪怕理解不了，也去试一下，尝试一下也掉不了一块肉。我日常中对小红书、陌陌、soul、得物、盲盒，这一类的东西很不感兴趣，但是还是去尝试了。像一些理解不了的概念，比如区块链的应用场景，nft的追捧，也去接触，虽然被割了韭菜，但是在虚拟货币的交易场景中也发现了赚钱的机会，赚了半年的快钱（这部分，后面项目介绍的时候具体在展开说一下）。
对于不用人群的接纳了解，我现在qq群里面加了各种类型的社群，包括常规一点的行业、各种类型的粉丝、还有各种特殊人群的聚集社群，发现过很大的未知天地。

④多体验

体验各种应用、体验各种广告，了解它们本质的商业模式。

⑤抄

产品的行话叫竞品分析，多思考别的产品优秀和不足的地方，思考他们团队为什么要这么做？

⑥行业研究，数据分析

行业研究网站，上市公司财报，哪怕是一些新的概念，很多都能在老的模式中找到分析的方式，如最近火热的预制菜概念，其实在很早以前就有中央厨房、料理包这一类的概念。

⑦跳出行业，已局外人的视觉去看自己的行业

在一个行业待得久了，看待事物的方式很容易产生一个惯性的固化思维，适当的可以跟行业外的人交流一下你们的模式、产品，听听外行人的意见。

⑧给自己足够的思考时间

好的创意不是忙出来的，对于我来讲，大脑最活跃，思维最发散的时候集中在拉屎、上班路上，以及躺床上休息的时候。太忙的时候很难出创意，大量的时间精力在不停的做方案，赶项目，996，下班后只想早点休息，思考太需要时间了。

（2）从商业需求雏形到商业需求方向的落地

有了商业需求雏形，如何确定可行性？进而确定到商业方向呢？

①市场的规模

常规的行业一般可以从国家统计局，证券公司的报告等方式上获取。
但是对于一些市场上比较冷门行业，或者说市场上干脆没有这个领域怎么办？我的方式可以给大家共享一下。
最近一年因为爱人在家带孩子，也没上班，就想着找个事干干，因为我爱人是学服装设计的，我最开始关注的是服装领域的，后来在qq群里发现了一个特别小众的服装领域，给手办、玩偶定制衣服，利润和市场都有，但是在实际过程中发现需要的投的精力会比较大，宝妈的精力有限，无奈放弃，随后发现了一款特殊人群的特殊食品，特别小众，也不需要怎么制作，但是淘宝有人开店，不多，几家。
通过观察此类产品淘宝头部店铺的销售情况，大概推算出这家头部店铺每年的销售额在200万左右，综合利润大概在100万，不过他们的品种比较多，而且通过社群的方式聚集了一批同好者，大概有2000人左右。搜了一下同样内容的社群，活跃社群的人数加载一起大概有两万多人。估算了一下他们的市场占比在大概能主动寻求这个产品的客户中的10%左右，在不做任何广告的情况下市场规模预计在2000万左右。
又细细研究了一下，这个产品的获取成本非常低，而且有稳定的渠道，就在淘宝试着开了一家店，在没有货源的情况下试运行了一段时间，总结了一下，每天投入的主要精力就是碎片化的咨询时间，预计的收入大概在3000-6000左右，事实证明在正式开始后，收入情况跟预估的差不多。

②竞争对手

就像上面市场的分析说的拿样，对于常规的行业，通过客户、通过产品，去找你的竞争对手，这里的目的就是分析在当前的竞争对手的情况下，你能拿到的市场份额，以及方便做后期的竞品分析，重点关注头部的竞争对手。

③自身的资源

除了市场和竞争对手外，自身的情况和资源是否满足，如果不满足，需要哪些东西。

（3）商业需求的目的

在商业需求分析的阶段，不需要形成具体的执行方案，更多的是为接下来的执行提供方向，最终的目的我认为有以下四点：

确定业务模式
业务怎么开展？怎么赚钱？赚谁的钱？为哪些人提供什么样的服务？
方便定位客户群体
知道接下来该怎么哪些资源

2. 用户研究

（1）找到你的用户

当有了一个商业需求了，告诉你，我们要一款产品，为某些需要某些服务的人群，提供一个平台，来帮助他们解决问题。这个时候应该干什么？我的话会去先找我的客户，先了解目标客户的特点，进一步的去分析需求。

如何找到你的目标客户？根据需求情况，我常常采用的方式：

①借用团队现有资源

一个商业需求的确认，肯定是团队现有了某些资源，才能确定的，或者是业务上的，已经开展了类似的业务；或者是客户上的，已经储备了一批这样的客户；又或者是实体资源上的，我有一批货源。以现有资源为基础，找到对接的用户群体。

②征求专业人士的建议

寻求行业内的资深人士，或是老板，或是深耕业务多年的同事，让他们知道用户的方向。

③行业峰会

如食品行业从业者的糖酒会、互联网人群的各种技术峰会，都可以找打很多目标用户。

④兴趣社群

亦如贴吧、qq群、各种行业论坛这种，会聚集一批兴趣、行业相同的同好者。

⑤把自己当成第一批业务员，实地跑一跑

就像刚入行的业务员，没有客户资源怎么办，拓客嘛，实地去跑、扫街，扫完街回去总结，客户在哪，有没有集中的地方？

（2）用户调研

到这一步其实就是老生常谈，用户画像和用户需求调研，结合我们产品商业模式的战略防线，为客户提供的服务，初步建立其一个大概的用户画像，把用户的一些共性特点属性总结归类，然后在调研中不断完善。我这边常用的调研方式如下：

①访谈

最常用的就是跟客户，跟业务干系人沟通，一般有两种场景，一种是主要作为倾听者，听他们聊聊行业的情况，看法，这种一般对行业了解还不够，还没有建立起访谈的框架的时候；另外一种心里已经有一个方向，预设了一些问题，验证或补充你的想法。
访谈的话没必要聊太多人，3-5个典型的客户就行，如果你访谈的目标5个人都没达成，再多也是这个结果。

②问卷

在已经在心中确定一个大致的产品方向时，就可以通过问卷的形式验证或完善你的想法，通过把一些抽象的问题量化成具体的数值或者选项，供用户进行选择，具体的渠道可以通过社群等方式进行投放。

③模拟业务

构建了一个产品的雏形，可以试着把自己当成一个业务员，把这个产品当成一个付费的业务来试着售卖，看有没有人愿意为其付费。

3. 需求管理

当通过商业的定位、需求分析、以及用户调研后，我们基本都可以知道，我们要做的这个产品是为什么人提供样的服务，这些人都有哪些特点了。延伸出的需求也就比较清晰了，在需求落地之前，需求的管理决定了产品的质量。

（1）建立需求池

需求管理的第一步就是建立适合项目的需求池，如果产品线只有一个你产品经理的话excel就可以满足需求，如果作为产品总监的角色，需要对团队的需求池进行管理，可以使用一些工具，tapd、jira之类的都可以，或者在线文档，excel+svn/git，都是可以的。

①为什么要建立需求池？

需求池是记录需求的一个工具：

产品经理要面对一条产品线从上到下所有的人，每个人都会有想法、意见、建议，不可能第一时间去完成，也不能全靠脑子去记。

此外，不是所有的需求都是需要实现的，也不是所有需要实现的需求都是立马要做的。记录下来，保证到你这的需求有迹可循，方便管理。

需求池是需求排期、版本管理的工具：

需求池也相当于一个产品工作的todolist，方便产品经理进行需求分析的实际安排，项目的大概的排期计划；
另外也可以在需求池上进行版本的规划，根据优先级、工期制定版本计划。

挡需求：

作为产品经理肯定会经历过这种情况，上级领导、其他职能部门提出不是特别合理或者不是特别紧急的需求，但是要当时直接拒掉他的需求，太过于不讲情面、不利于团结，但是如果你当着他的面把需求记录在需求池，并向其展示优先级比较高的需求，向其说明原因，表示你的需求我已收到，但是当前的需求排期有更紧急的任务，我计划什么时候对你的需求进行分析，再进一步沟通。

这样双方都有一个深度思考的时间，作为产品的我们也能更好的判断需求的合理性，做还是拒绝。

方便汇报：

对于阶段性的工作汇报、或者对于领导重点关注的需求，你只需要翻一下需求池，就能很直观的回报了。

②如何建立一个需求池？

需求池其实是个很简单的东西，需要的字段：需求描述、所属模块、功能点、需求类型、需求价值、场景描述、提出人、提出时间、状态，优先级。能记录清楚什么时候、什么人提出的什么需求？当前是什么状态即可，其他的字段可以根据项目情况、团队情况增加字段。比如说开发时间、上线时间之类的。

（2）需求优先级

如何确定需求的优先级？

①根据业务目标来确定优先级

这一阶段是要实现什么样的目标？用户增长？存留？收入？或者是提高某个流程的效率？
然后拆解目标，比如说某个信贷系统，想要对部分优质客户进行200万以下融资的时候，不在进行人工审批，自助办理，直接放款。简单拆解一下，需要建立优质客户模型、风控、评级、授信、电子合同等体系，保证资金的安全，降低风险。这些是重中之重，其他的像用户使用什么平台操作、用户体验之类的，就显得不是那么重要了。

②根据需求价值确定优先级

这个功能能为什么人带来什么价值？使用场景是什么？当前没有这个功能给产品、用户造成什么问题？增加这个功能能带来什么？影响范围有多大？有多少人需要这个功能？这个需求需要做到什么程度？搞清楚这些问题，需求价值的非常清晰了。
不过在日常工作过程中，会有很多价值难以量化的需求，怎么办？开价值评审会，拉起相关的干系人，推论、评审价值，估算一个合理的价值区间，直到大多数人认同为止。

③根据产品的生命周期阶段确定优先级

新产品：

新产品的核心是业务流程的完整性，流程相关的功能必须完善，要形成闭环，来完成我们产品定义的目标。所以只需要围绕核心业务流程，就可以定义出高优先级的需求，反之，无关核心业务的锦上添花的需求，哪怕看起来再重要，优先级都不应该太高。

举个例子，如果老板有一批茅台，想在网上建个网站平价卖掉，那个这个网站的核心业务流程就是下单，其他都不重要。

但是如果老板想通过这批平价茅台，作为用户奖励，建立起一个酒水商城，这个时候，核心流程就多了起来，我们要考虑基础的下单流程，还有考虑延伸出的注册登录流程、奖励获取流程，以及老板需要的电商平台的基础功能流程：发布产品流程、订单管理流程等。

成长阶段：

这个时期应该是已经启动，积累了一部分种子用户，进一步发展的阶段，这个阶段，已经验证了需求是真实需求，有客户买账，存留、拉新是核心。

关注数据、反馈，影响业务的bug，影响用户体验的细节、都是这个阶段应该关注的。

此外，围绕核心业务，能为核心业务锦上添花的功能，这个时候的优先级也要相对提高。

以上面的电商平台为例，我们在新产品上市后，我们重点关注用户在登录注册、参与活动、下单支付等流程有没有阻碍，茅台激励的形式有没有更好的方式，用户参与活动转化购买其他产品的途径。

成熟稳定阶段：

这个阶段项目主业务趋于稳定，就可以考虑其他拉新、转换的模式了，把主业务的剩余价值发挥到最大。
以电商平台为例，假设我们通过之前的各种手段，把平台建立起来，这个时候我们就可以去延伸做更多的非主业务需求了。比如说针对用户消费分级的画像系统，针对产品标签权重的推荐系统，或者延伸下沉市场，做一个极速版或者低价版的平台。或者打造为高端用户服务的会员机制。再或者把我们的供应链系统完善。

④根据实现成本确定优先级

大多数互联网项目的成本都是开发成本，评估一下需求的工时，再对照一下价值、目标，优先级高低一目了然。

4. 产品设计

（1）业务流程图

在需求梳理完成之后，开始产品的设计工作，首先要做的就是把流程图画出来，目前我常用的工具是draw.io，开源的工具，很好用。
这个时候的流程图主要做的是关键业务的系统流程，不需要特别细致，也不需要特别精美，关键是逻辑清清晰，流程完善。一般来讲最常用的就是跨职能流程图，能够清晰的表达用户与系统、或者不同角色、场景直接的业务关系。

（2）功能清单

结合需求及流程，确定需要的功能，使用思维导图或者excel表格进行整理，这里需要具体到功能模块，如登录、注册、发布xx信息等。

（3）角色用例

对于多角色系统，如涉及到买卖双方的c2c交易平台，需要考虑到卖家与买家不同的角色用例，区分不同角色需要的功能，如果不同角色用例没有交叉，就可以考虑对不同角色使用不同客户端去区分使用了。

（4）产品结构图

在确认了业务流程、功能清单、角色用例的基础上，我们就可以确定整个产品的结构框架了，主导航有哪些，需要哪些页面，页面的层级与聚合关联关系，都可以通过结构图梳理和呈现出来。

一般来讲，像移动端，由2-5个主导航构成，首页、我的属于95%以上产品都会有的功能，中间根据具体业务的情况去设置相应导航。

中后台产品的主导航就比较多一些，根据业务情况去聚合就可以，如用户中心、会员中心、商品中心、广告中心、营销中心等。

（5）页面元素

根据产品结构梳理出来的页面，以及页面承载的功能流程，去确定这个页面都需要哪些元素构成，如登录，最基础的账号密码输入框，登录按钮。复杂一点的，登录方式选择、注册、找回密码，验证码等。这个时候可以先不用太多的考虑页面上的呈现方式和体验，把构成页面的基本元素整理出来。
页面元素框架可以使用draw.io等流程图工具，用基础的线框表示，或者做一个页面流程图，表示页面元素内容和页面流转关系。

（6）页面设计

前面的一些工作完成之后，到了页面设计这一步，其实就没有什么通用的方法论这一说了，更多有价值的是一些规范性的东西。

首先，是一个产品的不同页面直接一定要保持样式一致性，这样可以通过建立一个原型规范来去执行。

抽离公共部分一些常用的组件，比如按钮、头像、弹窗、表单等，在项目开始前期建立相应的标准，尽量不要出现一个项目相同场景的功能，交互组件样式不一样。

如果你常使用axure，用好母版和元件能让你事半功倍，把不同项目可以复用的样式做成元件，把一个项目中的通用组件做成母版。

这个方面可以多参考一些开源的前端UI框架，尤其是像中后台类的产品，可以把一些优秀的框架如element、layui之类的优秀的样式做成组件，储备下来。

其次，遵循用户体验，尽管产品经理输出的只是原型，但是原型的体验很大程度上决定了最终输出的UI设计稿的体验。

这个方面，设计的时候带入用户视角，假设你是用户，怎么样最方便。
多学、多看、多抄，参考优秀产品的同样操作，不要怕被怼又抄哪个，合理就行，哪那么多创新.
进行可用性测试，一些传创新的页面或者交互设计，实在没得抄，在整个功能流程中还非常重要，就可以组织一些干系人进行可用性测试。

另外，学会克制，不要在原型里加一些跟业务无关、跟功能无关的花哨设计，如果真的忍不住，自己列到需求池里，评估之后再进行处理。

最后，做页面原型设计的时候首先要明白你的目的是什么？

对于大多数常规的产品原型目的就是向UI和开发传递可视化需求用的，想设计师和开发表达出我们想要的东西大概是长什么样.

原型是一个沟通工具，沟通到位了，一句话就可以表述清楚一个功能，沟通不到位，弄个几十页的prd做出来也不是你想要的。

当然这不是绝对，就像前面说的，如果要组织可用性测试，尽量保证你要测试的原型和交互是完整好用的。还有一些toB或者toG的项目，在开发之前，需要跟客户演示，做一些售前的工作，也需要高保真的原型。

5. 项目推进

在我作为产品经理参与主导的项目管理中，各种会议的管理，正式我推进项目的最有效的工具，我作为产品经理的工作，除了需求分析、产品设计之外，其他主要的工作就在各种评审会上面。

（1）需求价值评审会

作为产品经理，你要保证，做的任何需求都是有价值的，这也是产品经理的价值所在。

接到一个需求，当你开始分析时，首先要判断它的价值，而且尽量把它去量化，比如说某个功能上线后，结合运营多少资源，可以为产品带来1万活跃用户，我们需要投入2个人10天的成本，值不值得做？

但是实际上很多需求你没办法一个人去清晰的判断出它的价值，就需要一个价值评审会，来明确产品价值。

尤其是对于B端产品经理来讲，需求价值评审会就是避免你成为传声筒的最好方式，客户、领导、其他业务部门传递过来的需求，没办法拒绝，拉着相关的干系人，逐条评审产品的价值，明确是否要做，怎么做，不能做，也有合适的理由拒绝。

价值评审会产品经理为主导，拉着一名技术人员，以及需求的提出人、干系人来进行。

价值评审会需要准备一份《需求价值评审文档》，包含一下属性：

需求描述
需求背景
提出人/部门
需求场景
需求的价值
大致的系统方案
实现成本
可能存在的风险
功能清单
业务流程
原型示例
评审结果

（2）原型评审会

面向技术团队内部的会员，向开发、UI、测试讲诉你的产品，你的原型会议。

原型评审会的目的：向团队成员表达清楚你想要的东西，让大家参与，找出当前设计存在的问题。进行任务的分配，然后评估各项工作的大概工期。

讲解原型的几个要点:

需求背景表述清楚
需求的价值
为什么要这么设计

评审会经常会遇到的问题多是一些与开发人员的沟通问题，如何应对？

①功能做不了

判断是真的做不了还是不想做，可以通过历史经验和其他竞品的功能进行判断。
真的做不了的话了解其无法实现的原因，共同寻求其他替代方案，或者暂时延迟此功能。
不想做，找到不想做的原因，是觉得麻烦还是不认同产品的价值；

②功能成本高

评估价值与成本，是否在接受范围，再来决定是否要做。

③功能没价值

听听开发认为没价值的原因，不要有对抗思维，向其也表述你认为要做的原因和价值，去综合评估。

对于跟开发意向有分歧的地方，怎么处理？

客观地想一想，如果真的价值不高，且成本太大，目前的开发资源又有限，暂时先不考虑；
如果觉得此功能的重要性很高，坚持要做，会议上表述你想要实现的最终目的，询问是否有其他方案来实现这个功能的目的，有，皆大欢喜。
没有的话也避免会上激烈冲突，可以说我们都在考虑下，过下一个功能点，结束后，单独沟通，可适当表述出你的难处，把大家拉到一个立场上来，同时为其争取项目时间、资源。
真的遇到极端的人，可以不必浪费时间，将问题升级，由领导来决定，并同时向领导申请资源，之后把他当成工具人来用。

（3）UI评审

产品经理来确认UI效果图是否达到预期；
涉及新项目的时候前端确认UI是否规范；
取得相关干系人满意，防止项目过程中，有人再对UI效果表示不满。

（4）技术评审

对于新项目，我建议产品经理一定要参与到技术评审中，了解技术架构、技术选型，框架等，最主要的是要关注数据库结构的设计，表和字段是否满足你的产品需求，减少开发过程中的遗漏。

除此之外，对于产品经理主导的新团队，在技术评审的时候一定要让前后端把接口的规范定清楚，把责任提前明确，防止前后端扯皮。

（5）测试用例评审

这个评审主要是由产品经理和技术来评审测试用例的范围，是否覆盖全，以及明确重点测试的部分，还有可容忍的bug范围。

（6）项目复盘会

复盘项目过程中出现的问题，人的问题，制度的问题，共同讨论如何规避问题。

6. 迭代需求的获取（从1开始的需求分析）

（1）用户反馈

①建立用户反馈渠道

与核心用户建立联系，在项目启动时活跃的种子用户，可以建立社群或者加好友的方式，建立联系，作为一名产品的角色，一般的客户很容易会给你反馈一些他觉得是问题的地方，判断，收集，列入需求池。
建立长效的反馈通道，尤其是c端产品，建立一个反馈通道，可以是直接的问题反馈模块，也可以根据用户的操作判断引导客户反馈问题，比如监测到截屏后，提示是否要反馈问题。

②主动寻找用户问题

经常关注应用平台上的用户评论，尤其是低分评论，收集整理；
主动搜索，搜索引擎、微博、抖音、快手、小红书，经常搜索一下你产品的关键词，看一下用户问题；
一般来讲这种工作可以指导运营来进行收集，指导运营对问题的类型有基本的认知，什么需要bug，什么属于需求，来建立一个问题汇总的方式；
有条件的可以使用一些舆情监控系统，更全面的了解用户对产品的想法。

（2）数据分析

产品上线后，即时的监控分析数据;，数据分析的数据来源可以通过三种方式获取

①接入第三方统计工具

产品在上线之前就要确定好是否要接入第三方统计，确定接入的平台都提供哪些数据；
常用的像百度统计、友盟、极光之类的，通过SDK接入；
一般来讲像这种第三方工具，适合监控分析产品的整体数据，如访问量、入口页、停留时长、页面流转情况之类的基础数据，然后还会有一些基础的转化漏斗模型。足够监控分析关键业务点的业务或用户流失情况，帮助我们分析哪个页面或者哪个功能不合理。

②数据埋点

对于一些具体到特定用户的行为，或者某些特定功能的具体检测，需要在开发过程中进行预埋点处理，相对于第三方工具数据维度更丰富和深入，适合精细化分析和用户行为洞察。

③业务数据分析