有言在先

做事、做人，都有两种态度：理性和感性。在职业生涯的前几年，也许做一个纯粹理性的产品经理，更为合适。

一起去做产品吧！

产品经理的三个阶段

每个产品经理的做事风格可能都不一样，但是归纳起来大致可以分为两种方式：理性地做产品和感性地做产品，它们并不是矛盾的。一个产品经理新人，在整个职业生涯中，可能要经历从感性->理性->感性这样一个流程。

❶ 初级阶段：感性做产品

一个产品新人在职业生涯的前几年，往往会用感性思维做产品：

A.你很喜欢体验一些竞品，然后好的功能，你喜欢不问原因的Copy过来。

B.你喜欢说“我觉得这个应该这样做…”，主观地说出你的想法，也许你是对的，但大部分情况你是错的，因为刚开始，你的直觉不准。

新人容易感情用事，而且年轻气盛不容易被别人的观点说服，但是新人没有阅历、没有丰富的人生经历，你的直觉往往是不准确的。如果没有及时转变思路，新人很容易瞎忙。

❷ 中级阶段：理性做产品

初级产品经理解决问题时，目光往往局限于个人（很多时候甚至你只盯着自己）。当你不断打怪，不断踩坑，攒经验升级后，你的目光不再局限为个体了，你开始理性地看待用户需求了。

单个用户的需求千奇百怪，为个别用户设计产品没有意义，特别是产品新人往往是在为自己的需求做产品。中级阶段的产品经理，能将眼光放到整个用户群体上了。每个用户的需求千奇百怪，但当用户聚集为一个群体后的需求，往往是比较统一的。

理性地做产品，最重要的事情是相信数据的力量。你应该从数据中看到用户的需求，因为这时候你的直觉依然是不准的。你的产品设计一定要有反馈：从产品的各种数据中找到直接的反馈，从用户各种评论中找到间接的反馈，然后根据这些数据整理模型，有目的地提升产品魅力。

❸ 高级阶段：回到感性

有一天，你终于成为了一名经验丰富的产品经理，你做过了不少产品，一款产品也许在你的眼中全部都是数据，这时候你开始回归产品的本质，你敏锐的眼光能够看出一个产品能够解决的用户需求。也许你能够从本质出发，从文化、人性等角度思考产品需求。数据也许能告诉你这个产品是否运行良好，但是从无到有地做产品，还是需要产品经理回归感性。

●●●

理性做产品的第一步：用户调研+数据建模

如何从感性做产品转变到理性做产品呢？第一步，也是贯穿始终的一步，就是用户调研。每个产品经理都知道用户调研的重要性，但是具体操作时，却又往往难以执行下去。如何客观、理性地做产品，用户调研是最基础、最重要的一步。

❶ 苹果真的不进行用户调研吗？

一些人可能会说：用户调研没什么卵用，乔布斯说他从不进行用户调研，因为用户根本不知道他们需要什么，直到你做出一款让他们尖叫的产品，用户才会知道这东西才是他们想要的。但是苹果真的不进行用户调研吗？恰恰相反，iOS系统每天都会上报无数的数据给苹果公司，苹果公司依此会进行iOS系统的产品更新。苹果独特之处在于，它能够根据一些客观的数据提炼出用户真正的需求，所有的产品大师都是这样。

❷ 1000 100 10非常难

1000 100 10是张小龙提出的产品经理进行用户调研的一个方法，每月看1000篇帖子，100篇博客，进行10个用户调查。但是一些简单的事情在具体操作的时候非常难，真正能做到1000 100 10的产品经理非常少（Glen目前也没有做到，之后这方面我会加强）。

认真的用户调研常常会提炼出非常靠谱的用户需求：Glen在大学时有一次做产品设计，是一款O2O产品。当时带着团队进行头脑风暴，但是能够想到的需求别人基本已经实现了，场面陷入死局。迫于无奈Glen选择了一个非常笨的方法：将竞品淘点点在广州地区的所有店家的用户反馈评论全部看了一遍（几千条），然后分类、归纳，最后得出了很多很好的用户需求。

听用户的声音+产品的数据反馈=靠谱的产品设计

●●●

理性做产品的第二步：正确地敏捷

产品新人容易没想清楚问题就急着做事，最后忙了半年，没用！其实是他们没有真正理解敏捷开发，导致事倍功半，产品成功与否只能看运气。

❶ 错误的敏捷

很多人理解的敏捷开发是你有一个想法，然后快速出方案，快速开发，快速迭代。如下图：

这种方法不能说错，不过很多时候你往往没有想清楚你为什么做这件事，归根到底，你还是在凭直觉做产品。前面已经论述过了，产品经理的直觉有时候是不准确的。所以这种方式做产品，成功与否就是碰运气。

❷ 修正后的敏捷

前面的那种敏捷开发模式，是大部分人理解的敏捷开发，简单来说，就是1天出方案->1天出交互->1天出设计->12天开发，两周的开发时间，没有数据预估、没有订立目标，产品最后也可能成功，但大部分情况是产品反馈不好，但又不清楚如何改进（因为没有数据预估），盲目地不断进行敏捷开发，最后团队都在盲目中磨尽了热情。对敏捷开发模型进行简单的修正，即可极大地提高效率：

在输出方案和落地执行之间，增加两个关键步骤：建模预估+制定目标。你的工作模式改变了：1周出方案（包括建模+制定目标），然后根据关键数据因子和目标，将需求点进行优先级安排，分配到几个小版本中，然后剩下的1周完成当前版本的交互+设计+开发。先花一周时间进行方案的设计，磨刀不误砍柴工，最后得出的方案能够说服团队，凝聚力自然而然就提高了。