人人都是产品经理02-08章摘要

8.1好产品步步为营

如果你到了对手公司做卧底，如何不 动声色地毁掉一个产品，请大家献计献策。

多开会多获取需求：使进度拖延。
增加大量新功能：让产品臃肿化。
项目推进制度化、流程化：制造各种无形的障碍，让团队成员投入精力去整理各类文档。
不切实际地赶进度：给开发人员超负荷的压力，让他们情绪化。
扩散干系范围：牵连多部门，制造各种利益冲突，让问题尾大不掉。
过度细化职责与分工：形成众多小团队，让他们相互扯皮、纠缠不休。
绝对民主作风：优柔寡断、不决策。

迭代”和“规划”，这两个词究竟是什么意思？表面看，说的都 是“一步步来”。但其实它们的区别，在《精益创业》中有一个特别贴 的对比：发射火箭（规划）和开车出门（迭代）。

打一个比方，迭代其实是瞄准、射击、再调整的过程。大家可以想一下，射击时怎样才能够尽快地打中靶心呢？一种做法是花很长时间瞄准，经过各种计算后打出一颗子弹。还有一种做法是，大概瞄一下就打一颗，根据这颗子弹的弹孔距离靶心的远近做出调整，调整完后再快速打出第二颗子弹，就这样不停地调整、发射、调整、再发射，其实更容易打到靶心。当然，这里有一个非常关键的前提，就是子弹不贵，而互联网正好就属于这种子弹不贵的行业。

8.2规划：只看最长和最短

业务规划可以包含MRD里的所有内容，但它更加强调“未来几步怎么走”，就像一名优秀的棋手，会多算几步，更通俗的说法是：吃着嘴里的，看着碗里的，想着锅里的。它和MRD相比还应该说清楚以下三点。
► 一句话的业务定位
►一个业务模型
►三五个业务关键点

先说说抢资源时如何提问。这种事儿通常发生在规划PK会上，因为大公司人多事多，所以选择不做什么比决定做什么更重要。
怎么在规划PK会上，通过提问题的方式把别人干翻。

1. 每次对方讲完PPT。 为什么要做这件事，不做的话会“死人”吗？
2. 看到对方从总体KPI分解出的目标。 这是用户的目标还是我们的目标，是不是老板的目标，老板换了怎么办？
3. 看到对方从用户需求出发，引用了一个观点。 这个用户有普遍性吗，能代表多少人，这类用户对我们的优先级是什么？
4. 看到对方引用一个数据来证明自己的观点。 数据来源是什么，什么时候获取的，是怎么采样的？
5. 看到对方的规划写得太实在，都是项目方案。 为什么没有看到这个产品线的大图，5年后这个产品是什么样子， 你实现整个图景的路径是什么？
6. 看到对方写得太虚，都是画大饼。 未来的确很美好，但怎么实现？现在如果只做一件事，最重要的是 什么？你打算怎么做？
7. 看到一个运营方案需要资金预算。 你能给出量化指标吗，ROI是多少，这笔钱真的能用在最看重的用户身上吗，会不会被不投钱就已经很活跃的用户花掉？
8. 看到要做的事情太多。 这么多事情，你打算组建多少人的团队，他们都需要什么能力，怎 么分工？如果只给你两个人，怎么办？
9. 看到要做的东西真的很吸引人。 实现路上会碰到的最大问题是什么，你打算怎么解决？需要大家怎 么配合你，你打算如何说服各个部门都来帮你？
10. 看到具体的项目。 你这些项目需要占用的开发资源有多少，如何给技术同学带来成长和成就感？

8.2.3提升规划能力的实践

►让产品团队每个人做一份自己产品的规划，规划周期可以限定为3个月。重点是每个月要拿出1天时间，每个人轮流宣讲，听众是团队其他人。
►每个人讲完以后，听众轮流说一点“好”与一点“可以更好”（其实就是“不好”的委婉说法），不许重复。可以针对规划本身，也可以针对 PPT制作、演讲技巧等。
►主讲人自己在白板上记录大家的发言，等所有人发言完毕后统一进行回复和讨论，会后优化产品规划PPT以供下次讨论。

