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