让我们的产品更成功

　　文马博
　　作者首先分析了影响产品成败的因素，然后对症下药，从战略、规划、战术三个层面，诠释了做一款成功产品的秘诀。
　　谈到“成功”和“失败”，我想每个企业管理者和产品的具体参与者都存有“避之不及”与“翘首期望”的双重心态。被冠以“成功”还好，可以上下振奋、内外俱荣。一旦被冠以“失败”，便推搡躲闪、情何以堪。其实定义所谓的“成败”很容易，销量、口碑、利润率、市场占有率、顾客满意度、业界认同、第三方评价等，都可以加冕“成功”的称号，或被冠以“失败”的恶名。但这样简单、宏观或者浅层面的比较我觉得并不客观，也不一定绝对，而且会对企业和产品的具体参与者造成多重的负面影响，对企业和产品的发展都没有太大的益处。所以我个人认为无论是企业、产品的参与者还是其他第三方，都需要理性地对待这个话题。把表象抽丝剥茧、挖掘和分析其核心的因素才是真正值得我们所有人去思考、评价和借鉴的。
　　影响产品成败的因素
　　涉及产品的“成功”与“失败”，其根本是产品。产品在每个人的眼中是不一样的东西，比如在企业眼中是传播企业愿景和实现价值交换的载体，在产品经理眼中是把企业愿景转化成可市场价值交换的过程，在开发人员眼中是技术构想的实现成果，在用户或客户眼中是满足需要的工具。如果从各自的角度出发看待产品的“成败”，至少会出现很多个不同的组合结果。这样看来，我们就无法从单一角度或者某个独特因素去分析和评价。而其中有很多隐藏的可挖掘的可能性，比如企业战略、产品战略、产品定位、市场策略、人才、渠道、定价、外观、技术等，都有可能是影响个体判断产品成败的因素。每个个体有自己的成败定论，但我认为还是不要简单地看待这个问题，不然失去全面性和客观性的分析和借鉴是基本没有价值的。
　　我接触过很多企业就是因为没有全面、客观地考虑产品成败的因素，所以败笔产品比比皆是：把可换取利润的产品变成了企业自己的消费品，而且由于思维模式和管理模式的局限性，产品一旦出现问题，很难客观、准确地找到症结所在。这时只能用传统的方式去回溯，简单地用“谁出错谁担责”的方式去加强产品过程中的工作质量。然而这些其实不能根本避免产品出错或者失败的出现，而且还往往因为部门和个人利益等原因，导致互相推卸责任的情况频繁发生。这对企业来说是最不利的，不但从根本上没有解决具体产品上市成功的概率，而且对产品后续的发展也会有深远的不利影响。
　　我们总会感叹为何国外优秀企业的产品成功率会很高，能达到64，而国内企业的产品成功率平均只有5。我不太清楚每个企业是否会统计自己的产品成功率，或者是否对自己产品的成功率满意。但当这个数据摆在我们面前时，我想企业管理者和产品的具体参与者都应该认真反思。因为5和64之间有太多的提升空间和利润空间，也有太多的思考空间。
　　导致产品“成败”的原因还有很多，比如对产品的定义偏差造成的问题。IT企业最常见的一种现象，就是对“产品”本身的定义出现认识错位。比如有些公司把某个功能模块或者应用定义为产品，甚至把某个系统的后台也定义为产品。这样就出现了由于对产品本身定义的狭窄或者偏差导致后续所有围绕产品相关的、系统性的工作和信息没有兼容性和关联性。试想这样的所谓“产品”怎能到市场上完成价值交换，又如何能够保证产品上市后的成功？5的产品成功率给了我们很肯定的答案。
　　产品经理：让产品更成功
　　那么作为企业或者具体产品的参与者该如何思考这些问题、如何提高产品成功率、如何让自己的产品能够成功呢？我就以“产品经理”的视角来做简单阐述。
　　既然用产品经理的视角来阐述，那就不得不先提提产品经理的根本工作产品管理。产品管理到底是什么？很多企业和具体管理者都有不同的理解，这是由于企业对产品管理的认识和管理者职业化水平有限造成的。当然也与国内产品管理领域的初级阶段有很大关系。这里我推荐UCPM（中国产品经理联盟）的一篇文章《让产品管理裸奔》，让大家能够更清晰地认识到产品管理的本质。只有理解和认识到产品管理的本质，才能从最科学、客观、准确的角度出发看待产品，才能知道如何把产品做成功。
　　这里需要明确一个概念。产品是什么？说到底，产品是承载企业愿景、实现价值交换的一个包含“品牌、服务、介质”的载体，是指具有同一标识的介质、服务、品牌的企业资源集合。
　　下面我们从一个真正的、标准的“产品经理”的视角来简单阐述如何做一个成功的产品。
　　首先要认识到最终体现在市场的产品，在企业内部其实是“愿景战略规划计划交换”这样一个逻辑和流程的最终载体。基于这个思路，站在产品经理的角度需要考虑三个层面的工作：战略层面（产品管理中的战略，非企业战略）、规划层面、战术层面。这三个层面最终可以归结为：知道我们的目标是什么、知道我们该如何去做、知道我们如何能够做到。作为产品经理只要是做产品，就脱离不了这三个层面，而且必须按照这个逻辑和顺序，不然就成了主观臆断或者经验主义。如果顺序乱了，有可能会本末倒置、无序无章。对于企业来讲，如果理解或者理顺了这其中的关系和作用，就可以大大避免出现“失败”的产品。
　　在这个认识的前提下，我们会发现一个产品从无到有再到优这个过程中一定会涉及关于产品的三个层面的具体工作，而且每个层面都是影响下一阶段成败的关键性的活动和前提。
　　战略层面的工作
　　对于产品经理来说战略层面的工作尤为重要，这个阶段的工作成果决定了一个产品的目标和方向。试想一个产品如果没有目标和方向结果会怎样。有人会说：“我们的产品在初期也考虑了方向和目标，怎么还是做不好呢？”我来说明一下战略层面的工作内容，各位可以对照一下是否有做过或者是否做到位。
　　战略层面其实归结为三个方面的工作。
　　首先是预测问题。预测什么问题？就是我们在做产品之前一定要了解市场、用户和关于产品的一切需求，当然这里的需求是产品管理中的需求，而非研发需求。只有了解了这一切我们才能明确市场是否有需求，规模是否够量级，是否有明确的用户群，用户群在哪里，竞争对手在哪里，是否有相应的资源开拓这个市场等。这就是为什么我们要把预测问题放在首位它能够为后续的工作提供一个有力的市场依据。
　　其次是培育机会。我们面对一个市场时要推出一个什么样的产品才能有竞争力，才能可持续发展，才能产生高收益？这就要在培育机会的过程中做一系列的工作，包括评估自身的技术实力、分析竞争格局、明确自己的独特能力、分析管理需求等。只有这些工作都做到位了，才能客观、准确地知道我们想象中的市场是否真的存在机会，如果存在机会，我们是否真的可能把握住这种机会。
　　接下来就是产品创新。这里的产品创新并非技术层面的创新，而是基于产品（参照产品的定义）本身和相关资源集合的创新。什么意思？就是我们所关注的创新不仅要在产品“介质”上创新，而且要在影响产品交换过程中的每个环节和元素上创新，包括渠道、包装、价格、概念等。只有这样的创新思想才能保证自己的产品能够更准确、快捷地到达用户，被用户快速接受，这才是创新的目的。当然技术上的创新很重要，但我们要做的毕竟是一个基于商业的“产品”，而不是基于高精尖技术的艺术品，所以作为企业这个商业组织、作为每位创造产品的产品经理来说一定要认识到这一点。
　　当然有人可能会说iPhone就是技术创新成功的典范。我个人觉得这没什么可比性，从商业环境、企业积累、历史发展都有其独特的因素。而且我们很多人只关注到它技术层面的信息，忽略了渠道、概念、价格、包装、盈利模式等成就iPhone成功的众多因素。如果我们一味强调技术，就有可能走上一条偏离商业规则的非坦之途。当然我不是摒弃技术的纯市场忽悠主义者，我一直认为技术好像人的骨架，其他商业元素好像是人的血肉，骨骼粗壮才能血肉丰满，才能身体健康，缺一不可。
　　规划层面的工作
　　规划层面的工作是基于战略层面的工作来开展的，也是把产品战略层面的工作更具体化、形象化的一个关键性步骤。它决定了产品的原始形象和用户群体、决定了我们该如何达到在战略层面中所制订出的方向和目标。
　　首先是制订产品路线。产品路线的环节中要考虑很多因素，包括价格策略、产品收益和相应的产品所需的一切资源。
　　其次是产品策略。产品策略工作中需要考虑产品定位、业务流程、阶段性策略等因素。有人可能会问：“这些工作有的做了，有的没做，但都有什么作用呢？”举个例子，比如业务流程方面的工作。一个产品从出厂到用户手里会经过很多的环节，用户首先要知道这个产品，然后又要知道哪儿能买到，知道哪儿卖又要考虑是否选择这款产品等。你可以想象得到一个产品到达用户手中需要经过多少环节，在这些环节中又有多少因素会影响用户对产品的理解和购买。
　　如果不构建一个成本最低、效率最高、最现实合理的业务流程，那么我们的产品再好，用户也很难或者说会花费很高的成本去接受。所以构建业务流程的工作非常重要。当然其他工作皆如此，都会对产品的后续发展产生影响。因此我们必须认识到并重视起来，只有做好每一步的工作才能保证产品的成功。
　　最后是产品计划。产品计划包括营销计划、控制管理、产品路线等一系列工作，重要性同等重要，这里就不详述。
　　战术层面的工作
　　战术层面的工作是现在很多企业和产品经理最常见的。很多产品经理把大部分工作精力放在战术层面的工作中，但不知道在这个过程中都要做哪些具体工作，做到什么程度。他们和研发、UEUI纠结在一起，整天折腾技术、用户体验、界面美观等这些属于人家专业人士的工作，搞得自己挺忙，其他部门抱怨也挺多。打杂、救火、写文档，也就成为了工作常态。下面我说明一下产品经理如何在战术层面工作、做哪些工作。
　　首先是概念的实现。这项工作就是要把我们的产品用标准的指标定义出来，简单来说就是定义我们的产品应该是什么样子。
　　其次是图纸实现。这项工作就是完成产品的相应的规格定义，该阶段最容易出现与技术、UED部门纠缠的情况。这里强调一下，产品经理的规格定义不是具体到该用什么技术实现、用什么颜色表现这些具体的工作。很多产品经理容易混淆产品管理中的规格定义和技术等部门的技术规范，导致工作上的冲突。
　　接下来是技术实现。这个阶段就是按照之前的规格定义，通过其他部门把产品“介质”制造出来的过程。