从做电商转到做工具，几个月做下来，笔者发现产品属性对于产品思维的要求是不一样的，而从整个产品设计到上线的过程，笔者也有五大思考与大家一起分享。

过去四年的时间，我一直在做电商类产品。最近半年公司战略调整，我被划分到了新的业务线开始从0到1打造一批出海工具类产品，今年的目标是达到日活达到50万，这个是立了军令状的。

从做电商转到做工具，几个月做下来，我认为两种不同的产品属性对于产品思维的要求也是不一样的。

比如电商产品更加注重「数据思维」，产品的改动往往需要数据作为支撑，「漏洞模型」是重要的环节之一。而工具类产品在很多时候则需要反复思考其在体验和设计上的「合理性」，尤其是出海产品在构建之初是「距离」用户是很远的，产品经理往往需要依靠自己的感性经验和对使用场景的构想来进行设计。

再比如电商产品依靠出售商品本身已经有自己的商业模式了，而工具产品往往需要借用到「广告」来实现营收。如何巧妙的加入广告而不引起用户反感，也是需要反复琢磨的。

考虑到Google Play特殊的生态环境，在打法上我们采用的是「产品矩阵」的策略，就是针对某一特定领域，会批量的上架不同定位的产品，然后配合上运营的ASO方案多点开花。

在产品功能上，我们的思考是采用「瑞士军刀式」的功能设计，就是一个产品会内含多个核心功能，每个功能在体验上都做到尽可能的做到极致。在宣传方面可能只重点介绍其中一个功能，但是实际的体验上让每个细分功能都拥有较高的易用性。

几个月下来，我们目前已经上线两款产品并投入运营，而从整个产品设计到上线的过程，对我来说也是一次新的挑战与尝试，在这个过程中有以下几点思考。

01 所有的流程都是为结果服务的

产品规模到了一定程度的时候，从设计、产品、开发到测试，需要建立相对完善的流程，确保每一次的产品的变动与调整都是在流程内进行运作，减少人为因素带来问题的可能性。

但是这次做工具性产品，我们整个团队都是新组建的，无论是团队还是产品，都是一个从0到1的过程。这个阶段我对于流程的看法一直是持「探索的态度」——到底什么样的流程适合我们？我们需要制定哪些规范和原则？如何让流程帮助、而不是阻碍到产品的打造？这些是我一直在思考问题的。

这个阶段我很担心的是团队里的成员「拿一些固有的流程来解决当下的问题」。比如产品提测时候，我肯定会反复体验和反馈，这个时候发现有些地方设计的不是很合理地方，我就会直接提出来要求开发进行改动。但测试人员在面对此类问题时会出来对我说：按流程来讲，你这属于需求变更了，我们需要走需求变更的流程。

而实际上也就是开发随手就改掉的事情，如果一旦上升到需求变更的流程，整个过程就会变得很麻烦，尤其是在产品的初始打造阶段。

所以我的总结就是：在工具性产品从0到1 的过程中，流程要尽可能的简化与灵活。而且所有的流程都是为最终的结果服务的（好的产品）。如果流程反过来没有帮助到最终的结果，反而因为流程的存在制约了很多问题的快速解决。那这种流程就是特别愚蠢的、不合理的流程，就应该被废弃掉的。所谓黑猫白猫抓住老鼠的就是好猫，也是这个道理。我们看重的是最终的结果，而非过程。

初期打造产品的阶段，流程没必要绝对的完善，只要能够输出的高品质的产品，那么也就是合理的。反之，流程再怎么规范，输出的结果却很垃圾，那么这样的流程也就毫无意义。

02「是否合理」是检验工具产品的主要标准

我们都知道「实践是检验真理的唯一标准」，这句话套用到互联网领域可以是「用户是检验工具产品的唯一标准」，但是很多时候产品还没上线该怎么办呢？这个时候我认为就应该强调「是否合理」是检验工具产品的主要标准。

之前公司的测试人员对我说过一句话「产品文档对我们而言就是圣旨，我们都是以你的需求为准的」。

这句话听起来没什么毛病，给予了产品文档足够的尊重，但是背后隐藏的含义却很有意思：一切以产品文档为准，言下之意就是产品文档无论是对错，我们都应该以此为准。

这其实是一种惰性思维，实际在新产品诞生的环境中，产品文档怎么可能做到100%的准确无误呢？怎么可能做到覆盖100%的用户场景呢？

这个中间会有一定概率出现纰漏和疏忽，尤其是我现在面临的情况：同时推进多个产品、一个人面对十几位开发人员。

所以无论是开发还是测试，在看待产品需求时都是带着辩证的思维去看待，要评判产品文档是否合理？产品文档所覆盖的情况是否存在漏洞？产品需求的出发点是否与实际的用户使用场景相吻合？

如果开发和测试的过程中发现不合理或疏漏的地方要及时的指出来，而不是用「产品文档对我们而言就是圣旨」这样的话来掩盖自己不愿意思考的行为。

