2020-08-13

@产品成功的标准
产品成功的标准

https://www.zhihu.com/question/20189327/answer/1400032756

好比语文考试， 有主观题，也有客观题，通过主观、客观2个方面就能比较好衡量产品的成功与否。

成功的产品往往是下手前就预见到了成功。 很多团队领导人非常盲目，曾经有创业团队的技术负责人和我聊，我问过他一个问题，什么是成功的标准？ 他说了一大堆天花乱坠的话。继续问，跟着你的这些兄弟在北京能解决基本生活问题吗？ #@$#@% ，他就无话可说了。反过来说，跟错一个错误的人是很悲哀的。 一个从未想过成功的人，是不可能搞出成功产品的。至于成功产品的标准是什么， 每个人的角度都不同，会有不同答案。 重要的是要独立的思考过这个答案。 这个答案对不同方向的产品可能是不同的。

客观上：
市场上同类产品中的竞争力，尤其是互联网行业，排第一，还是排第二， 影响非常大， 前几名是赢家通吃。具体来说， 就是要比较 注册用户数、活跃用户数。

DAU/MAU 是衡量产品的重要标准，但在这些情况下不适用
​
www.sohu.com
图标

不同类产品之间的比较， 可以看投入的时间、人力和金钱， 产出快，人力少，投资小的，比耗时长、人力庞大、投资巨大的成功。

更细微的比较往往被人忽视， 共赢。产品团队的每个人、至少是主要参与者能财富自由，至少是技术能力、收入、行业知名度的提升。这个决定了产品的成功能否持续。很多产品关键人员离开，导致竞争力下降。所谓的MBA型管理者、投资人，对产品失去行业领先地位的原因还不知道怎么回事。

底线是能形成商业闭环，至少能有收购价值或者对公司其他产品是补充。既不赢利，又无收购价值，即使同类产品排第一，也是失败。

主观上：
这个一般人谈的比较多，产品经理相关的书已经说的很好，不再多说了。

易用性、满足需求、交互能力、可靠性等等

所谓主观评价是这个意思，并不是完全和客观的对立，比如你说这个产品易用性第一，肯定是有实实在在的理由，但是外行、投资人、不同的用户可能体验的不同。

或者说技术最好，可能确实是真的，但是什么算技术领先，什么算技术最好，外行很难判定。产品的主观标准还有个特点，就是对时间节点、商业闭环考虑的比较少。 最初级的，就是说我用了什么AI技术或者很牛逼的技术，甚至幼稚到我用了什么开放语言，用了什么框架。

如果只有主观标准，容易出现无法理解的产品失败， 忽视创新精神和机会；如果只考虑客观标准，可能会出现团队不好建立，找到合适的人不容易，找到了，日常团队管理也困难，无法衡量产品开发的壁垒（技术壁垒对市场当然也是重要的因素，越高，越容易阻击竞争对手模仿）。

对天使阶段以前或者内部创新的几人小团队，建议先重视客观标准，再重视主观标准。 资金充足、人力充足的情况下， 完善主观标准。

当然这个也和一个人的思维模式有关， 如果一个人乐观又聪明的话， 可以直接以客观标准为导向， 如果一个人还不够自信的话， 可以先从主观的角度入手。 如果一个团队缺乏顶级技术 大牛， 一般还需要团队培育相当时间。 不过不建议创业团队这么搞，技术能力、创新能力到底能不能培育出来，培育出来，人员会不会有流失，这都有巨大的问号。

通常做过几个成功产品的人，即使不具备一些技术，也会习惯先选择客观标准。

从HR、打工者的角度，主观标准比较重要，从创始人、投资人的角度，客观标准比较重要。

标准

软件开发者和运动员可以做个类比，更高，更快，更强。
什么算更快， 运动员跑得快， 秒表就能见证。 程序员呢？ 标准未必能反应全部真实，但是有标准还是必要的，能激励人。
人总是有惰性和懦性的。 好的标准能激发潜能帮助人突破局限性。 从事软件开发初期思考过的标准的问题。
想到的第一点是单位时间代码产出的速度。 当然有人也会以几百行的经典代码反对这个标准。但是对于初级开发者来说，这个标准还是有价值的，简单。

再到负责产品、项目的时候，想到一个版本2. 两个速度衡量。 第一个速度，快速推出具有MVP功能的版本。 第二个速度，在第一个版本的框架下 ，精致、完善版本推出的速度。 用这两个速度衡量。 这么思考的根据是， 一方面满足市场、运营 的时间窗口，一方面反映软件开发过程本身，以及建立竞争门槛。

现在想到版本3. 要考虑大公司在成熟阶段对软件开发的要求， 维护软件是最耗时的，而很多996公司 由于外行的介入，让程序员疲于奔命，而事多功少。 再版本2的基础上， 要考虑到 重构，不断重构的技术能力。衡量在于能不能让程序员有更容易维护代码，并有时间 思考更多潜在的创新机会，掌握更多新技术。初期团队应该避免过早的优化，很多大公司出来的人急于建立从大公司习得的一套管理软件开发的办法，往往会降低组织的效率，比如引起和其他部门的沟通障碍或者开发团队本身也容易出现矛盾。在时间急迫的压力下，又同时要求架构、代码其他完美的标准。 而初期团队招募的人中也可能有不少人没有大公司经验。有个玩笑，谋害一个初期竞争对手的好方法，是推荐一个来自微软、BAT等大公司的“合适人选”去给他们做技术总监。

最后这3个标准仍然相互可以支撑， 用3个不同角度的标准对软件开发能力能有个更全面的理解。 对外行来说，容易对功能、需求增增改改，这个时候可以拿出版本控制代码的变更量给外行看。 对过分强调专业，把技术等同于软件开发的人，要有第二个版本的标准。 软件开发不是简单的学术、技术和编码，不能庸俗化理解软件开发。

早期互联网开发者和产品经理不是截然划分开的， 甚至有的开发者扮演产品选择方向的角色， 但是人的精力有限， 而且人性的弱点决定了大多数在KPI压力下，容易回避高标准的产品要求，这当然是产品开发的大忌。
虽然最好的方式是，一个人同时能兼顾产品和开发，但是这样的人选不好找。

而两个角色分开后， 会因为产品经理缺乏技术理解力，导致沟通障碍，以及产品设计有盲点。弱势的产品经理，可能放弃更高的挑战。

对于有创业想法的软件开发者， 第2个版本的标准最有价值，即使技术、架构上不是那么 精致，具有快速推出MVP的能力，用商业价值的角度衡量是最有价值的。 而定位在一个大公司做高管的话，第三个标准就比较重要了。这也是为什么有的大公司高级技术主管反而不一定适合0-1的创业团队的原因。 他们太容易把自己作为大公司一个螺丝刀眼界直接套用到0-1的产品开发过程中。

大多数人也没有坚持第2个版本，做个有创业可能的开发者，在外在考核、流行技术的影响下丧失了锐气。

以上适合普通人，也许会有天才的开发者是例外。

最后要说的是，标准只有真正内化为开发者的信念中，才能激励自己，而不是人云亦云。标准是为了保持开发者像一个运动员有着良好的训练，信心和体能。