总结一下就是用户不爽的原因往往不在于他们所说的，产品人员需要进一步去挖掘。而挖掘的核心个人认为就是“价值认知”。之所以不爽是因为这步操作没有让他感觉到有价值。这里借用福特的依据名言：如果你问客户需要什么，他们只会告诉你他们需要一匹更快的马。

　　1.1.3 想着一步把功能做完整

　　刚开始上一个功能总是追求功能模块的完整性，但一个功能最初上线能够满足基础的需求就可以了，非必要的都可以砍，后面再慢慢完善。

　　在初次做OSS的设计时，企图一下子做一个完备且专业化的用户筛选功能，提供各种可以进行的筛选维度，外加“与、或、非”三种逻辑间的组合关系。然后初次需求讨论会的时候就被否了。因为我们的运营人员并没有接受过逻辑方面的训练，“与、或、非”的关系根本理解不了，而且多维度的复杂筛选会占用大量系统资源。所以只保留一些易于理解的筛选维度。简化版本推出后发现，我们的运营人员对各种维度的组合应用完全抓瞎，无法做到举一反三，只能是我告诉他们哪几个维度组合在一起可以筛选出什么样的用户，各种分析情境下需要通过哪些维度的组合调出哪些数据。最终实际应用较多的只有开发内容的一半，另一半基本不会使用。

　　这个功能的设计给我的教训有三个：第一是开发过程中，第一版应当尽量选择常用的功能，对于不常用的功能可以在迭代过程中根据需要逐渐加上，而非追求一次性把某个功能做的完善；第二是要考虑到使用人员的实际知识水平，有些需要专业素养的东西，一些门外汉短时间内是学不会的；第三是要考虑各种数据的积累量，一些数据积累的量很少，没有可用性，所以相应的筛选维度也就不会发生作用。

　　1.1.4 老想着让开发人员一版能多做点功能，快速完善APP

　　一个初创型的企业产品需求变动会相对较多。这时快就是慢，慢就是快。因为在急促开发的情况下，开发人员写出的代码在后期更改时就会十分的麻烦。但是如果初期开发过程中给予足够的时间，让开发人员将较多的模块写成可以灵活更改的（当然前提是开发团队有这个能力和觉悟这样做），后期改动时所花费的精力则要小很多。开发人员在后期对功能进行调整时也就不会有太多的抵抗情绪。这样前面慢点，后面就会快很多。而且说实话，真正必要的功能其实并不多，很多都是自己以完善为名加入的非核心功能。

　　1.2再说一下看到别人走过的坑

　　1.2.1 过度超前——阻碍重点模块的优化进度

　　我到公司以前，我们的APP就设置了待录用、待上岗、待结算、待评价4个模块。但时至今日除了待录用之外，其他几个模块对用户都没有什么实际效应。此外没有实际应用的模块还有很多。究其原因就是我们在按照心里预设的商业模型埋头进行产品的完善。忽视了实际运营中内外部用户的实际使用情况，使得产品过于超前。

　　产品开发超前带来的负面效应主要有三块：第一是阻碍了初期一些重点工作进度。比如到现在，重点流程页面的埋点工作依然没有做。使得产品优化缺乏足够的参考依据，比如产品技术架构的更新滞后，在很长时间内产品很多内容的更新都需要用户主动更新APP才能实现。第二是会占用更多的开发成本。一个功能上了之后想下来就很不容易了，从产品到开发大家心里都会比较难以接受。就以待上岗、待结算两个模块为例：为了能够保证模块中提供数据的有效性，我们根据用户报名的不同职位类型、做过哪些操作等一系列的逻辑进行区分。而根据我们所拟定的逻辑，即便再过几个月也不会有几个职位能够出现在待结算的环节中。第三就是导致资源浪费。毕竟对于创业企业研发还是挺贵的。前几天跟以前离开的产品总监聊了聊。由于那些不必要的功能，浪费的研发资金上百万还是有的，够做几次不错的营销活动了。

　　1.2.2 群策群力——群体智商通常低于个人智商

　　我们公司技术部开始时喜欢调动大家讨论，甚至大家投票表决一个产品或是运营的策略。这是一个很糟糕的方法。所谓头脑风暴，正常的运用是大家一同讨论后，收集各方的意见，再由专业人员进行整理与分析，最终平衡后得出一个相对恰当的解决方案再由领导拍板决策。