做什么大于怎么做

坏的产品坏的千奇百怪，好的产品都有相似的原因。就和做人一样，做产品经理需要遵循原则。设计的原则，程序的原则，运营的原则，思考的原则，管理的原则，行业的原则，相处的原则等等。

原则的重要性已经无须一再强调，重要的是产品经理究竟应该遵循哪些原则。每个产品经理都有自己的原则，但我们如何确定这些原则是否普适而且能引导产品走向优秀？

这就是我写这个系列文章的原因，我只是个成长中的产品菜鸟，很多原则的探讨并不完全来自于实践，所以我对自己定的目标是“迭代”，希望通过不断的思考和写作，能进一步迭代出更好更普适的原则来利己利人，同时欢迎大家帮助我一起迭代这份产品经理的“原则清单”。

我能想到最重要的原则是“做什么大于怎么做”，它不单单是产品经理的思考原则，也是任何工作乃至人生都需要遵循的原则。不过本篇我们着重以产品经理的角度去思考这个原则，不是讲究战略的CEO角度，也不是“选择大于努力”的人生角度。

“画脑图”的时间应该远远多于“画原型”

现在请各位产品算一算，你花在“画脑图”和“画原型”的时间各是多少？

我给不出一个科学的比例，但我知道画脑图的时间应该远远多于画原型。有人说原型可以表达很多脑图表达不出的东西，解释起来更清晰，程序猿更喜欢看图而不是看字。是的，原型很重要，它是连接想法、界面和产品的关键步骤。

但是切记，在产品策划的早期，你可以用简单原型去加强思路表达，但千万不要花时间去做高保真原型和复杂的交互效果。思路不断在变化，评审过程中，不同产品也会有不同的设计方案，很多时候不同的方案都有各自靠谱的理由，没有人可以确保自己第一版就做出完美的原型直接给到设计。早期的原型一定会被修改的千仓百孔，修改高保真原型可比修改脑图的成本高得多的多。

与其纠结在细节和界面，更重要的是用脑图梳理清楚你究竟要做什么。如果能把做什么梳理的清清楚楚，除去可有可无的功能，确保每个功能都有它存在的意义，然后再去思考体验和交互往往更有意义。

小孩子才聊体验，大人聊的是需求。

我第一次听到这句话的时候，颇为做“体验”的人感到不公。因为体验是一件非常重要的事，天猫和京东做的都是类似的需求，差异在于体验；mac和windows做的也是一样的需求，差异在于体验；锤子手机因注重体验而受到尊敬；怎么可以说小孩子才聊体验呢。

不过仔细分析，这句话是有道理的。体验其实是市场成熟之后的行为，核心的需求已经被发现，各家都用不同的方法去解决它，拼的就是谁的体验好。但是真正决定产品能否成功的因素，还是你解决的需求是什么，也就是你在“做什么”。

各家音乐产品的体验其实有很多细节差别，网易云音乐其实算不上体验好的，界面和音乐专业度不如虾米，版权库不如QQ。但是我一开始就是愿意一首歌一首歌的重新点红心来转移歌库到云音乐，原因很简单，因为只有云音乐才提供320kbs音乐免费下载，这个需求深得我心啊。

我现在在一家P2P公司工作，我最大的体会就是，无论你把注册流程做到多简单，界面做的多漂亮，信息规划的多科学，也不如竞争对手把收益提高一个百分点。用户对赚钱和安全的感知远比产品体验重要得多的多。

“做什么”其实有很多可以做。

很多人觉得思考做什么是一件很虚的事，好像也没什么好做，其实要做好“做什么”是一件很庞大的工作。

第一件要做的事，就是思考为什么要做这个功能。针对某个需求可能会衍生出很多功能点，这里面有基本功能、期望型功能、兴奋性功能，还有很多可有可无的功能。在这一步取舍至关重要，这里会涉及到另一个产品原则“可有可无的功能先不做”，我们应该尽可能保持功能和界面的简单。

第二，对于要做的功能，我们要定义功能的边界。虽然大部分产品的不同功能之间是有关联的，但是在做初期的产品架构时，信息架构一定要梳理的非常清楚，好的信息架构区分了功能的边界，它可以用合理的功能点数量覆盖到系统所有功能，且功能之间的耦合性极低，在后期无论是要增加还是减少功能，都不会引起系统太大的变化。