还有一个小技巧：如果团队成员比较温和，不愿意互相批评，可以用评选最优评论员与最差评论员并适当奖惩的措施来加以刺激。

8.3迭代：再理解敏捷

再来复习一下敏捷宣言：
一、人与人的交互，重于过程和工具。
二、可用的软件，重于详细的文档。
三、与客户协作，重于合同谈判。
四、随时应对变化（不怕犯错），重于循规蹈矩。

8.4天下武功唯快不破

8.4.2 烧钱是为了抢时间

“烧钱”，似乎是互联网行业很有特色的一个发展策略。能理解快的重要性，就不难理解烧钱的目的——抢时间。对创业团队来说，抢时间尤其重要。
一位创业的朋友在分享运营策略时，谈到“单用户成本”的算法：计算一款产品的“单用户成本”时，要纳入整个公司的运营成本（含人员等成本），而不是只计算该产品的推广费用 。
举个例子。如果只算推广费用：
A方案：每个月花5万元带来1万个用户，单用户成本是5元。
B方案：每个月花20万元带来2万个用户，单用户成本是10元。
如果以这样计算出的单用户成本为考量依据，明显应该采取A方案，选择每个月花5万元来运营。

但如果考虑公司日常运营成本（包括人员、服务器、带宽等成本， 假设一个月为20万元）：
A方案：每个月25万元带来1万个用户，单用户成本25元。
B方案：每个月40万元带来2万个用户，单用户成本20元。
这次，对比后理所应当选择单用户成本低的B方案，而这个方案中投入的直接推广费用是20万元，远大于A方案的5万元。看来“烧钱”是有量化依据的。

当然，这个例子忽略了很多实际情况，比如用户的后续活跃留存等，但其计算方法的逻辑无疑是正确的。除了单用户成本有优势外，B 方案更加有利的是，比A方案提前一个月做到了2万用户，足足省了一倍时间！对于在和竞争对手赛跑或需要用漂亮数据拿到投资的互联网创业公司，这样的领先意义重大。
多年前我写过一个“攻山头的故事”，里面提到创业和某些大公司的区别： 从前有座山，山上没有庙……但是有好多好多的蘑菇、山药、木耳，让每个人都口水直流，于是，大家都想抢占这个山头，而且只有一天时间。
一支三五个人的游击队，饿得不行了，没时间探路，没时间研究， 唯一的机会就是抓紧时间，乘着夜黑风高随便找一条路冲向山头。也许 一场大雨引发泥石流，或者踩到一颗地雷，或者遇到一群狼，都会全军覆灭，但如果侥幸冲上去，就立马占山为王，山鸡变凤凰。
这支部队，是创业公司。
一支看上去人很多的部队，实际上是十支集合在一起的游击队。进攻之前，领头的发现依然是没时间探路，没时间研究，心想干脆不探路了，当年在游击队的时候拼的就是RP（人品）。于是召集所有兄弟开 了一个统一思想的会议，言明攻下这个山头的高尚动机与社会价值。然 后，十个队长带着兄弟们高喊着：“为了×××，冲啊！”从四面八方涌向山头，十支敢死队也许死了八九支，但只要有一两支冲上去，就胜利了。
这支部队，是阿里。
国内现在的创业环境，更像是综合了上面两个情况。
每个小土包，都有几十支饿得不行的游击队在往上冲，每个人都清楚地知道，他们绝大多数都会死，但从概率上讲，总有人会登顶。这时候，如果选择慢慢来、想清楚了再上，就算路径正确，也是死路一条。 因为等你爬了一半，就会发现山顶已经有人了，而——快，才有可能活下去。 听起来，像是有一种“别人孩子都去上补习班，于是我也只好给娃报名”的无奈，而事实上这是一个行业从新生到成熟的必经之路。

