这八个产品原则,决定了产品能走多远

不懂技术怎么做产品?15天在线学习,补齐产品经理必备技术知识,再也不被开发忽悠。了解一下>

优秀的团队,是产品成功的重要因素,但决定产品能走多远的,是产品原则。

从0到1打造一个新产品的过程,团队的重要性不言而喻,事实上对产品经理而言,团队决定其高度,是一种产品能够成功的重要因素,但并不足以让整个产品走的很远。

回顾整个平台型产品的全过程,高明的做法是:能在项目开始之前明确一些基本性的原则,一来可以避免在项目过程中随意发生不必要的争执,更为重要的是产品原则决定了产品的未来。

“产品原则,是产品发展的一个潜在标尺,指导着产品发展的方向,它代表着产品的定位与运营的逻辑。它不仅仅是UI或者交互层面的细节问题,更涉及到整个产品从市场定位、产品架构到运营策略等一系列问题。

比如:微信,到底要不要做“已读”标记,这个看起来是一个功能,其背后的逻辑就是到底是发信者视角还是读信者视角的问题。

产品原则,就像设定了一个评判尺度,有效的归置了在面临取舍时的判断标准。通常来说,产品原则可以从8个维度入手。

八项基本原则

一、MVP原则

指的是通过提供最小化可行产品获取用户反馈,并在这个最小化可行产品上持续快速迭代,直到产品到达一个相对稳定的阶段,MVP背后的核心原则就是减少时间成本。

这个原则,根本目的就是:要对需求进行快速的试错验证,而不是纠结某个点的UI和视觉问题(在产品的某些阶段,这些问题完全不值一提),其出发点就是避免团队耗费不必要的成本开发错误的产品功能。

但MVP常常让人误入歧途,只关注了它的小,而忽略其是否真正符合市场需求。

“你应该从你的点子、价值定位起步,找到真正的方向(true north)。当然,你需要迭代、机型优化、在市场里试验,但你不能迷失方向、失去自己的视野、丢了自己的故事”。

也就是新产品的开发过程必须要经过三个过程的递进:

  1. 用户问题和解决方案的匹配
  2. 产品和市场的匹配
  3. 规模性扩展

对照起来看,我们能发现很多产品没有走完前面两个阶段就开始规模性的扩展,常常是国内的还没搞明白就开始国际化,金融行业还没拿到手,就开始想着制造行业,产品还没有发布就想好了10个亿的市场订单。

然后,弄得鸡飞狗跳,最终也达不成既定目标。

二、简洁原则

“大道至简”,是一种基于人文的哲学之美,乔布斯说“一旦做到了简洁,你将无所不能。”

这种简洁,不是简单的减法,更不是直接减少功能,它是贯穿在产品、组织和企业战略之中的体系化。

具体表现在三个方面:

1. 专注

深刻的理解“好的产品不是解决所有问题的产品”,整个团队能够专注做某事,而不是什么都在做,什么都想做,什么需求都敢接,什么客户都要拿下。

乔布斯果断地砍掉了90%的业务线,只专注做几款产品,结果这几款产品非常成功。

2. 简单

通俗的说,就是把所有的内部逻辑复杂化,而把用户的操作体验做到极致的简单化。

这是很难的一件事情,确实需要“死磕”才可能做到,这会带来一个矛盾,过度的死磕细节会导致成本的上升,以及与市场的脱节,或者错失机会。

所以,简单是原则首先是基于MVP之上的,一定要让整个产品与市场相匹配,而不是盲目的简单化。

3. 不完美

新产品开发过程中,追求完美是大忌,它带来的后果就是成本的叠加和机会的错失。如果团队有一种“必须要等到“产品”拿得出手了,才好意思展示在公众面前”的想法,这个产品可能永远也无法达到“拿得出手”的地步。

比如:第一代iPhone连最基本的“复制粘贴”功能都没有,但丝毫没有影响它的成功。在产品开发过程中,一定要搞清楚那些是必备的功能,它起到决定性的作用,有的可能则属于锦上添花的功能,可以根据市场反馈来进行迭代。千万切记,不要把自己的产品困在办公室,否则它会永远都走不出去。

任何伟大的产品和事业都不是一上来就做的很好,而是通过不断试错,不断修正,不断迭代而逐步形成的。

所以,我们可以看到:“简洁原则”既是组织战略层的高度专注,也是产品维度的细节体验,更进一步也需要整个团队的沟通机制简单化。

这种“简单化”的沟通,取决于整个团队在创立之初所形成的文化。这就是我在整个复盘过程中,分开了两个篇幅讨论产品经理的角色与担当,以及如何打造团队能力的根本原因。

三、核心体验

按照习惯性的观念,任何人购买一件东西都应该是希望价格满意,功能多多,用途能力彪悍,也就是花最少的钱,办最好的事。

但真实的生活场景下,这个观念已经过时,用户的关注点早已从强调产品的的广度切换为深度——也就是更为有品质的生活。这就意味着我们首先应该在核心的点上做得足够好,再去想做更多的事情。