第三，对功能上线有规划。如果你要做五个功能，它们的优先级是怎样的，核心功能是什么？第一期先做什么功能，第二期做什么功能？第一期做的功能是否很好的搭建起了产品的基础框架而有利于产品的后续迭代。

第四，思考功能（子系统）是如何配合来形成一个系统的。阅读文章后的“点赞”功能，就是一个能起到画龙点睛之效的功能。如果我们把文章、阅读者、写作者看做一个系统，点赞多刺激写作者输出，阅读者也能根据赞的数量迅速找到优质内容。如果能思考清楚功能之间的关系，我们就更能了解用户在产品里的行为并因此找出更好的运营方法。

只想怎么做，压力小得多

强大的执行力有时并不一定是好事。我们一有解决方案便马上付诸行动，因为这样完成任务更快，但这并不是对结果负责的态度。产品是一个很奇怪的东西，我们永远不能抱着“完成”的心态去做产品，产品永远都在“迭代”，不优秀的产品一定会死。

雷军有句话说的好，你不要用战术上的勤奋掩盖战略上的懒惰。

将正确的事推动

如果说产品经理的职责是“将用户体验做到极致”，不知有多少人会同意，反正我是不同意的。

“以原则为中心的产品经理（一）：做什么大于怎么做”出了后，我想了好久都找不到接下来的主题。有一段时间我想写“从用户场景出发”，脑图大纲都出好了，准备动笔之际，最近的一个项目却再次暴露了自己经验的不足——项目没有按时上线。

方案出的倒是准时准点，但中途因为各种意外状况，比如人员请假，高优先级的需求插入等等，项目排期整整延后了半个月。方案没拖，听起来好像没我啥事，但这其实就是我在事前计划及事中跟进时缺乏经验的表现。

我的计划里没有缓冲、没有对平台近期紧急需求的预测，人员排期里没有并行而用的是瀑布式开发，需求优先级降低时我没有及时调动空闲资源。我有一万种方法可以让工期跟上进度，可我却傻傻的坐在原位感叹无能为力。

我费了多少心思在用户场景里啊，可是项目到现在都还没上线呢。要知道有些需求一旦延后，效果将大打折扣。

当然我并不是认为用户体验不重要，但确确实实，产品经理不是对用户负责的，他同时对用户、公司和实现负责。产品经理想的应该是如何将正确的事推动。

正确的事:

德鲁克老先生关于“做正确的事情”有一段经典论述：效率是以正确的方式做事，而效能则是做正确的事。效率和效能不应偏废，但这并不意味着效率和效能具有同样的重要性。我们当然希望同时提高效率和效能，但在效率与效能无法兼得时，我们首先应着眼于效能，然后再设法提高效率。

那现在的问题是，对产品来说，什么是正确的事，什么是有效能的事。

注重用户体验对产品来说是一件正确的事，但我们仔细想想，提高用户体验的目的是什么？？归根究底其实还是希望用户能够“购买”产品，只不过我们通过提升体验，从更长远的角度来提升盈利的机会。

如果一个产品用户体验优秀，但是商业模式不清晰以至于预期内都无法盈利，我会认为这是个失败的产品。但是我佩服他们以用户为导向的价值观。

答案在我心里越发清晰，产品所谓正确的事是平衡，是在努力考量过用户体验、商业盈利和技术实现后，找到一个最佳的可实行方案能将三者的价值都最大化。

剩下的就是，如何推动。

将事情推动:

推动是一件很难的事，能把事情推动直至推成并不是靠执行就能完成的。都说产品经理没有实权，是的，产品推动人靠的不是职务或者排期，靠的是影响力。

这里不得不说一句，产品经理是一个很辛苦的职位。虽说工作在于奖惩清晰、职责分明，但作为一个有影响力的产品，可能压根没有职责的区分。需求文档提交后，开发没有看没有重视，这是开发的问题，但更多的是产品经理的失职，你为什么没有想办法让他重视起这个需求，如果他不重视，是不是你的方案本身就没有传递出有意义的价值？