8.4.3省时间的低成本验证

单纯为了速度而横冲直撞，是不可取的，也是得不偿失的。那么， 如何合理而科学地加快速度呢？答案就是低成本验证。

低成本验证的理念，本质上和迭代的思路完全一致：在一个快速变化的环境下，不断地用最少的时间、成本去获取市场反馈，不断修正前进方向 。
下面举几个例子。
1.假设你要做一个交易系统。 正常的交易流程一般叫作“正向交易”，要满足买卖双方之间下单、 付款、发货、收货等常规需求，是交易系统必备的。但是，“退款/退货”这种“逆向交易”要不要做呢？做的话，系统复杂度会大幅增加，实 际工作量不只翻倍，往往会超出3～5倍。 怎么办？可以这样低成本验证：先在线上做一个假的“退款/退货”按 钮，用户点击以后，系统直接给客服人员发邮件，由客服人工完成处 理。这样运行几周后看看效果。如果客服只收到几封邮件，那么就继续 采用“人肉”处理；如果收到的邮件多到人工处理不过来，就可以理直气壮地上系统了。

2.除此之外，不轻易做系统还有一个现实意义：上线容易下线难。功能上线后，如果只有很少的人在用，就会陷入尴尬境地。如果下线，这些在用的人会跳起来说：“我用得好好的功能，你们为什么要下线。”而如果迫于这种压力，勉强继续维护着这一功能，一方面有成本，也很吃力；另一方面后续新功能也必须考虑和这个鸡肋功能的兼容、协作。

3.现在的很多创业项目，启动阶段先做微信公众号、H5页面，而 是App，一个主要的出发点也是低成本验证。这么做，开发人力的成本可以低一些，用户获取的成本可以低一些，功能调整的成本也可以低一 些。用一个简单的产品雏形把业务逻辑先跑通，然后再考虑是否要做客户端，是很值得推荐的产品策略。

4.最后来说一种有趣的低成本验证方法——利用公关手段。
经常看到阿里PR稿件中出现“阿里又要推出×××”“阿里开始进军 ×××”“阿里正在秘密研发×××”这样的标题，而这很多时候都是有意为之的小动作，甚至产品、技术团队都毫不知情，更谈不上真正开始投入资源了。而很多对手会被带到沟里，开始研究对策、排兵布阵。
大机构想推出新政策的时候，先借助合适之人如专家的嘴，或其他渠道如非官方媒体、小道消息等来透露给社会大众，试探他们的反应， 得到相应的结果后，或顺水推舟地证实，或矢口否认地辟谣。不用担心最终没做会辜负期待，用户总是很健忘。回顾一下以往的新闻，能想到很多这样的例子。
广义的公关之法，其本质就是先不做，却告诉受众我已经做了，从而收集反馈，其优势在于成本非常低，验证非常高效。

8.5与用户一起成长

事实上，产品往哪里走，并不是由产品经理决定的，而是由产品团队和用户共同决定的。产品与用户在几年时间内已经形成共生的关系， 产品影响着用户，用户也影响着产品。
试图决定产品走向的产品经理，实在有些自不量力。

下面，用豆瓣的成长故事来进一步说明产品发展的自主性。
豆瓣最早的产品是“读书”。对于一本书，如果想讨论内容，可以发书评，但是想讨论作者的八卦，怎么办？于是，豆瓣做了“小组”，把它当作“读书”的“垃圾桶”，有些奇怪的话题都可以去小组讨论。没想到， 小组火了。这时，作为一个读书网站的豆瓣，最大的小组居然是“爱看电影”。豆瓣顺水推舟，又做了“豆瓣电影”，而另一些小组催生出“豆瓣同城”。
这个故事告诉我们，产品和用户是一起成长的，只有把用户当作产品的一部分，形成一个大的生态系统，才是正道。