文章为作者产品上线的项目复盘，希望能够对产品路上的各位带来一些启发。

最近回顾了一下从去年年底到现在做过的两个 B 端产品，从需求调研到产品设计再到最后上线落地，耗时接近4个月；整体来看，时间有点超出预期。作为产品经理的我，有很大一部分责任的。

从开始的行业不够了解，需求分析跑偏。到定位错误，导致产品调整。也经历需求临时变卦，功能不断修改调整……不过，好在项目最终都顺利上线！

发表一下感慨：产品真难！

不过这些坑都是非常宝贵的经历，对于产品而言，如果能有效地进行思考、复盘、调整，或许能带来很多新的东西。

那过程中，我究竟经历了踩了哪些坑呢，以下是文章目录，我们一条条看！

01 不清楚产品服务对象，是惨痛教训

两项目其中一个来源于总监对业务的规划，目的是 通过供应商对资源的有效竞争，来降低公司跨境物流成本；这个我最初的定位是做一个公司内部的工具。另一个来源于公司产品的迭代，根据公司现有业务和未来发展，对官网前后台进行重构。

这两个产品说不上多大的工程，但对我而言已经很满足，至少让我有了产品从零到一，上线并给用户使用的经历。当亲眼看到后台有新增用户注册，使用产品的时候，感觉又心酸又有成就感。

其实工具产品一开始的定位太窄，产品服务对象没搞清楚，对公司做这个产品的思考较少，类似于跟着别人思维走。比如，公司总监告诉我需要满足什么样的需求，我总是站在他的立场上，想着如何设计一个产品，高效地满足他所提出的这些问题。

现在我仔细回顾决策的过程，发现问题的根本原因在于：我忽略需求分析阶段，思考方式的重要性，而是跳过了头脑风暴阶段，习惯性地直接做流程梳理。

这个问题很严重，要想办法养成习惯避免；那我们如何站在公司业务角度思考需求，防止自己闭门造车呢？ 这里根据案例，复盘整理了两个核心点：

1. 我们如何切换思维？

试着把公司人力当工具组件、把服务当商品，把用户当买家。公司其实就是用工具组件制造商品，和用户交易。

以工具 A 为例，最初定位是给内部员工用，整个链路是：用内部成本打造了一款商品，卖给了自己。既然都是卖，那我可不可以卖给其他有需求的用户，那其他有需求的用户是谁？我要不找找看有没有这样的用户？

后来经过自己对竞品调研，发现需求和用户都存在，提供服务的公司还不小。

2. 我们如何站在公司角度评估业务？

当你找老板聊需求，总是会被问到：成本多少？收益多大？业务持续多久？ 从老板的日常话语中，我们大概就能知道：产品价值 = 收益 – 成本。

最初工具 A的 收益是效率，成本是 技术开发 ，价值不好评估，可能收益不大；如果能开放使用，至少未来不会太局限，如果有机会做出来，也是盈利的机会。

总监经常和我说，产品设计其实是在设计一项业务，任何一项服务的打磨，都要当成是一门生意来看待。仔细回味这句话，确实没毛病。

站在公司角度思考业务，其实就是一种向上思考的过程。这种产品思维日常培养很重要，也非常实用。比如找一份工作的时候，思考自己的收益是什么，付出哪些成本，持续性怎样？

02 不了解行业信息，是惨痛教训

第一点中，我们说到产品设计是设计一项业务。而业务其实是市场和行业背景下催生的产物，一个运转过程。所以从这个角度来看，自己一开始对行业信息懵懵懂懂就开始设计产品，明显踩坑太深。

了解行业信息其实就是调研，这个过程我有遇到了三个问题：

1. 如何了解一个行业基本信息？
2. 如何找目标用户并调研？
3. 如何评估对用户了解程度？
   

1. 如何了解一个行业基本信息

为了熟悉行业知识，搜寻了相应资料。发现照搬有点不靠谱，太大而全，于是照猫画虎，整理出来的东西好像很厉害，但肚子里真正沉淀的不多；

做了无用功，花了大把时间，还没学到东西。

于是项目实践后，我尝试做一些删减，个人觉得做好这三点是能对行业有一个基本了解的。