回想起自己在开发评审时的状态，我像一个战士一样回击每一个质疑，这不是推动事情时该有的心态和行为啊。我给自己定了个规矩，开发评审时，理性的评判每一个质疑，以寻求更好的解决方案为目标。其实再仔细想想，开会更多是一种形式，达成共识的大部分精力和机会应该是在会前完成的。早应该在开会之前，我们就需要面对面的和开发进行沟通取得共识。

推动还可以从文档下手，出方案是一回事，让开发明白是另外一回事。我们出的文档当然越简单越好，但更重要的是，符合开发的思维习惯。我曾经想用一个文档贯穿到设计、标注、后端和前端的所有过程，但发现技术和设计的思维是不同的，设计喜欢看列举好的页面，他们的思维是穷举。

技术喜欢看归整好的页面，希望知道哪些页面可以复用，他们的思维是逻辑流程和归纳。产品经理是有义务为需求文档整理出更好的展现形式的，方便了开发，人家心情一好，工期不就赶上来了嘛。

我在一开始思考方案时，会屏蔽掉技术实现，完全从用户角度出发，实现的问题可以之后再和技术讨论，这样产品坚持自己观点时也是有用户场景作为支撑的。但其实再仔细想想，在构思方案时，是不是也能在不影响用户体验的基础上，想一些能方便开发实现的方案。比如关于接口的请求，在页面顺序设计上，我们可以尽可能减少接口请求的次数，而把返回的结果集中到一个页面。

