产品工作深陷繁琐事务与无效增长的内耗，增量稀缺消磨着工作热情？逆向产品思维提供破局思路：跳出 “先开发再验证” 的传统逻辑，用敏捷思维提前测试广告、模拟功能、收集用户反馈，在不盲目投入开发的情况下，快速验证 PMF，让产品价值自然浮现。

我的认知中，产品工作是需要花大部分时间在探索性内容上的，以此创造出新的增量价值。但目前大部分产品工作让人感觉心里憔悴的原因在于：

1.大多数工作是不得不做的繁琐类事务；

2.单纯以增长为目的，在各方压迫下不得不做的表面功夫；

这是大多数企业环境下产品工作的真实写照，也是多数人逐渐对这项工作失去热情的主要原因之一。

放在我自己身上，也会有这样的感受，尤其是在近几年，常规互联网增量价值的可挖掘性真的过于稀缺，找不到好的增长因子，有时候做事心态上也难免有点悲观。

但最近看到一个关于敏捷概念的观点，对我自己还是蛮有启发的，总结了说就是

“试着逆向做产品，用敏捷思维快速找到产品的价值”

具体是什么意思呢？

传统的产品构建流程中，一般都是先花时间找产品的使用场景和定位，期间还不乏会有一些调研工作，整个前期的工作我们其实可以统称为一个小型的PMF前期验证过程，所有的目的都是为了找到业务的确定性。

直到第一个小版本上线，数据上客观看得到的确定性出现后，才算是整个0到1工作的结束。

而在整个过程中，工作最艰巨最重要的部分我个人认为是构建产品定位和模式，但传统的敏捷思维在这个阶段往往运用不上。

确实，核心定位和模式都不知道，怎么快速迭代，迭代什么。

所以整个产品前期摸索过程，我们能不能假设已经有了第一个小版本，能不能用其它的方式来验证它的PMF是否成立？

答案是完全可以。

测试相关产品广告素材的受众程度；

收集意向用户名单；

甚至是对客户预收款项的提前试探；

….

这些目的都在于测试用户对于新产品的接受程度，以及为迈出构建产品第一步提供方向。

用敏捷的方式做业务做产品，让用户与产品提前发生碰撞，是逆向做业务做产品的核心思想。

包括在产品的正常迭代中，大多数团队对于敏捷的做法还只是停留在开发层面，认知到位，但大家对于业务的认知不够，就一定会动作变形。

往往都是，把大模块划分成小模块，把大功能拆成独立的小功能，对于业务发展本身起不到任何作用。

在这，我就不得不提我们之前在做相关迭代，最常用的三问法：

1.用户没有这个功能，现在是怎么做的？

2.用户有了这个功能，真的会这样做吗？

3.用户有了这个功能，也这样做了，真的达到他想要的效果了吗？

过往的经历中，第一个问题很好得到答案，但第二个和第三个常常没有确切的依据，往往依靠第一个问题去做二、三问的推演。

但是如果用逆向的敏捷思维，或许就能得到一些答案。

不实际开发功能，而是在界面上提供有了这个功能的假象，看看有多少用户实际会被吸引，有多少用户真实会有反馈。

大部分场景中，这样做确实能够有不错的验证效果。

拿早期的字节案例举例，用AB测试去衡量不同引导页的引流效率，直接让数据说话，而不再是依赖产品经理的经验和思考推理，把部分脑力工作硬生生变成流程化的测试工作。

当然，在这里我并不是说大家不用再思考了，所有的探索性工作都可以尝试借用这样的思维方式解决，给大家另一个角度的解法而已。

毕竟增长困难，如果长期如此，大部分人避免不了花越来越多的时间在毫无意义的工作内容上。

工作时间越长，越是不希望好的点子只是停留在假想阶段，好的产品也从来不是一蹴而就，有的时候不妨当个“测试”，试探着让让产品自己长出价值。