• 先了解行业基本信息：知乎、百度、谷歌上找，通过搜索我大概知道跨境电商行业，有仓储、物流、采购、供应商、亚马逊平台等，再逐个细分下去深挖一下，我的知识面就更广了；
• 了解业务流程，及上下游角色：躬身入局，亲自实操一下；我们常用的做法是线下找相关岗位人观察，聊天，主要看他们做的 事情和协同交流部分。
• 了解竞品：有些行业信息竞品是比我们更早察觉的，看看竞品看他们的玩法，可以尝试注册，找他们的客服销售问问题。

回顾这个过程，其实还蛮有意思的：为了了解竞品流程，自己模拟下单遇到问题，说没办法解决。最后加了对方微信，还抛出一大堆疑问咨询。这个方式，你也可以试试。

2. 目标用户？怎么调研？

B 端 寻找目标用户，其实就是做场景的还原；比如做人力资源管理系统，我们需要找 HR 还原现场，沟通日常招聘、邮件发放、资料管理等。

在做场景还原的时候，发现自己没有提前做问题大纲的习惯，导致最终的调研产出内容非常零散；这样一来，需求分析是很容易出错的。

其实找用户调研的时候，很有必要提前准备一些问题，和用户聊的时候思绪会更清晰。比如 提前整理表格，列出核心问题，尽量不做无效沟通。

这里要注意的是，在问题设计上也有一定的学问，线下调研因为过程比较开放，话题相对问卷调研来说，思维不会闭塞。所以线下面对面沟通的过程中，问题要尽量针对关键点，提一些开放性的问题，让用户尽情表达自己的观点。

给一个模板例子希望能给你参考：

3. 对用户了解程度？

因为上一次调研，信息收集不全，导致后续自己三番五次  找用户请教问题。

因为对用户不够了解，遇到任何规则的变化，我们很容易陷入联想状态，假设的越多，错得也就越多。提供一个参考思路：

• 首先按照上述方式调研场景，整理并划分好用户基本类型和特征，这里的特征不是性格特点，是用户群体对行为的偏好。
• 针对不同用户类型，若预测用户在不同外部条件下的预期和行为，说明我们对用户的掌握基本合格。

比如用户登录密码错误，用户可能会产生懊恼情绪，会尝试找回密码，感受用户也是同理心的过程。

03 产品定位错误，是惨痛教训

产品定位的调整，是血淋淋的教训。第一点中有说到产品定位太窄。那现在，我针对这个坑点，来说说定位调整，给产品带来的影响。

产品定位踩过的坑：产品定位有用户、痛点、也有方案，但忽略了盈利和收益。

工具 A 最初定位是给内部使用，调研过程用户述求不断。让自己陷入了功能堆积过程。刚开始的架构思路 大体上是这样的：公司产品设计人员 负责打磨服务，产品管理人员负责运营管理，吸引客户和我们签约，服务售卖。

简单的看，是能够满足公司目前的业务，但总监看了之后和我说：我让你设计，是让你打磨出来，日后拿出来给 合作公司用，我是要收费赚钱的，听完恍然大悟。

后来站在其他公司的角度，发现需求依旧存在（有竞品），于是在方案上加了一层用户关系。把工具 A 迭代成服务平台。这样的改动，给产品带来盈利的可能性。

表面一些小改动，触动的是后台整个逻辑的修改。增加一层用户，实际上后台增加的有：账户体系、付费模块、数据关联表修改等。所以，做 B 端产品，决策路径很长，千万不能忽视了任何一个改动。

做出决定修改之后的一周，我将需求重新整理，按照调研的方式进行问题回访。对场景的规则和模块二次补充。产品工作倒无所谓，最可怕的是开发小哥因为我的调整，最终结项时间推迟一周多。

为了避免熬夜爆肝，产品设计之前，我们得先把定位想清楚。其次是，如果做一个产品，一开始就在不断累加需求，多问问自己用户是不是找对了。

04 产品设计不规范，是惨痛教训

经过这次项目经历，让我对经验和方法的重要性，有了新的定义：经验是轮子，给不了我们建设性的创新，但能避免我们在一条错误的路上，越走越远。

产品设计阶段做的更多是模块和流程性的梳理，先定义问题，再找场景，然后梳理规则，最后抽离模块；比如这样：

但这个过程也遇到了两个问题，十分困扰。

• 产品设计如何避免东拼西凑，有条理进行展开？
• 功能和规则这么多，配置怎么做？

产品设计时感觉自己信心满满，业务催催需求，就乱了阵脚，跳过功能设计开始画图。结果证明，越画越乱。

