产品上线的7个惨痛教训，说多了都是泪
最近回顾了一下从去年年底到现在做过的两个 B 端产品，从需求调研到产品设计再到最后上线落地，耗时接近4个月；整体来看，时间有点超出预期。作为产品经理的我，有很大一部分责任的。
从开始的行业不够了解，需求分析跑偏。到定位错误，导致产品调整。也经历需求临时变卦，功能不断修改调整……不过，好在项目最终都顺利上线！
发表一下感慨：产品真难！
不过这些坑都是非常宝贵的经历，对于产品而言，如果能有效地进行思考、复盘、调整，或许能带来很多新的东西。
那过程中，我究竟经历了踩了哪些坑呢，以下是文章目录，我们一条条看！
01 不清楚产品服务对象，是惨痛教训
两项目其中一个来源于总监对业务的规划，目的是 通过供应商对资源的有效竞争，来降低公司跨境物流成本；这个我最初的定位是做一个公司内部的工具。另一个来源于公司产品的迭代，根据公司现有业务和未来发展，对官网前后台进行重构。
这两个产品说不上多大的工程，但对我而言已经很满足，至少让我有了产品从零到一，上线并给用户使用的经历。当亲眼看到后台有新增用户注册，使用产品的时候，感觉又心酸又有成就感。
其实工具产品一开始的定位太窄，产品服务对象没搞清楚，对公司做这个产品的思考较少，类似于跟着别人思维走。比如，公司总监告诉我需要满足什么样的需求，我总是站在他的立场上，想着如何设计一个产品，高效地满足他所提出的这些问题。
现在我仔细回顾决策的过程，发现问题的根本原因在于：我忽略需求分析阶段，思考方式的重要性，而是跳过了头脑风暴阶段，习惯性地直接做流程梳理。
这个问题很严重，要想办法养成习惯避免；那我们如何站在公司业务角度思考需求，防止自己闭门造车呢？ 这里根据案例，复盘整理了两个核心点：
1. 我们如何切换思维？
试着把公司人力当工具组件、把服务当商品，把用户当买家。公司其实就是用工具组件制造商品，和用户交易。
以工具 A 为例，最初定位是给内部员工用，整个链路是：用内部成本打造了一款商品，卖给了自己。既然都是卖，那我可不可以卖给其他有需求的用户，那其他有需求的用户是谁？我要不找找看有没有这样的用户？
后来经过自己对竞品调研，发现需求和用户都存在，提供服务的公司还不小。
2. 我们如何站在公司角度评估业务？
当你找老板聊需求，总是会被问到：成本多少？收益多大？业务持续多久？ 从老板的日常话语中，我们大概就能知道：产品价值 = 收益 – 成本。
最初工具 A的 收益是效率，成本是 技术开发 ，价值不好评估，可能收益不大；如果能开放使用，至少未来不会太局限，如果有机会做出来，也是盈利的机会。
总监经常和我说，产品设计其实是在设计一项业务，任何一项服务的打磨，都要当成是一门生意来看待。仔细回味这句话，确实没毛病。
站在公司角度思考业务，其实就是一种向上思考的过程。这种产品思维日常培养很重要，也非常实用。比如找一份工作的时候，思考自己的收益是什么，付出哪些成本，持续性怎样？
02 不了解行业信息，是惨痛教训
第一点中，我们说到产品设计是设计一项业务。而业务其实是市场和行业背景下催生的产物，一个运转过程。所以从这个角度来看，自己一开始对行业信息懵懵懂懂就开始设计产品，明显踩坑太深。
了解行业信息其实就是调研，这个过程我有遇到了三个问题：
- 如何了解一个行业基本信息？
- 如何找目标用户并调研？
- 如何评估对用户了解程度？
1. 如何了解一个行业基本信息
为了熟悉行业知识，搜寻了相应资料。发现照搬有点不靠谱，太大而全，于是照猫画虎，整理出来的东西好像很厉害，但肚子里真正沉淀的不多；
做了无用功，花了大把时间，还没学到东西。
于是项目实践后，我尝试做一些删减，个人觉得做好这三点是能对行业有一个基本了解的。
- 先了解行业基本信息：知乎、百度、谷歌上找，通过搜索我大概知道跨境电商行业，有仓储、物流、采购、供应商、亚马逊平台等，再逐个细分下去深挖一下，我的知识面就更广了；
- 了解业务流程，及上下游角色：躬身入局，亲自实操一下；我们常用的做法是线下找相关岗位人观察，聊天，主要看他们做的 事情和协同交流部分。
- 了解竞品：有些行业信息竞品是比我们更早察觉的，看看竞品看他们的玩法，可以尝试注册，找他们的客服销售问问题。
回顾这个过程，其实还蛮有意思的：为了了解竞品流程，自己模拟下单遇到问题，说没办法解决。最后加了对方微信，还抛出一大堆疑问咨询。这个方式，你也可以试试。
2. 目标用户？怎么调研？
B 端 寻找目标用户，其实就是做场景的还原；比如做人力资源管理系统，我们需要找 HR 还原现场，沟通日常招聘、邮件发放、资料管理等。
在做场景还原的时候，发现自己没有提前做问题大纲的习惯，导致最终的调研产出内容非常零散；这样一来，需求分析是很容易出错的。
其实找用户调研的时候，很有必要提前准备一些问题，和用户聊的时候思绪会更清晰。比如 提前整理表格，列出核心问题，尽量不做无效沟通。
这里要注意的是，在问题设计上也有一定的学问，线下调研因为过程比较开放，话题相对问卷调研来说，思维不会闭塞。所以线下面对面沟通的过程中，问题要尽量针对关键点，提一些开放性的问题，让用户尽情表达自己的观点。
给一个模板例子希望能给你参考：
3. 对用户了解程度？
因为上一次调研，信息收集不全，导致后续自己三番五次 找用户请教问题。
因为对用户不够了解，遇到任何规则的变化，我们很容易陷入联想状态，假设的越多，错得也就越多。提供一个参考思路：
- 首先按照上述方式调研场景，整理并划分好用户基本类型和特征，这里的特征不是性格特点，是用户群体对行为的偏好。
- 针对不同用户类型，若预测用户在不同外部条件下的预期和行为，说明我们对用户的掌握基本合格。
比如用户登录密码错误，用户可能会产生懊恼情绪，会尝试找回密码，感受用户也是同理心的过程。
03 产品定位错误，是惨痛教训
产品定位的调整，是血淋淋的教训。第一点中有说到产品定位太窄。那现在，我针对这个坑点，来说说定位调整，给产品带来的影响。
产品定位踩过的坑：产品定位有用户、痛点、也有方案，但忽略了盈利和收益。
工具 A 最初定位是给内部使用，调研过程用户述求不断。让自己陷入了功能堆积过程。刚开始的架构思路 大体上是这样的：公司产品设计人员 负责打磨服务，产品管理人员负责运营管理，吸引客户和我们签约，服务售卖。
简单的看，是能够满足公司目前的业务，但总监看了之后和我说：我让你设计，是让你打磨出来，日后拿出来给 合作公司用，我是要收费赚钱的，听完恍然大悟。
后来站在其他公司的角度，发现需求依旧存在（有竞品），于是在方案上加了一层用户关系。把工具 A 迭代成服务平台。这样的改动，给产品带来盈利的可能性。
表面一些小改动，触动的是后台整个逻辑的修改。增加一层用户，实际上后台增加的有：账户体系、付费模块、数据关联表修改等。所以，做 B 端产品，决策路径很长，千万不能忽视了任何一个改动。
做出决定修改之后的一周，我将需求重新整理，按照调研的方式进行问题回访。对场景的规则和模块二次补充。产品工作倒无所谓，最可怕的是开发小哥因为我的调整，最终结项时间推迟一周多。
为了避免熬夜爆肝，产品设计之前，我们得先把定位想清楚。其次是，如果做一个产品，一开始就在不断累加需求，多问问自己用户是不是找对了。
04 产品设计不规范，是惨痛教训
经过这次项目经历，让我对经验和方法的重要性，有了新的定义：经验是轮子，给不了我们建设性的创新，但能避免我们在一条错误的路上，越走越远。
产品设计阶段做的更多是模块和流程性的梳理，先定义问题，再找场景，然后梳理规则，最后抽离模块；比如这样：
但这个过程也遇到了两个问题，十分困扰。
- 产品设计如何避免东拼西凑，有条理进行展开？
- 功能和规则这么多，配置怎么做？
产品设计时感觉自己信心满满，业务催催需求，就乱了阵脚，跳过功能设计开始画图。结果证明，越画越乱。
后来强迫自己回到正轨，会议、催需求，先晾着，完整流程先跑通（回顾一下我的整个流程，如果感兴趣，可以给我留言，后续加油补充）：
关于配置的问题：也是踩了太多坑，我们总想把所有功能都做成配置，用户想要什么，产品上给个界面，用户自己设置。
于是在这种思路下，我发现最后出来的产品后台，还没上线就显得十分臃肿。
过程中总结了部分规律，发现功能配置其实有一个核心思维在的：频次 & 范围 四象限：频次越高，说明使用非常频繁，用户量大，说明需求的集合也就越大，所以结合这两者进行思考配置功能，再适合不过。
以下为详情：
像电商后台产品，类似商品添加，价格设定这种，涵盖用户量大，且切换频率较高的，妥妥的配置。
05 评审成批斗会，是惨痛教训
直到项目开发，我才发觉要检查一下逻辑，看看文案，再想想交互。
于是准备不够充分，评审会高光时刻成了批斗会。业务会觉得比产品更懂需求，开发觉得逻辑理解优于产品。总之百口莫辩，事情讲不清楚，一个问题 N 多方案。
后来自己整理了一张自查表，项目开发之前，我时不时就会看下，这里分享一下：
按照这样的流程将自己的产品原型 从头到尾的梳理，假以时日，我们的产品逻辑肯定日飞冲天（鸡汤句哈）！
06 需求失控是惨痛教训
加需求了怎么办？
你是否有这样的经历：开发到一半，业务过来教你做人（做产品） 老板或者业务咨询一下需求状况，灵感爆发，给我们提几个优化，导致需求变更。
在做官网 B 产品的时候，我经历了两次官网核心下单业务的修改，主要是项目到开发阶段了，业务对需求二次定义，麻烦的不是补充内容，而是在修改，产品逻辑改动，可能对产品最终的走向都会产生影响。
新增需求我们要看对现有影响，也要看是否可持续。其次产品设计阶段，我们是比业务更懂产品逻辑的，如果需求对现有影响范围过大，不可持续，不符合产品定位，可以打回去。即便是新增也要尽量归并二期。
针对需求变动，在需求评审之前，很有必要拉上业务，将模块、流程、原型和UI 进行共享，内容走查，确保需求完善。当然，也要有一定领导力，主动推进项目，给开发小哥一点关爱。
07 项目延期是惨痛教训
项目延期了怎么办？
上线推迟，作为产品经理，我们怎么都脱不了干系。
为减少推迟上线对业务的影响，可以尝试：
- 提前制定里程碑：在什么时间点完成那些核心功能，提前准备内容；
- 上线二次预估：预计推迟到什么时候，保证后续资源能继续开发；
- 广而告之：将里程碑、现有进度、发布时间和开发 及 业务多方确认，想办法分配资源。
过程中，主人翁意识强一点，专业度就会有提升，别人会觉得我们靠谱。
总之让产品由我们掌控，把问题扼杀在过程，不能等到开发上线后再解决。
08 关于迭代的思考和复盘感悟
B 端产品迭代的思考
产品进阶是一个缓慢迭代过程，B 端类产品升级频率较低，但并不意味不需要迭代。这次实践过程，让我体会到 B 端产品更需要 关注变化。“牛鞭效应”就是一个很好的例子。
系统服务类的产品 实际上非常个性化的，本质原因就是因为场景的不同。比如我们把一个产品开放，即便基本模块都有，遇上不同客户，定制化需求依旧很多。
系统服务类的产品很多时候是在还原 场景，服务多少企业，可能就有多少种服务方式。
所以，B端产品个性化是件好事，很多企业初期就是在提供个性化服务，待成型，才考虑标准化。
最后分享复盘的五点感悟：
- 问题复杂度越高，解决过程越投入，成长也会更快；
- 产品方法论终究是方法，实践内容和结果还是得自己慢慢找；
- 如果解决问题的方案过于复杂，不纠结，有可能是问题本身不对；
- 以用户角度看问题，以生意角度思考业务，比如收益、成本，是否一直存在；
- 复盘包含：实践、思考、回顾、调整，难在调整，因为是推翻自己的过程；
本文以自己项目经历在此抛砖引玉，如果大家有不同意见欢迎一起交流。希望能和喜欢写字的你，交个朋友。
本文作者 @好奇产品铺 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
