什么是产品原则

产品经理的日常工作中,经常会出现如下两种情况:

①、一件事情有价值,但是价值无法在短期内度量,甚至会带来短期内的数据下滑,但是大家都清楚长远来讲这么做对产品是有益的,做不做,怎么做;

②、一件事情有价值,但是也会带来伤害,怎么去平衡优先级,比如某个特定页面想要采取一种新的交互,会更加高效但是与现有交互不符;

其实针对这类问题大公司能够有比较好的处理手段,比如上 A/B,上更复杂的 A/B,更精确的 A/B,完全用数据说话,一旦灰度没有问题就放全量。但是对于中等规模的公司来说就会比较蛋疼,很多公司会选择 Case By Case 的讨论,但是随着业务规模扩大,团队人数增加,开会讨论这种问题其实是很费劲的。毕竟 10 个人开 1 小时的会议实际上是耗费了超过一整个人日,尤其是这种涉及到价值观之争的。

为了解决上述问题,很多公司会采取一个策略,叫做制定产品原则,在不同的公司可能叫不同的名字,比如「产品价值模型」,比如「产品设计原则」等等。

所谓的产品原则,就是指在产品设计、运营、迭代等过程中需要遵守的一系列共同的规范,原则这种东西如果没有上升到一定程度是不可以被打破的,同时原则通常也是内容很少的,是非常底线的,并且尽量避免互相冲突。

产品原则在实践的时候其实是一种「用共同的信仰」代替「复杂的度量」的一种手段。科学度量是丰满的理想,但现实是度量本身就有成本,因为不是每一个公司的每一个项目都值得用复杂的 A/B 实验来去进行度量的。

但这并不表示这些原则就是不科学的,产品原则来自于团队的实践,比如在过往的业务中发现「低价」就是比「交互步骤一致性」或者「出票速度」快要更重要,那么「低价」就是最高价值这个原则就不需要每次写需求之前都再进行评估一遍,破坏了交互流程又怎么样?

举个例子,各大 OTA 的机票搜索相比火车票搜索要慢 3 倍(可以自己打开 App 试试看,火车票一般是 1s 多一点,机票是 3s 多一点,背后的运算量是完全不一样的。),因为机票报价本身就是很复杂的系统,为了能够搜到最便宜的机票,宁愿卡顿一点。

正是因为产品原则是从实践中来的,所以每一个公司的产品原则差异都非常大,都是完全取决于自己的业务场景的,To C 和 To B,大体量的国民级应用与小体量的垂直应用,交易类产品还是内容类产品,这些因素都会显著影响到产品原则的设计。

从我自己的观察来看,产品原则的不仅仅可以起到解决产品需求不同价值取向的平衡问题,在很大程度上也是一个保险阀,可以一定程度避免产品的体验滑向一个无可挽救的深渊。

举例来说,市面上公开自己产品原则的公司不多,有赞就是一个,有赞的产品原则中有一条内容是:「不可减少,每个用户都重要。新产品不能比老产品的功能少,不应该轻易下线产品功能,不降低服务。不让少数服从多数,每个用户的需求和习惯都是重要的。」

如果是做 C 端的产品经理可能会觉得砍功能难道不是天经地义的吗?但是实际上大部分 SaaS 从业者都明白对 SaaS 来说,砍功能,尤其是砍付费客户会用的功能就是生死线,说严肃点这叫违反合同。有赞的产品原则恰恰是为了避免自己的产研人员犯下这种低级错误而设立的,同时它的存在也是一个约束,警示每一个产研上线功能之前要深思熟虑,做更加严肃的 PMF,毕竟开弓没有回头箭。

以我自己浅薄的认识来看,产品原则是一种能够平衡「又不是不能用」和「长期投入维护价值」这两种取向的方法。一方面如果原则生产的过程是科学的,就能保证按照原则进行决策本身带有一定科学性,因为一些业务认知在一定周期内是可传递的,没必要每次做实验,另一方面有降低了内耗和度量的成本,不至于为了确保科学决策把流程搞得很重。

同时产品原则还会有一个潜在的好处,就是减少「债务」的产生。当我们需要重构时,究其根本原因大概率是以前为了快速迭代业务做了很多糙猛快的决策,但是大部分产品原则在设定的时候天然就会更倾向于长期而非短期价值,所以一些原则的设定可以避免债务快速堆积,进而避免我们总是陷入不重构就迭代不下去,不得不面临削减业务投入来重构的窘境。

但是任何方法其实都还是需要实践的,如果原则的产生过程本身是随意地,不科学的,原则制定之后没有定时 Review(这个很重要,因为原则背后的业务认知随着时间推移其价值会递减),没有根据原则去安排产品决策和优先级排布,那么即使有 100 条原则也是没有用的。

喜欢此内容的人还喜欢

 

精选评论