如果在一个点上还没深入的时候,就开启了另外一个方向,用户不仅无法完成核心任务,还回分散他们的注意力,结果就是团队很努力的做了很多事情,但用户并不那么买账。过多的功能(产品)会让用户迷失,也会让团队处于不必要的压力挑战之下。

有一个很奇怪的现象是:当一个产品的市场反馈不佳时,“产品经理们”似乎容易通过拉长功能和产品线来弥补用户和订单量的不足。我们需要警醒的是用户不喜欢我们的产品,多数情况下并不是因为产品的功能不够多。

一定要保持克制,只有在一项功能做的不错的前提下,你才能去延伸另外的功能,而且这个延伸不能影响用户使用核心功能。这一点可以参考下微信的做法。

砍掉那些残缺不全的功能,把团队的焦点拉回到如何解决用户的核心痛点上来,帮助用户聚焦他们想要达到的目的,找到能够完全满足优先级最高用户需求的解决方案。

四、数据导向

我们需要全员的数据意识,来降低错误的概率。

数据体现的过去,很多时候都会因为我们的过分解读和理解不够,而与事实发生偏移。我们需要数据,但不要去迷恋数据,有的时候不是数据越多越好。尽管通常情况下,数据的可靠性大于用户的反馈,更大于我们的经验和构想,但这不应该成为我们迷恋数据的借口。

这一点很难达成共识,除非你有足够的权威。

也许正是因为这些原因,现实中常常都是数据反而成为了产品开发中的坑。有些环节,数据被认为是某些机密,而被认为的隐藏或者修饰。

还有些情况是因为对数据的意识不足,所以被忽略,甚至是拿到了数据也不知道怎么用,或者只关注表面,或者觉得离自己很远。

最为可笑的是那种只知道拿自身感受来PK数据的做法,却常常深度干预产品的发展路径。

五、统一需求

这个原则简单来说,就是统一需求出入口,不要让需求满天飞,它包括需求的优先级处理和风险分析,也会带来产品质量和团队效率低下的问题。

这一点,同时也包括需求必须评审的基本要求,不要出现随意修改,随性发挥的情况,整个团队要有全员的质量意识,既要有自主性,也要有责任心。

在实际操作过程中,“统一需求的原则”是解决产品变更的利器。

基本的思路就是在一定时间几点上冻结需求,而不是没完没了的变更加塞需求。不要为了追求某些“成果”而强行改变计划,打乱整个团队的节奏,特别是从零开始的产品,这种变更往往得不偿失,市场和用户不见得会因为我们想象中的“功能”而忽然变成喜爱你的产品。

这个原则和MVP原则是一脉相承,目的是为了快速试错,找准方向,而不是似是而非闷头折腾。

六、系统效应

新产品开发过程中的“系统效应”问题,指的不仅仅是在产品设计和技术选型的系统性,还包括围绕产品上构想到售前、售中、售后的全链路的问题。

后者强调的是:开发管理和产品经营的问题,它对产品成败的影响力远远大于前者。

最典型的例子就是:产品开发与市场、销售的脱轨,各自为政,比如:软件开发到一半时突然发现某个特性硬件本身不支持,这种情况屡见不鲜。它的底层原因是某些部分没有被足够重视,或者把一个产品的开发过程视为某些部门的事情,而缺乏系统性的全局管理路径。

后面我还会重点讲到在开启一个新产品的开发过程中,如何才能规避这一现象。

七、风险意识

关于“风险”,我不知道应该用什么词汇更为贴近描述这个原则。很多人害怕风险,认为风险就是失去控制,这种思路的所有行为都是为了规避和控制风险。

还有一些情况则反过来,“风险”就是不确定性,也就意味着无限可能,凡是都是一种“到时再说”的心态——俗话叫“顾头不顾腚”。

当组织中的某个产品需要横跨多部门协作的时候,这种思维导致的后果会非常的严重,特别是硬件类等周期性长的产品,上游部门一旦只管自己这一节事情,就很容易给下游环节带来很多额外工作和不可控因素,最终导致产品的失败。

所以风险包括业务、技术、质量和团队等多个环节的“不确定性”。甚至有些产品,还会涉及到一些人文的,社会的风险,都需要及时找到应对和解决的方案。

不同的产品,不同的团队和管理风格,应对风险的方式都会各自有很大的差异,作为产品经理,首先要理解所在的组织风格,尽早识别风险,并提出预警,协助和推动风险应对方案的落实到位。

八、效率原则

当团队规模达到一定程度以后,带来的最显著问题就是效率的低下,比如:制定一些基本的会议规则,邮件的规范等都有助于提升团队的效率。

举个邮件管理的例子:当你的项目周期超过3个月,具有统一识别的邮件标题规范都能提高效率。

行为到此,在我看来确定一个产品开发管理的“基本规范”是一个产品能否成功的基础,

本文完

#专栏作家#

杜松,公众号:产品微言,人人都是产品经理专栏作家。专注于人工智能方向,擅长产品规划和架构设计。

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

题图来自Unsplash ,基于 CC0 协议。

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 我非常认同,但是实际操作起来,跟预期差太远多!

    回复
  2. 不错 ;-)

    回复