对“技术质问产品的几个常见问题”的回答

给某大厂的技术新人做了一个关于产品思维的分享，提前收集了一些困惑，贴几条提及最多的，稍微聊一下。

哦对了，先帮产品说句话——技术同学，千万别简单地用“那个产品是傻X”来回答以下问题。

这是因为，作为技术，如果你总觉得和你配合的产品都是傻X，那大概率，别人会觉得你也是——要不然，为什么选择与傻X共事？

所谓 “若，我看周围皆傻X，料，世人看我亦如是”。

“需求改来改去，好不容易上线了，最后又不用了”

这句话是个结果，背后的原因有很多，比如用户确实变了，需求确实变了，市场/竞品确实变了，又有新的增量信息，产品一开始没想透，产品只是在被动响应需求方的变化，做需求本来就不是为了给用户用，…… 这得对症下药。

如何更好地应对需求变化？无非两种思路。

一是预防，主要指交给开发前，从源头上减少变化，升级流程规范，提升产品团队能力，等等；

二是治疗，主要指交给开发后，着重降低变化引起的成本，“假产品”的实验，更灵活的技术架构，等等。

还有？还有就是心态要好——要相信，这已经是产品在当时尽了最大努力的结果了。

最后，保护好自己，不要背锅。

“产品想法天马行空，完全没有考虑系统的可行性，产品方案不周全、有明显的逻辑漏洞”

技术这么觉得，多半是不认可需求的价值，这让我想到了一个古老的段子——

产品找技术做一个功能，讲了半天理由，技术用关爱白痴的语气问：“你觉得自己说得有道理么？我不做……”

产品没办法，说出了最后一个理由：“求求你还是做吧，我要写周报啊”。

技术想了想，说：“好吧，我做，因为我也要写周报啊”。

我们要关注的，是区分“被动需求 vs 主动需求”，老板提的某些需求、因为竞品做了我们也要做、为了写周报憋出来的需求，显然都是被动响应式的，我们还是要多从用户那里找需求，是谓，我们主动想做的需求。

主动需求，有其天然的价值感，更容易在团队里获得认同，“方案不周全”也没关系，大家一起想办法解决。

“为什么业务方要临时上一个明显不靠谱的方案？还不如晚两周，给到一个更完美的方案”

这条和上一条有点类似，但这条似乎更强调要“赶时间”。

其背后有个很重要的原因，是考核方式——

产出与结果，或者说output与outcome，到底考核哪个？

产出是指做了多少事，结果是指创造了多少价值。考核前者就不要质疑产品会给你堆功能，考核后者就不要总觉得产品啥事没做。

很多时候，更多的调研、“假产品实验”，得到的结论可能是“ABC都不应该做，D还需要再研究研究”，这是有价值的，但看上去，似乎没什么落到产品上的功能。

这种情况下，产品会被质疑摸鱼么？技术又如何配合一起探索那个“更完美的方案”呢？

“产品梳理需求不清晰的情况下，技术如何能帮助发现问题”

需求不清晰，在很多创新领域都是常态，这里可以借用投资领域的一个说法——不预测，只应对。

承认看不清，猜不透，所以，对要做的产品功能没把握。

这时候，我们可以“少洞察，多实验”，提出各种“关键假设”，用各种“假产品”来做“原型测试”，从而让需求越来越清晰。

乔布斯说“我不做用户调研，因为用户也不知道自己需要什么，直到我把那个东西拿到Ta面前，Ta才会跟我说——这不是我想要的”。其实，这就是乔布斯的调研方法，我们也可以学。

技术在这时，能发挥的就很多了，可以帮助产品用各种技术手段，更“多快好省”地做各种实验、假产品。

“业务侧需求爆满，留给技术侧的开发时间很多时候都非常紧张，这种情况下，技术如何从用户体验的角度做好优先级排序”

我们总有一个妄念——功能越多，产品越强。

我们也有一个误会——高估添加新功能的价值，低估优化老功能的价值。

需求爆满是常态，但80%的需求，做和不做没啥区别，也是常态。

我们要放弃妄念，解开误会，回归用户，把用户已经觉得不错的老功能，精益求精，毕竟这些老功能，往往是产品一开始就要满足的“刚需”。类似“维护老客户的成本，远低于开发新客户的成本”，放在产品功能上也是一样的。

当然，我并不是说就不做新需求了，随着行业竞争越来越激烈，当然要参与这个“军备竞赛”，只是，适当的抛弃妄念，重新思考（注：有些产品，比如企服，确实需要“啥都有”，这时候就要“先补齐”，本质上还是要理解用户）。

以上问题，互相牵扯、一团乱麻。而我的回答，也有“互文”效果。

年年岁岁问题似，岁岁年年人不同啊。

_________

苏杰（iamsujie），产品创新顾问，《人人都是产品经理》系列4本书的作者，阿里前8年产品经理，集团产品大学负责人，良仓孵化器创始合伙人。如需产品经理/产品思维/产品创新相关领域的培训咨询服务，欢迎联系这个微信（13758212411）。