掌握一个产品的五要素（这八个产品原则）
掌握一个产品的五要素（这八个产品原则）这个原则，根本目的就是：要对需求进行快速的试错验证，而不是纠结某个点的UI和视觉问题（在产品的某些阶段，这些问题完全不值一提），其出发点就是避免团队耗费不必要的成本开发错误的产品功能。指的是通过提供最小化可行产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到产品到达一个相对稳定的阶段，MVP背后的核心原则就是减少时间成本。比如：微信，到底要不要做“已读”标记，这个看起来是一个功能，其背后的逻辑就是到底是发信者视角还是读信者视角的问题。产品原则，就像设定了一个评判尺度，有效的归置了在面临取舍时的判断标准。通常来说，产品原则可以从8个维度入手。八项基本原则
优秀的团队，是产品成功的重要因素，但决定产品能走多远的，是产品原则。
从0到1打造一个新产品的过程，团队的重要性不言而喻，事实上对产品经理而言，团队决定其高度，是一种产品能够成功的重要因素，但并不足以让整个产品走的很远。
回顾整个平台型产品的全过程，高明的做法是：能在项目开始之前明确一些基本性的原则，一来可以避免在项目过程中随意发生不必要的争执，更为重要的是产品原则决定了产品的未来。
“产品原则，是产品发展的一个潜在标尺，指导着产品发展的方向，它代表着产品的定位与运营的逻辑。它不仅仅是UI或者交互层面的细节问题，更涉及到整个产品从市场定位、产品架构到运营策略等一系列问题。
比如：微信，到底要不要做“已读”标记，这个看起来是一个功能，其背后的逻辑就是到底是发信者视角还是读信者视角的问题。
产品原则，就像设定了一个评判尺度，有效的归置了在面临取舍时的判断标准。通常来说，产品原则可以从8个维度入手。
八项基本原则
一、MVP原则
指的是通过提供最小化可行产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到产品到达一个相对稳定的阶段，MVP背后的核心原则就是减少时间成本。
这个原则，根本目的就是：要对需求进行快速的试错验证，而不是纠结某个点的UI和视觉问题（在产品的某些阶段，这些问题完全不值一提），其出发点就是避免团队耗费不必要的成本开发错误的产品功能。
但MVP常常让人误入歧途，只关注了它的小，而忽略其是否真正符合市场需求。
“你应该从你的点子、价值定位起步，找到真正的方向（true north）。当然，你需要迭代、机型优化、在市场里试验，但你不能迷失方向、失去自己的视野、丢了自己的故事”。
也就是新产品的开发过程必须要经过三个过程的递进：
- 用户问题和解决方案的匹配
- 产品和市场的匹配
- 规模性扩展
对照起来看，我们能发现很多产品没有走完前面两个阶段就开始规模性的扩展，常常是国内的还没搞明白就开始国际化，金融行业还没拿到手，就开始想着制造行业，产品还没有发布就想好了10个亿的市场订单。
然后，弄得鸡飞狗跳，最终也达不成既定目标。
二、简洁原则
“大道至简”，是一种基于人文的哲学之美，乔布斯说“一旦做到了简洁，你将无所不能。”
这种简洁，不是简单的减法，更不是直接减少功能，它是贯穿在产品、组织和企业战略之中的体系化。
具体表现在三个方面：
1. 专注
深刻的理解“好的产品不是解决所有问题的产品”，整个团队能够专注做某事，而不是什么都在做，什么都想做，什么需求都敢接，什么客户都要拿下。
乔布斯果断地砍掉了90%的业务线，只专注做几款产品，结果这几款产品非常成功。
2. 简单
通俗的说，就是把所有的内部逻辑复杂化，而把用户的操作体验做到极致的简单化。
这是很难的一件事情，确实需要“死磕”才可能做到，这会带来一个矛盾，过度的死磕细节会导致成本的上升，以及与市场的脱节，或者错失机会。
所以，简单是原则首先是基于MVP之上的，一定要让整个产品与市场相匹配，而不是盲目的简单化。
3. 不完美
新产品开发过程中，追求完美是大忌，它带来的后果就是成本的叠加和机会的错失。如果团队有一种“必须要等到“产品”拿得出手了，才好意思展示在公众面前”的想法，这个产品可能永远也无法达到“拿得出手”的地步。
比如：第一代iPhone连最基本的“复制粘贴”功能都没有，但丝毫没有影响它的成功。在产品开发过程中，一定要搞清楚那些是必备的功能，它起到决定性的作用，有的可能则属于锦上添花的功能，可以根据市场反馈来进行迭代。千万切记，不要把自己的产品困在办公室，否则它会永远都走不出去。
任何伟大的产品和事业都不是一上来就做的很好，而是通过不断试错，不断修正，不断迭代而逐步形成的。
所以，我们可以看到：“简洁原则”既是组织战略层的高度专注，也是产品维度的细节体验，更进一步也需要整个团队的沟通机制简单化。
这种“简单化”的沟通，取决于整个团队在创立之初所形成的文化。这就是我在整个复盘过程中，分开了两个篇幅讨论产品经理的角色与担当，以及如何打造团队能力的根本原因。
三、核心体验
按照习惯性的观念，任何人购买一件东西都应该是希望价格满意，功能多多，用途能力彪悍，也就是花最少的钱，办最好的事。
但真实的生活场景下，这个观念已经过时，用户的关注点早已从强调产品的的广度切换为深度——也就是更为有品质的生活。这就意味着我们首先应该在核心的点上做得足够好，再去想做更多的事情。
如果在一个点上还没深入的时候，就开启了另外一个方向，用户不仅无法完成核心任务，还回分散他们的注意力，结果就是团队很努力的做了很多事情，但用户并不那么买账。过多的功能（产品）会让用户迷失，也会让团队处于不必要的压力挑战之下。
有一个很奇怪的现象是：当一个产品的市场反馈不佳时，“产品经理们”似乎容易通过拉长功能和产品线来弥补用户和订单量的不足。我们需要警醒的是用户不喜欢我们的产品，多数情况下并不是因为产品的功能不够多。
一定要保持克制，只有在一项功能做的不错的前提下，你才能去延伸另外的功能，而且这个延伸不能影响用户使用核心功能。这一点可以参考下微信的做法。
砍掉那些残缺不全的功能，把团队的焦点拉回到如何解决用户的核心痛点上来，帮助用户聚焦他们想要达到的目的，找到能够完全满足优先级最高用户需求的解决方案。
四、数据导向
我们需要全员的数据意识，来降低错误的概率。
数据体现的过去，很多时候都会因为我们的过分解读和理解不够，而与事实发生偏移。我们需要数据，但不要去迷恋数据，有的时候不是数据越多越好。尽管通常情况下，数据的可靠性大于用户的反馈，更大于我们的经验和构想，但这不应该成为我们迷恋数据的借口。
这一点很难达成共识，除非你有足够的权威。
也许正是因为这些原因，现实中常常都是数据反而成为了产品开发中的坑。有些环节，数据被认为是某些机密，而被认为的隐藏或者修饰。
还有些情况是因为对数据的意识不足，所以被忽略，甚至是拿到了数据也不知道怎么用，或者只关注表面，或者觉得离自己很远。
最为可笑的是那种只知道拿自身感受来PK数据的做法，却常常深度干预产品的发展路径。
五、统一需求
这个原则简单来说，就是统一需求出入口，不要让需求满天飞，它包括需求的优先级处理和风险分析，也会带来产品质量和团队效率低下的问题。
这一点，同时也包括需求必须评审的基本要求，不要出现随意修改，随性发挥的情况，整个团队要有全员的质量意识，既要有自主性，也要有责任心。
在实际操作过程中，“统一需求的原则”是解决产品变更的利器。
基本的思路就是在一定时间几点上冻结需求，而不是没完没了的变更加塞需求。不要为了追求某些“成果”而强行改变计划，打乱整个团队的节奏，特别是从零开始的产品，这种变更往往得不偿失，市场和用户不见得会因为我们想象中的“功能”而忽然变成喜爱你的产品。
这个原则和MVP原则是一脉相承，目的是为了快速试错，找准方向，而不是似是而非闷头折腾。
六、系统效应
新产品开发过程中的“系统效应”问题，指的不仅仅是在产品设计和技术选型的系统性，还包括围绕产品上构想到售前、售中、售后的全链路的问题。
后者强调的是：开发管理和产品经营的问题，它对产品成败的影响力远远大于前者。
最典型的例子就是：产品开发与市场、销售的脱轨，各自为政，比如：软件开发到一半时突然发现某个特性硬件本身不支持，这种情况屡见不鲜。它的底层原因是某些部分没有被足够重视，或者把一个产品的开发过程视为某些部门的事情，而缺乏系统性的全局管理路径。
后面我还会重点讲到在开启一个新产品的开发过程中，如何才能规避这一现象。
七、风险意识
关于“风险”，我不知道应该用什么词汇更为贴近描述这个原则。很多人害怕风险，认为风险就是失去控制，这种思路的所有行为都是为了规避和控制风险。
还有一些情况则反过来，“风险”就是不确定性，也就意味着无限可能，凡是都是一种“到时再说”的心态——俗话叫“顾头不顾腚”。
当组织中的某个产品需要横跨多部门协作的时候，这种思维导致的后果会非常的严重，特别是硬件类等周期性长的产品，上游部门一旦只管自己这一节事情，就很容易给下游环节带来很多额外工作和不可控因素，最终导致产品的失败。
所以风险包括业务、技术、质量和团队等多个环节的“不确定性”。甚至有些产品，还会涉及到一些人文的，社会的风险，都需要及时找到应对和解决的方案。
不同的产品，不同的团队和管理风格，应对风险的方式都会各自有很大的差异，作为产品经理，首先要理解所在的组织风格，尽早识别风险，并提出预警，协助和推动风险应对方案的落实到位。
八、效率原则
当团队规模达到一定程度以后，带来的最显著问题就是效率的低下，比如：制定一些基本的会议规则，邮件的规范等都有助于提升团队的效率。
举个邮件管理的例子：当你的项目周期超过3个月，具有统一识别的邮件标题规范都能提高效率。
行为到此，在我看来确定一个产品开发管理的“基本规范”是一个产品能否成功的基础，
本文完
#专栏作家#
杜松，公众号：产品微言，人人都是产品经理专栏作家。专注于人工智能方向，擅长产品规划和架构设计。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash ，基于 CC0 协议。
