编辑导语：近年来，就业形势严峻，能力的扎实越发凸显。年限并不能代表经验，什么样的产品发展路径与成长才是比较理性的？作者从其自身经历出发，总结了其八年产品生涯的一些体会与经验。
一、前言
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接入；
- 一般来讲像这种第三方工具，适合监控分析产品的整体数据，如访问量、入口页、停留时长、页面流转情况之类的基础数据，然后还会有一些基础的转化漏斗模型。足够监控分析关键业务点的业务或用户流失情况，帮助我们分析哪个页面或者哪个功能不合理。
②数据埋点
对于一些具体到特定用户的行为，或者某些特定功能的具体检测，需要在开发过程中进行预埋点处理，相对于第三方工具数据维度更丰富和深入，适合精细化分析和用户行为洞察。
③业务数据分析
- 对一些业务数据的分析，如电商平台对某些商品的购买人群属性的分析，分析这些商品受众的用户特点。
- 一些常用的业务数据的分析可以作为中后台的固定功能来设计。
- 非常用的建议使用一些BI工具，来进行查询，如power bi 、ableu、fineBI等。
（3）建立内部反馈渠道
产品经理作为一款产品的负责人，一定要让公司内部有一个清晰的反馈机制，线上有问题首先找你反馈，包括bug。向开发、测试同步，内部业务口的问题，他们不要接待。所以的问题集中在你这，一方面清晰的掌控产品与公司内容的相互影响关系。
（4）深入了解业务模式
对于你所主导的产品线的业务，要积极了解，与相关的业务人员保持一个良性的沟通关系，可以适当积极参与一下业务的例会，了解业务的情况。
对于一些新开展的业务，可以自己尝试以业务员或者运营人员的身份去跟客户沟通，开展业务，去发现问题。
（5）了解前言的模式、技术
一方面指的是商业模式，另一方也要保持对技术的了解，可以不会，但是不能不了解。尤其是在互联网领域，很多新的事物是现有技术体系，才演变出各种类型的产品。这方面可以多了解各大厂的团队博客，或者是开源项目。
（6）了解你产品环境的生态体系
了解你产品的生态体系，比如在微信体系下，你是否了解微信开放平台、微信小程序、公众号提供给开发者的功能都有哪些，接口文档有没有阅读过，更新的功能了解多少。
（7）竞品分析
又是老生常谈，这可以说是产品经理最基本的功能了，这里不再过多的赘述，简单梳理一下我的思路。
①找到竞品
对于C端的产品来讲几乎不存在这个问题，C端产品想找竞品到处都是吗，这里主要说一下B端产品如何需找竞品：
- 相关业务关键词搜索，搜索公司或者产品；
- 通过客户了解，跟客户沟通，了解客户常用的产品有哪些；
- 加入行业群，了解行业的动态，找到竞品；
- 一些原型、设计分享网站，碎片化的去了解竞品的功能；
②竞品分析的思路
- 首先通过竞品的价值主张或者宣传内容，了解竞品的战略定位和客群，为什么人提供什么样的服务
- 梳理页面框架、内容
- 梳理产品功能结构
- 梳理业务流程
- 总结亮点与不足
- 反推他们为什么这么做
- 如何应用到我们的产品中
- 结合第三方数据分析
以上，就是我对自己产品技能，从需求分析到落地的一些方法的总结，希望对大家有帮助。
本文由 @产品野狐禅 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
上一篇
