新产品开发必须要遵守的基本原则

编辑      删除

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

关注产品微言,下载完整PPT


文  |   杜松,公众号  |   产品微言

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


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


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


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


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


八项基本原则


1、MVP原则

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


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


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




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


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


1、用户问题和解决方案的匹配

2、产品和市场的匹配

3、规模性扩展


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


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


2、简洁原则


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

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


专注。


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


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


简单


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


这是很难的一件事情,确实需要“死磕”才可能做到,这会带来一个矛盾,过度的死磕细节会导致成本的上升,以及与市场的脱节,或者错失机会。所以,简单是原则首先是基于MVP之上的,一定要让整个产品与市场相匹配,而不是盲目的简单化。


不完美


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


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


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




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


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


3、核心体验


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


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


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


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


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


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


4、数据导向


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


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


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




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


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


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


5、统一需求


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


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


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


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


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


6、系统效应


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


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


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


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


7、风险意识


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


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


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




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


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


8、效率原则


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


举个邮件管理的例子。


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


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


<本文完>

———— /  END  / ————

关注本公众号,回复“从0到1”,即可下载完整  PPT   

我将通过17篇文章,解密推动产品落地的全过程,包括产品的定义和设计、开发过程的管理,以及由此引发的系列问题,更包括在此过程中我所学到的宝贵经验和深刻教训。


欢迎交流,下辑预告:

“仪式感”,是产品能否成功的重要因素


杜松
产品经理 · X公司