后来强迫自己回到正轨，会议、催需求，先晾着，完整流程先跑通（回顾一下我的整个流程，如果感兴趣，可以给我留言，后续加油补充）：

关于配置的问题：也是踩了太多坑，我们总想把所有功能都做成配置，用户想要什么，产品上给个界面，用户自己设置。

于是在这种思路下，我发现最后出来的产品后台，还没上线就显得十分臃肿。

过程中总结了部分规律，发现功能配置其实有一个核心思维在的：频次 & 范围 四象限：频次越高，说明使用非常频繁，用户量大，说明需求的集合也就越大，所以结合这两者进行思考配置功能，再适合不过。

以下为详情：

像电商后台产品，类似商品添加，价格设定这种，涵盖用户量大，且切换频率较高的，妥妥的配置。

05 评审成批斗会，是惨痛教训

直到项目开发，我才发觉要检查一下逻辑，看看文案，再想想交互。

于是准备不够充分，评审会高光时刻成了批斗会。业务会觉得比产品更懂需求，开发觉得逻辑理解优于产品。总之百口莫辩，事情讲不清楚，一个问题 N 多方案。

后来自己整理了一张自查表，项目开发之前，我时不时就会看下，这里分享一下：

按照这样的流程将自己的产品原型 从头到尾的梳理，假以时日，我们的产品逻辑肯定日飞冲天（鸡汤句哈）！

06 需求失控是惨痛教训

加需求了怎么办？

你是否有这样的经历：开发到一半，业务过来教你做人（做产品） 老板或者业务咨询一下需求状况，灵感爆发，给我们提几个优化，导致需求变更。

在做官网 B 产品的时候，我经历了两次官网核心下单业务的修改，主要是项目到开发阶段了，业务对需求二次定义，麻烦的不是补充内容，而是在修改，产品逻辑改动，可能对产品最终的走向都会产生影响。

新增需求我们要看对现有影响，也要看是否可持续。其次产品设计阶段，我们是比业务更懂产品逻辑的，如果需求对现有影响范围过大，不可持续，不符合产品定位，可以打回去。即便是新增也要尽量归并二期。

针对需求变动，在需求评审之前，很有必要拉上业务，将模块、流程、原型和UI 进行共享，内容走查，确保需求完善。当然，也要有一定领导力，主动推进项目，给开发小哥一点关爱。

07 项目延期是惨痛教训

项目延期了怎么办？

上线推迟，作为产品经理，我们怎么都脱不了干系。

为减少推迟上线对业务的影响，可以尝试：

• 提前制定里程碑：在什么时间点完成那些核心功能，提前准备内容；
• 上线二次预估：预计推迟到什么时候，保证后续资源能继续开发；
• 广而告之：将里程碑、现有进度、发布时间和开发 及 业务多方确认，想办法分配资源。

过程中，主人翁意识强一点，专业度就会有提升，别人会觉得我们靠谱。

总之让产品由我们掌控，把问题扼杀在过程，不能等到开发上线后再解决。

08 关于迭代的思考和复盘感悟

B 端产品迭代的思考

产品进阶是一个缓慢迭代过程，B 端类产品升级频率较低，但并不意味不需要迭代。这次实践过程，让我体会到 B 端产品更需要 关注变化。“牛鞭效应”就是一个很好的例子。

系统服务类的产品 实际上非常个性化的，本质原因就是因为场景的不同。比如我们把一个产品开放，即便基本模块都有，遇上不同客户，定制化需求依旧很多。

系统服务类的产品很多时候是在还原 场景，服务多少企业，可能就有多少种服务方式。

所以，B端产品个性化是件好事，很多企业初期就是在提供个性化服务，待成型，才考虑标准化。

最后分享复盘的五点感悟：

1. 问题复杂度越高，解决过程越投入，成长也会更快；
2. 产品方法论终究是方法，实践内容和结果还是得自己慢慢找；
3. 如果解决问题的方案过于复杂，不纠结，有可能是问题本身不对；
4. 以用户角度看问题，以生意角度思考业务，比如收益、成本，是否一直存在；
5. 复盘包含：实践、思考、回顾、调整，难在调整，因为是推翻自己的过程；

本文以自己项目经历在此抛砖引玉，如果大家有不同意见欢迎一起交流。希望能和喜欢写字的你，交个朋友。

本文由 @好奇产品铺 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。