不能否认有些开发对不懂技术的产品是存在赤裸裸的排斥的，这时我想借用下别人文章的描述(引用自，http://qiuyuexp.com/pm/，产品经理最重要的能力)：

工程师不理解需求，我们不论是画图、写文档、做原型还是直接表演给他们看，一定要弄到他们理解需求为止；

合作伙伴不配合，我们不论是威逼还是利诱，拍桌子红脸还是跪在地下磕响头，一定要弄到他们配合为止；

老板不支持，那我们就用最小的代价和完整的逻辑证明你的观点，说服他，没日没夜地说服他，厕所里堵住他说服他，电梯里拖住他说服他，满地打滚，以头抢地，把刀架在自己脖子上说服他；

自己团队的同事解决不了的技术或者业务问题，不论是买书自学还是彻夜查资料还是找到其他行业大牛在他楼下跪一夜，一直到想办法找到解决方案为止。

推动的另一个难点在于和上级和老板的沟通，我们经常会抱怨老板总是突发奇想的插入新需求，但好的产品经理会在优先级上和老板达成共识（观点来自，戴雨森，好的产品经理/糟糕的产品经理）。和老板有了共识，调动其它部门的资源也会更加容易。

再有一个难点在于项目管理，再次引用别人的观点，好的产品经理把有限的资源聚焦在最能够推动产品目标的少数事情上。关于这点，自己经验不足，还有待加深体会，希望以后能用自己的文章表达给大家。

结语:

像我这样一个入行不深的新人，却妄想写好“以原则为中心的产品经理”这系列文章，其实很难。原则这东西虽然相通，但是要把它简练成真理一般的存在，我目前是做不到的，真诚的希望各位可以把你们总结出，认为十分重要的原则通过公众号与我交流哦，公众号请搜索wumuwizard，谢谢~

从打造用户喜爱的产品出发

一直想找一个词去形容产品的终极目标，“用户喜爱”，应该没有更加贴切的了。

然后是另外一个重要问题，确定了产品的终点后，怎样踏出构建产品的第一步？

不忘初衷，很多事做下来都发现初衷是最重要的，这其实就是在强调终点和起点应该是同个东西。这样一梳，打造产品的起点也相当清晰了：

“从打造用户喜爱的产品出发”

一、起点决定终点

“推动事情尽快落地”是产品经理很重要的能力，很多人做产品的起点就是让事情尽快实施。在市场竞争如此激烈，MVP观念盛行的当下，这样做无可厚非。

不过这里混淆了“产品”和“项目”的概念，用户根本不关心你的产品用了多久开发出来，他们只关心自己喜不喜欢这个产品。

这还牵扯到产品经理的职责，产品经理是对“价值”负责的，包括用户价值和商业价值。一个合格的产品经理思考最多的不是进度，而应该花更多时间探索产品让用户喜爱的价值点在哪里。

这也就是“从打造用户喜爱的产品出发”如此重要的原因，它决定了整个团队的氛围和流程是以价值为核心的，而不是所有人花了那么多精力和时间，却做了一个没有人用的产品。

二、MVP所不能解决的

首先摆上一个神图：

这幅图深刻的解释了MVP的核心概念，当你想真的测试一个蛋糕好不好的时候，你肯定不是用原料去让用户品尝和体验，而是先做一个承载了核心味觉和设计的小蛋糕去测试用户到底喜不喜欢吃。你看第二种方法，你可以清楚地辨认出，在每个阶段的输出都是一个可用的产品。

接着我们来说MVP不足的地方，MVP强调的核心是测试概念的每一步都要推出完整可用的试验品，从而最快的获得用户反馈。但我们不禁要想，一个完整可用的产品真的能得到你最需要的用户反馈吗。

我们来想想很多现有的以MVP模式开发的产品，第一版的产品，它们很简单也很快速，但是丑的令人发指也不好用，即使有价值，但是却会因为激发不起用户喜爱的情感导致连反馈都不想给。

正向medium上的一篇文章（https://medium.com/the-happy-startup-school/beyond-mvp-10-steps-to-make-your-product-minimum-loveable-51800164ae0c）所说的，这样一个测试版推出后，假如无人使用，你怎么知道没人用的原因是因为需求价值的问题，还是因为设计和交互太烂，压根就没人愿意反馈？？

三、设计是生产力

在产品的早期，对设计的忽视是非常常见的，因为项目这么赶，技术却要在调像素这种小事上花费这么多时间，这不是“正事”啊。第一版只要流程通顺不出太大问题就可以了。

一个定义好产品的经典模型是这样的，有价值，可行，可用，其中交互设计师对可用负责，程序猿对可行负责，产品经理对价值负责。嗯，压根没有提到设计。

设计真的那么不重要吗，不，无数的例子证明，设计就是生产力。衣服好看重要吗，用户为什么如此痴迷于苹果产品？？

尤其是界面设计所营造的氛围感，它将高度影响你的目标人群定位，第一版若不能吸引到你的目标人群，产品要如何运营下去？？

这也是本文认为“从用户喜爱”的角度出发来做产品的原因，设计是唤起用户情感很重要的因素。人喜欢美的事情，这件事是不会变的。

四、到底该怎么操作

在这么多理想化的理念后，有一个根本矛盾没有解决，好的设计是要花大量时间的，或者说MVP的第一版就达到让人喜爱的程度也是要花大量时间的。

或许更好的问题应是，怎样用最有效的方法让产品得到用户的喜爱？

这一点我自己也在思考T-T，欢迎大家提出你们的看法，不过目前自己有几点思路：

1.情感化的文案：包括各种按钮、提示文案，简单改下文案就能迅速提高产品的吸引度，投入产出比极高。

2.注重产品的第一印象：包括启动页，首页，桌面图标的设计，以及如何在用户打开APP的第一刻，就让用户感受到产品的核心价值并唤起正向的情绪。比如说使用facebook的第一刻，产品就会让你知道你有很多朋友正在使用，对一个社交产品来说，“朋友在用”有着极强的说服力。

3.亮点功能：早期的亮点功能就是一把利剑，它是你的产品让用户口耳相传，并在竞品海洋里让用户第一念想起你的原因。所以在核心需求确立之后，也不需要急着就去验证产品，应该让这个需求有个颇具亮点的壳来吸引用户以起到营销的效果。

4.好的反馈机制：MVP的核心理念就是最快的获得用户反馈，当面访谈和好的产品反馈设计对早期产品来讲非常重要，如何优化反馈流程，如何增强用户的反馈动机等等都是需要着重思考的东西。

五、 结束

如果用一句话来解释产品经理的工作核心，我可能会这样说，

“找到一个痛点，探讨解决方案，再探讨解决方案让用户喜爱的原因，然后在设计时尽可能强调这个原因给用户。”

嗯，说起来多简单，做起来多难啊。

作者：乌木

来源：乌木（ID:wumuwizard）