阻碍你向上的，是「差不多就行了」的思维
假期跟开发朋友在聊小公司的那些事，对方提到说：“最烦跟对方说，这接口差不多能用就行了。”
PS：好比你写作文，不能自带笔，只能是场地提供。最好是那种0.5mm 黑色中性笔。但现实是场地只提供红色、快没水、笔尖还很粗的那种。
也能用，但就是用着不舒服。
这些人，做事的标准就是「交付」，既不考虑求精，也不考虑对接的人是否舒服。
总之，年轻时的那股子冲劲全没了，取而代之的是混子般的心态。
事后我也有思考他说的这些话，对标我们产品经理的工作会是什么呢？
大概是对上线后的功能不管不顾，谁爱用谁用的那种心态吧。
一、哪有一步到位的设计
就算我们力求完美，但也无法保证自己的产出就是对的。
大多数情况，都还是在迭代中不断完善功能，让用户越用越舒服。
尤其作为刚入职场的新人，在思考和判断的经验都不足，产出的质量就更低了。
之前有个面试官对我说过：“刚毕业一年左右的新人，都是在小孩活泥巴，没什么质量。”
“把自己的姿态放低，多看、多学、多反思比什么都强。”
这些话在我做迭代的过程中，尤其受用。
01、内心强大一点，脸皮也厚一点
功能上线前，评审时开发常会说：“流程为什么要这么走？不大合理吧？”
功能上线后，与业务对接：“客户说这个不好用，你这怎么做的？”
刚开始工作听到这些，虽然告诫自己要冷静，但小情绪难免会上来，于是就多了很多无效沟通。
后来被吐槽和批评的多了，我的开场白基本都是：“你（客户）觉得哪里不合理？遇到的问题是什么？”
稳住心态、引导对方，让彼此就着问题和自己观点讨论。
你说服得了我，我就做调整。
我说服得了你，就按我的来。
总之，一切围绕着问题展开，到现在慢慢也能控制得好自己的情绪了。
这个过程中，我也发现了自己很多基本逻辑和设计上的错误。
02、功能设计我犯过的几点错误
1、没有做好操作闭环
在跟客户沟通时，对方有反馈过列表中的某个字段没办法检索。
这明显是我设计上的问题，主要原因是：早期设计没考虑列表字段过多，且都允许搜索的情况。
其实应该有「高级搜索」的存在，区分常用和不常用的搜索字段，方式如下图：
2、没有结合操作场景
对于数据管理模块，客户需要阶段性导出数据。
常规设计中，最常见的是：条件筛选 → 勾选导出数据 → 点击「导出」按钮。
但实际中发现，客户会将某一时间段的数据「全部导出」，而非原先我理解的「部分导出」。
显然这是不了解实际业务场景，做出的错误决策。
因此，在后续迭代中新增了「全部导出」功能。
3、不符合设计和展示
在设计数据看板时，考虑到筛选条件比较多，我将筛选结果统一放在弹框中，而非在外部直接展示，如下图。
这个点在上线后，也被客户吐槽说他们想看筛选条件，还需要多一步点击操作。
而实际上，完全可以外置展示，如百度统计这种。
以上这些，都是我在完善功能过程中才意识到的自己的错误。
二、不断做、不断错、不断总结
在我不断犯错和调整的过程中，我将完善功能的来源分成了两类。
当然，主要是针对 B 端产品的。
01、客户反馈
由于是 B 端小公司，用户体量不大，因此直接跟客户聊是最直接活的反馈的方式。
而且，有时就算你不主动找客户，他们自己也会来吐槽的。
在跟他们沟通时，同样也是围绕问题展开，避免情绪沟通。
说起来，这部分跟我收集客户需求的方式基本一致。
主要还是搞清楚：
（1）谁？（确定客户，以及使用角色）
（2）在什么情况下？（明确业务场景）
（3）因为什么？（了解流程上下游）
（4）碰到了什么问题？（产品经理要得知问题，而不是对方直接给出的方案）
（5）现在是怎么解决的？（判断问题严重程度、使用频率、影响面）
方法论不在多，在于能稳定、高效地解决问题。
02、漏斗模型
自从今年 5 月做起 App 数据埋点后，每周会观察下功能的使用情况。
像是我之前在 7 月份上线的 App「创建事件」这个业务功能，是解决违规门店整改要求的业务问题。
上线后通过漏斗模型发现，功能的使用情况非常差。
随后跟客户做了回访，才发现是对方内部还没开始做统一要求。
也就是，只有部分门店店长自觉整改，但发现没有人反馈。
久而久之，这个功能的数据情况也就惨不忍睹了。
以至于现在，我想优化这部分功能都无从下手，因为没有人用。
讲真的，B 端产品是真的基于业务驱动的。
这就好比，如果公司不要求你钉钉打卡，你也就不打卡了一样。
写在最后
说起来，产品经理的成长都是靠一个个的项目堆积起来的，但前提是自己要有 ownership 和 leadership。
不能上线了就不管，也不能做了就不迭代优化了，差不多的心态是不可取的。
对自己的产出负责，本质上也是对自己负责。
好在自己工作还不久，虽然很多事儿会力不从心，但这股子热情到现在依旧不退。
希望我分享的这些能给你一些启发，加油~
-END-
