从0到1和从1到100：产品经理的应对之道

　　一个产品从0做到1，和从1做到100，哪个更难？对待这两个阶段，产品经理如何应对。
　　一个产品从0做到1，和从1做到100，哪个更难？
　　Paypal创始人之一，PThiel的《ZeroToOne》对从0到1的过程，包括如何找到需求，如何小范围试错，如何快速迭代等，已经进行了详细的阐述。
　　的确，“创建新产品”对产品经理而言，更激动人心。从需求的挖掘，痛点的分析，想法的提出，产品的定位，产品的架构等，直至经过繁复的可行性讨论，最终看到一个产品“长”出来，这个从无到有的过程，需要产品经理有过硬的基本功和良好的sense，同时也要有强大的游说能力，使团队形成统一的合力。
　　而从1到100的过程，听起来更像是“运营的职责”。很多产品经理会有这样的想法：框架都搭建好了，产品也做出来了，种子用户也有了，接下来不就是推广了吗？听起来在这个过程中，产品经理貌似难以施展和发挥，更多是配合运营的工作，或者是做些“缝缝补补”的边角工作。
　　然而，事实真的是这样吗？我曾经从0到1做过一个小产品，也曾经接手别人的产品，经历过从1到100的过程，我的体会是：从0到1的过程不见得很创新或者多独特，但是从1到100着实更难做，更费心，对产品经理的要求反而更高。
　　从0到1：解决需求大于创新
　　谈起从0到1，很多同行会认为这个过程强调“创新”，要有与众不同的点子，甚至有不少误解，认为有独特的想法就可以赢得用户和市场。然而，在公司里，尤其是大公司，一个产品的出现，最根本的是要解决在业务中遇到的实际问题。以广告平台为例，最基本的功能是广告主可以投放广告，查看效果，随着业务的发展，自然需要精细化的工具，这时候，优化工具出现了，各种“眼花缭乱”的报表系统出现了，等等。每个平台所处的发展阶段不同，比如百度凤巢或者阿里妈妈，产品体系已经很成熟，在这种情况下，想要从0到1做一个新产品难度就比较大，关键是业务并不需要。
　　比起创新更重要的是，如何用产品去解决业务的难点痛点？你的用户在哪个阶段，需要什么产品，产品经理必须基于业务考虑需求，而不能因为“别人有，我们也要有”，“我们可以提供不同的功能来吸引用户”，这种判断明显偏离了业务本身。
　　第一，“别人有，我们也要有”，问题是：我们的用户需要吗？现阶段我们的用户最期待的功能是什么？
　　第二，“提供不同的功能来吸引用户”，事实上，在同质产品中，很少有用户是因为某些炫酷的功能而选择某个产品的。关键是：这个功能是要解决什么问题。
　　从1到100：产品进化与迭代
　　一个产品从0到1建立起来之后，并不意味着这个产品的主要功能就完成了，事实上，产品的进化和迭代才刚刚开始，这个过程比0到1要漫长也难多了。
　　为什么这么说呢？
　　第一，你的用户会变，而且要得更多。虽然在初期，一款产品的受众就已经确定了，但是随着产品的发展，用户会越来越“刁钻”，第一个版本只需要基本的功能就够了，如果有流程的交互那是更好。第二版可能就需要高级的功能了，到了后续的版本中，由于用户基础变大了，产品经理会听到各种各样的用户反馈，如何取舍？
　　第二，产品支持的业务会变。之前我们谈到，产品不能偏离业务。在一款产品的生命周期内，业务的变化是不可避免的，包括KPI的转变，业务重点的迁移，还有业务的调整，都会影响产品的设计。比如，某电商APP，原来的KPI是拉新，今年变成了留存。诉求变了，产品也要调整。因为之前的框架和内容都是基于原有的策略的，这种情况下，受众是一样的，但是你要用户关注的重点不一样了，那么，产品经理应该如何应对策略和思路的变化，平稳过度呢？
　　第三，老板的思路也会变。不管在大公司还是小公司，结构是扁平还是官僚，在做产品的过程中，都要协调好老板与自身的思路，尤其是当两者思路有冲突的时候。在这种情况下，产品经理又应该如何协调不同的方案呢？
　　产品经理的应对之道
　　前面提出了三个问题，在从1到100的过程中，面对用户反馈如何取舍？面对业务变化，如何过渡？面对思路冲突，如何协调？以我个人的经历为基础，我认为产品经理的应对之道有这些：
　　第一，对用户反馈要去伪存真。
　　很多产品经理会有这样的体会，用户反馈是个坑。你不重视，会被认为“不注重用户体验”，你重视它，又觉得用户的意见有点“无理取闹”。
　　我的观点是：不要过分强调用户的反馈，更重要的是，要学会去伪存真的方法：哪些是伪需求，哪些是真BUG。
　　那么，如何去伪存真呢？
　　在实际操作中，先将用户的反馈归类，功能上的，交互上的，架构上的，等等，按照类别分开，不同的类别处理方法不同。比如，交互上的反馈，往往比较主观，最重要的是不要有跳转死循环就好。如果仍有问题，将反复出现的问题整理，与交互设计师沟通解决。如果是功能或者是架构上的问题，首先不要轻易怀疑自己对功能和架构的理解（尤其是前期经过各种论证的点），其次一定要用数据验证。自己去后台找相关功能的用户数据，或者灰度的时候小流量实验，要量化分析！前提是，一定要记得正确埋点，不要有遗漏。
　　第二，对业务变化先拆解后合并。
　　不少人认为业务的变化特别抽象，尤其是战略的目标，看起来今年和去年完全不一样。我的观点是：对于一个持续发展的公司，战略目标一般情况下是有延续的，有同类项的。如果战略变来变去，那一定是作死的节奏。
　　业务诉求的变化是一定的。通常情况下，我的应对策略是：先拆解后合并。
　　拆解，首先要熟知KPI是怎么来的，要把KPI拆成几个关联的指标。比如，销售额UV成交转化率客单价，如果要拉新，那就主要是针对UV（uniquevisitor，访问人数）了。如果是存留，那要看成交转化（用户停留时间越长，理论上越容易产生购买行为），当然还要结合时间序列的分析。
　　合并，合并不同的KPI中的同类指标。还是以拉新和留存为例，如果重点从拉新转向了留存，并不意味着原来的架构就完全不适用，比如，留存也需要有用户基数，没有拉新，留存也意义不大。按照这个思路，产品经理可以找到哪些为原来的目标设计的功能可用，哪些需要变化或者加强。
　　第三，对不同方案拉长时间线思考。
　　为什么要拉长时间线思考？其实这算是一种缓兵之计，重点是要和你的上级包括团队对长期目标达成一致。
　　实际经验表明，这一招对于大多数短期的冲突来说尤其奏效。很多看起来不可调和的矛盾，放到长的时间里面，其实只是不同的走向，争论的原点在长期的目标上。很多情况下，产品经理会陷入要么A要么B的选择题，但是如果能结合长期的产品规划，也许会发现，其实当下最好的策略并不是A或者是B，而且这两种方案还有调和的空间。
　　具体的例子我这里不赘述了。如果下次遇到类似的冲突，我建议产品经理可以先试着和团队或者领导分享你对产品的长期规划，在整体目标一致的情况下，重新看待当下的方案。当然，在这个过程中，你也许会惊奇的发现，你和领导或者团队对于长期的目标是不一样的，这才是短期冲突不断的根源。
　　最后总结下，在从1到100的过程中，一定要做长期的产品版本规划，随时关注用户的反馈，并且根据业务自身来调整产品的设计。不仅如此，在这个过程中，产品也要合理解决与运营之间的分工问题，产品经理在从1到100的这一段同样是主导，而且需要更灵活的适应变化。