Reddit产品副总裁：如何打造一个持久高效的产品开发系统？
Alex Le和Kavin Stewart目前是Reiddt的联席产品副总裁。他们俩其实在8年前就认识了，当时分别是两家有竞争关系的社交游戏公司的创始人，不过他们并没有剑拔弩张、针锋相对，而是为了能共同生存而相互取经。Alex擅长设计，Kavin则擅长增加产品营收和用户增长。后来他们分别加入了其它公司负责产品方面的工作，但始终保持着联系。最终，他们都加入了Reddit，并共同担任公司的联席产品副总裁。
第一次听说联席产品副总裁，你可能会觉得这样的职位设置并不是一个好主意，因为这样的职位设置在合作的过程中可能会遇到很多问题，但对Alex和Kavin来说这并不是问题。为什么这么说呢？因为他们在公司的各个发展阶段都有打造产品的丰富经验，他们亲自见证过很多成功、也遭遇过很多失败；他们知道产品线何时该扩张、何时需要做出改变、打破重来，他们也见识过太多足以毁掉一款产品的致命错误。
近日，他俩接受了First Round Review的独家专访，主要分享了创业公司如何顺利地从产品市场匹配阶段过渡到增长阶段，很多非常有前景的创业公司都在这上面栽了跟头。他们分享了很多建议策略，不管你现在的公司处于哪一个发展阶段，你都能借鉴他们的方法来学会如何打造一个高效、可复制且持久的产品开发系统。
跨越鸿沟
有一种东西叫创业公司青春期，这个青春期阶段就是产品开始变得越来越受欢迎的阶段。正如青春期一样，这种转变常常会让人猝不及防。当然，他们之前可能预料过这个阶段会到来，但这并不意味着他们已经为此做好了准备。
对于产品而言，主要有以下两个方面的改变：
你已经不再是你自己产品的用户了：硅谷的创业者有这样一个共同点，他们刚开始创业的时候想要解决的是自己遇到的实际问题。在创业最早期，你开发的产品的目标用户是与你自己类似的人或是你非常熟悉的人群。一旦到了产品市场匹配阶段之后，便会有很多新用户成为你的目标用户，这时你自己的需求已经无法代表你所有的用户的需求和想法了。
你将有机会去展开更多的测试：在你有了足够多的用户或客户后，你将能够根据用户行为来调整和优化产品。
随着用户的新需求越来越多，你开始需要招聘越来越多的人，公司运营也会变得越来越复杂。为了获得后续成功，你需要对你的产品和工程师团队进行模块化设计，这样一来，你就能对要解决的问题进行分类，然后将不同的问题分配给相应模块的团队独立快速解决。随着公司日益壮大，所有团队都能实现自主领导、并肩冲刺。如果你能够早点将这种模块化团队机制嵌入到企业文化中，公司后期的快速扩张就会变得更加容易。
你必须要非常清楚地知道公司目前处于哪一个发展阶段，这样才能在相应的阶段采用合适的流程。理想情况下，打造一个在公司发展过程中可以进行优化的流程，而不是每达到一个新阶段都要将流程彻底打破、重新构造。
虽然Reddit是一家非常成熟的公司了，但和创业公司一样，它也会遇到同样的过渡转折问题。举个例子：Reddit最近正在开发移动App，关于App的功能和设计方面的想法全来自于团队成员，毕竟他们是Reddit最为忠实的用户。
我们也知道，随着获取的用户越来越多，肯定会遇到很多刚刚接触Reddit或是与我们的想法观点不一样的用户。有一个道理我们始终铭记：那些让我们成功到达此地的东西是无法帮我们实现下一个成功的。
为了弄清楚App究竟需要上哪些功能，我们确实需要好好做功课，这和早期创业公司所经历的那种绞尽脑汁的痛苦一样。“我们不能仅仅将用户反馈的需求和问题直接转给产品和技术人员，让他们去解决。相反，我们需要我们的团队不仅开发那些扔给他们的需求功能，同时也要主动探究那些我们没有获得的问题反馈，并想清楚哪些功能可以解决这些问题。”
他们在这个过程中采用的流程管理方法叫做“假设驱动型产品管理方法”。根据这套管理方法，产品经理已经不能停留在“我认为用户想要这个功能”上了。相反，产品经理需要这样问自己：“你预测这项功能将会产生什么影响？”
在A轮融资之前，你往往没有足够的数据让你这么做。在种子轮融资阶段，你的公司本身就是你的一个假设。你将公司展示给全世界，只是为了想看看你关于公司的假设是否成立。随着公司的发展，你会做出更多假设，那就是公司该往哪个方向走。确定了发展方向后，你会继续假设该为产品添加哪些功能。这种不断做出科学假设的能力将会让你的产品被越来越多的用户所接受和喜爱。
在Alex和Kavin看来，随着公司的发展，在产品开发方面将发生三个重大变化：如何产生想法？如何执行这些想法，将想法变成现实？如何对想法进行迭代？他们在下面分享了创业公司在这三个方面实现飞跃的最佳方式。
找到全新的头脑风暴方式
你需要构建一个进行假设的体系，即使公司日后发展壮大了，这个体系依然可以作为未来产生功能假设想法的基础。
将你希望达成的目标列成一个清单，例如你想要达成的指标、你想要看到的用户活跃度和用户增长数据。然后再根据数据和调研去猜测怎么做才能实现这些目标。
如果你的公司还处于非常早期的阶段，没有足够多的数据让你去做定量分析，那么你可以从在用户调研和测试中获得的定性反馈开始做起。不过你所构建的假设体系不能仅仅依赖你自己已有的观点与经验，你需要往这个体系中注入一些新东西，做竞品分析就是方式之一。你的竞争对手实现了你想实现的类似目标吗？他们是如何实现这个目标的？你怎样借鉴和迭代对方的做法，从而比对方做得更好？
除了竞品分析外，另外一个在假设体系中注入新想法的方式就是与那些你希望成为你目标用户的人群沟通，了解这些人目前使用的与你的产品类似的产品都有哪些、他们为什么使用这些产品、以及他们可能不会使用你的产品的原因。不管怎么说，你需要利用好手头的已有资源，从与用户交流中获得定性反馈要比什么都没有强得多。
产品管理主要有三个方面的内容：针对目标清单开展头脑风暴、为目标清单确定优先级、执行目标清单。其中，细节决定成败。
如果你头脑风暴出来的清单是有问题的，那么接下来的整个方向就会出问题。你想创新，这当然没问题，不过首先要确保创新的方向是正确的。
在产品方面的创新应该是一个非常机械的过程。在有些人看来，头脑风暴就好似坐在山顶上的时候突然被一道闪电击中时感觉，其实并非如此。在我看来，在头脑风暴的过程中，将“产生想法”和“评估想法”这两个阶段区分开来至关重要。我自己展开头脑风暴的时候是这样做的：首先将自己头脑中浮现出的任何一个想法都先记录下来，不管这些想法听起来有多愚蠢，然后再对这些想法进行逐一分析与评估。
利用你在用户测试和调研过程中获得的反馈以及从其它渠道获得的信息，对最初的想法清单进行过滤和精简，筛选出真正靠谱的好想法。利用下面这两个要素对清单里的想法进行优先级排序：
这个想法对达成目标有多重要？
这个想法的成功几率有多大？
只要回答了这两个问题，你就能知道清单上的哪些想法的优先级比较高，然后再去执行这些想法，这能让你更容易达成目标。在小团队里，这项工作可以集中统一开展。随着公司规模的壮大和产品功能组合越来越分散，这时可以由各个团队来各自独立运行这个系统，将想法推进到下一个阶段。
图中人物为Alex Le
让模块化执行达到最佳状态
头脑风暴结束后，通常都会产生多个新的想法。在小创业公司里，每个人都知道团队里的其他同事在负责什么工作，这是小创业公司的一个优势。在验证了产品市场相匹配之后，创业公司的这个优势就会逐渐丧失，这时你就需要花心思为不同的团队分配工作任务，让这些团队在没有人领导（尤其是没有创始人的领导）的情况下也能独立完成各项工作。
我亲眼见证过很多创业公司都走到了这个阶段，通常都是公司CEO或新招聘的产品主管负责为不同的员工团队分配任务，这并不是一个好方式，最好的方式是让员工都能负责各自最擅长的工作领域，并且有足够的自由去进行创新与测试。
下面是一些常见的工作领域：
核心产品：我们如何让产品变得更好？
注册体验：如何让更多的人注册使用我们的产品：
内部工具：如何优化公司内部使用的各项工具？
内容：我们应该向用户展示哪些内容？如何展示？
社区：如何建立起自己的用户社区？
渠道：在核心产品之外，我们通过哪些渠道与用户互动？如何互动？
盈利方式：如何获得盈利，确保公司能生存下去？
我曾经在一家创业公司担任顾问，公司CEO采取的方法依然是：将任务分配给不同的PM，PM再讲工作任务分配给研发人员。我对那位CEO说，应该让这些小团队进行自我驱动，让他们自己去发现问题和解决问题，只需跟你汇报结果就可以了，你不需要了解工作的所有细节。
我发现很多团队都按照技术领域来划分团队，如前端网页开发团队。我认为这并不是一个划分团队的好方法，我建议按照宏观产品而非单纯的技术来划分团队。例如，关注产品所有平台的内容建设，关注如何在各个平台上提高用户转化率。
从按技术划分团队转变到围绕目标来划分团队是非常困难的，因为之前形成的种种习惯是难以改变的。要完成这种转变，就需要从公司高层开始做起。CEO需要主动放弃一定的控制权，不能对什么工作都要亲自参与和决策，要学会放权。根据Kavin和Alex的亲身经历，一旦创始人或CEO做到了适当的放权，那么完成这种团队划分方式的转变就会容易得多。
如何确定什么时候需要进行这种转变呢？
CEO或联合创始人已经无法掌握公司的所有工作，对产品每天的进展也不了解。
你试图扩张自己的产品，这就需要你花更多的时间和精力去了解用户。
公司现有员工负责产品太多不同领域的工作，经常需要转换工作场景，导致工作效率严重下降。
一旦你意识到了这种需要之后，你可以利用下面的方式来实施转变：
为每一个主题领域的工作都任命一位商业负责人，负责驱动KPI和与高层的沟通。这样的负责人通常是产品经理。
尽可能减少跨团队依赖性。
制定运营目标，并将每个人的OKR都与这个目标绑定，让每一个人的工作都更有目的性，也能更好地评估大家的表现。
持续重新评估现有体系的瓶颈在哪里，并快速解决这个问题。
一旦你围绕主题组建团队时，你就会更清晰地了解谁负责产品的哪部分工作的。此外，你在定义主题的时候，你还需要任命一位负责人，这样的负责人通常是产品经理。在一些工程师驱动的公司里，这位负责人也可能是一位技术主管。负责人不需要管理团队的其他人，但需要负责做出最终的决策，同时要对工作成果负责。
在Reddit，Kavin和Alex分别负责产品不同领域的工作，一位负责内容和社区，一位负责增长和盈利。此外，他们各自还组建了不同的主题团队，每个团队都有自己专门负责的工作领域。
每个主题团队的负责人是需要做出最终决策的人，同时确保团队里的每个人的声音和意见都能得到重视。如果你是团队负责人，你需要让团队成员感受到他们的想法不仅被听到了，同时得到了足够的重视和理解。要想做到这样，最简单的方法就是重复他们说过的话：“你刚刚是说.......”，如果他们同意你的说法，那么你可以说：“很好，现在我可以在决策的时候考虑你的意见。” 通过这种方法，即使最后你没有采用他的意见，你也可以给出一个让对方满意的解释，从而避免让团队成员产生疑虑，这有利于团队和公司的长久发展。
随着产品团队日益壮大，你必须去教授和训练这种技能。你需要帮助团队中的每一个产品经理都培养出能充分考虑大家意见的能力。毕竟一个公司要想实现长久成功，团队的和睦至关重要。
要想让培养产品经理海纳百川、充分考虑所有人意见的能力，就需要让他们认识到，对于公司而言，任何一个单一决策对公司而言都不会产生致命的结果，同理，任何一个单一决策也都无法让公司取得重大成功。这就降低了决策失误的成本，减轻产品经理的决策压力，让他们能够充分考虑所有人的意见。
产品运维的巨大影响
如果你不和产品团队做好充分沟通，可能就会有很多个人只顾及各自负责的小功能和目标指标，而不会通盘思考整个产品。所以你需要一个“枢纽交警”，所有决策都需要经过他。他需要是一个能够跟踪同时开展的各个不同项目的人，了解不同项目间的相互影响。
你需要任命一个关注和重视产品宏观体验的人。这个人应该重视这两项工作：（1）搜集和沟通在实验中获取的数据；（2）引导每一个人都围绕公司宏观目标去开发产品功能和进行产品测试。如果你的公司有专门负责产品的副总裁，那么他可以扮演这个角色。如果没有，那么可以指定一个产品人员来负责这项工作，或暂时让CEO或联合创始人负责也行。
如果某项产品功能的测试结果好的，这也并非意味着这项功能适合推给所有用户。你需要采取额外的步骤对结果进行分析，真正了解是什么因素促使产生了这种积极的结果。在我之前就职的一家公司，我们常常会一天内开展5项测试，测试结果会相互冲突和影响，你很难真正搞清楚是什么导致了什么结果。
你的负责产品运维的“交警”需要充当这些测试结果的中央枢纽：集中获取和分享测试结果，让每一个人都知道这些测试信息。在Reddit，我们有正式和非正式的方法来分享这些信息。我们有产品经理午餐交流会，所有产品经理都在一起交流他们开展的有意思的测试以及测试结果。此外，我们还会召开战略会议，某一领域的负责人将会汇报自己过去一个月中的工作和详细的测试结果。
随着公司规模的壮大，你会发现很多人都会陷入越来越长的产品迭代周期中。这时必须要有人关注和解决这个问题。比如，搜集数据，看每一项新功能发布所需要的时间，了解推出类似功能在不同时间段所花时间的差异，每一个冲刺期或季度推出的功能数量。你必须了解完成这些工作所花时间的长短，这样一来，即使公司员工和项目越来越多，你都能保证产品迭代周期不会越来越长。
如果你了解Facebook的话，你就会发现它的产品迭代周期是非常短的，它并不是通过为一个项目配置更多人员做到这一点的。你需要有很多小的项目能同时保证产出，这就需要你在产品运维方面做好充分沟通。
为了能让产品运维走向正规，你可以做以下这些工作：
确定少数几个所有人都必须遵守的规则：对于我们来说，确保每一个人都在相同的进度上至关重要，所以我们对为数不多的例行会议非常严格。每两周，我们都会开始一个新的冲刺。其他事情都可以灵活一点，但在每两周一次的会议上，Reddit的所有产品团队都会在会上开始一个新的冲刺——可能同时启动7、8个项目。此外，每个团队自己也会制定自己的冲刺计划，他们只需展示给大家他们打算开展的工作就行。
提供一定的自主权：每个团队在例会上做出的正式承诺有助于缩短产品迭代周期。但在一个迭代周期内如何具体开展工作，这由各个团队自己确定，前提是他们能在每两周一次的会议上交出满意的冲刺答卷。
明确产品运维的角色定位。
现在就开始做。现在就开始启动产品运维方面的工作，而不要等到有了总体规划和确定的流程自后再去做。
如果你现在还是一家早期创业公司，团队里没有人适合产品运维这个角色，这时不妨选择一位高绩效、注重细节的产品经理担任这一角色。这个人必须是产品人员，这样他才能了解不同项目的合理开发速度是什么样的。
在产品开发中提供或采纳的建议都要符合公司的发展阶段，然而这却是很多人最容易忽视的。有人告诉你要数据驱动，你也努力想做到数据驱动，但在公司发展初期，你是无法做到数据驱动的。在一周只有300个访客的情况下，你是无法开展A/B测试的。
另外一个常犯的错误在于，认为过去那些成功的做法能保证公司未来持续获得成功。适用30个人的框架和流程是不适合200人的公司的。你必须机械化头脑风暴流程、划分责任、引进产品运维。只有这样你才能紧密地团队大家，激发大家将工作做到最好。