我特别喜欢开发人员就产品上的问题来质问我，因为质问的动作本身就表明了开发人员其实是在思考产品上的问题，而非单纯的产品让开发做什么，他就做什么。

所以在整个团队里千万不能有「对产品经理负责」的想法，整个团队都应该是抱着「对用户负责」的想法来做产品的，每个人都要有产品意识、需要判断产品的设计是否合理。

03「最小化可行性产品理论」的局限性

最小化可行性产品（简称MVP）的概念是Eric Ries 在《精益创业》里提出的。简单地说，就是指开发团队通过提供最小化可行产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到产品到达一个相对稳定的阶段。

这个概念做过产品的人应该都很熟悉了，在一定时期内也被奉为真理一般的存在。但是我最近反思下来发现MVP理论有其自身的局限性，它更适用于一些创业公司以及新兴市场。

新兴市场的需求往往是不明确的，这个时候需要快速的做出产品到市场上进行验证，获取用户反馈后再进行迭代。比如微信早期的功能就极其简陋，甚至IOS系统1.0版本也是极为简单的。

但是现在的市场竞争环境已经发生了极大的变化，在大量的领域已经诞生了较为成熟的产品，MVP理论在这些成熟的市场环境里已经是完全不适用了。

比如AirPods切入的是无线耳机市场，但是在AirPods切入之前，该市场已经是红海了，所以苹果的做法就不再是用户最小化产品去进行尝试了。而是利用其强大的产品和供应链能力，一次性的把体验做到极致，让AirPods一上市就直接干翻所有竞争对手。

之所以谈这个问题，是我们所做的产品也是从0到1 的，在整个过程中，团队内部都有较强的MVP产品的思想。认为先做一个产品，推到市场上看看再说。

但是我在进行市场调研的过程中，发现我们所切入的市场已经有着相对成熟的竞争对手了，市场环境并不允许我们再做一个MVP去进行验证，我们推出的产品必须是在综合体验上领先于竞争对手的。

而这个时候，就需要整个团队产品观念的转变。

04 开发人员的产品意识是逼出来的

好的产品背后肯定是一个牛逼的团队！这个道理是我在很早之前就意识到的，单靠某个人的产品意识和能力，都是难成大事的。

但是「产品意识」这个词说起来简单，做起来极难！尤其是提升整个开发团队的产品意识上。

很多显而易见的错误，一个缺乏产品意识的开发人员会完全发现不了，硬等着别人去提醒。还有就是凡是产品文档中没有覆盖到的地方，一概不考虑、不做，也不愿意思考。

搞到最后就是，开发交付的东西存在各种奇奇怪怪的问题，不问则罢、问就是扯皮。每个开发都这样搞下去，就会产生极大的内耗，最终结果就是做出一个垃圾产品。

我们团队在组建初期，就面临过这样的问题——开发做东西应付测试，测试应付产品，产品怎么办呢？难不成去应付用户？

当时我一想，不对啊！团队里的开发都是工作至少3-5年的是中高级的开发人员，为什么凑在一起反而做不好一款产品呢？

但是我也发现其中有个别的开发人员产品意识很强，很喜欢去质问我产品上的问题，交付的质量也很高。后来我去请教对方，问他为什么会有这么强的产品意识。他的回答是：是被逼出来的，之前所在的团队里只要做的东西有丁点问题，就会被一群人追着说，后来就逐渐把他逼的必须有产品意识了。

反应过来这个道理后，我就围绕着「产品意识」这个事情反复的去给周围人讲，我讲完还不行，让开发主管也讲、也运营也讲……

通过这样一个多维度轰炸的过程，开发人员的产品意识才可能真正的提升起来。

05 你是什么样，你的团队就是什么样

在产品上我是一个很坚持的人，但是在和团队相处的过程中，我是一个很不愿意让别人尴尬的人。

平常在团队里发现一些问题，我很少会公开的提出来，为啥呢？有些问题属于开发团队的，我去提出来不是让开发主管难堪吗？而有些问题又涉及到企业文化和公司的管理模式，我直言不讳，对我也没什么好处。

但是我最近在琢磨两件事：

• 我的核心目的是打造一批优质的出海工具产品，所以我不应当对团队出现的问题坐视不管，毕竟团队都出问题了，还怎么去打造好的产品呢；
• 我认为只要我的出发点是为了团队和产品考虑，我就应当更直接的去指出团队的问题，没必要过于顾忌「面子问题」。

所以虽然我们公司的文化相对保守，但是现在我也放飞自我了，只要发现哪里有问题，我就直接提给相应的负责人，并且跟踪问题的解决。

因为我的理念是：我需要打造优秀的产品，我就必须让整个团队都是优秀的。我是正派的人，我也影响到整个团队去形成正派的风气。

以上几点就是近期在做工具性产品的思考。

#专栏作家#

旺仔九号，人人都是产品经理专栏作家。心理学硕士，服务电商类产品经理，微信号：Jackaniy（添加请说明来意）。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash ，基于 CC0 协议