我在 2014-2018 年的 37 个产品思考片段

我从 13 年开始做产品，14 年底开始在网络上写东西，一写就是五年了。

我回顾了一下截止去年底的所有文字，感慨万千。它们记录了我的产品思维从无到有、从模糊到清晰、从简略到复杂的全历程。

有时看到早期许多文字，既有趣又俏皮，顿时觉得已经老了，深深怀念当初放飞自我的自己。

我把感触比较多的、可能对你有启发的这 37 条整理出来，希望能帮到你。

1

点子只是灵机一动的故事，就跟知乎上的百万鸡汤一样，没有细节只有情节，投资人不会相信只有点子的创始人、市场也不会承认做不好的点子。

还有一个真相是： 你能想到的点子，100% 已经被别人想到了 。绝对被别人想到了，无一例外。

2

热情和勤奋很重要，加班很重要，累得瘦了 50 斤很重要，带领大家喊口号打鸡血很重要。但是都只是基本的条件。

还需要什么呢？对商业逻辑的敏感，对业务能力的把控，对社交关系的掌握，对团队管理的熟悉。在某个专职的岗位上也许具备5 种能力就能玩得飞起，但创业却要会 50 种。

3

“只从用户思维出发”是很典型的对产品经理的误读。这来源于许多招聘网站提到的，能够从用户角度看问题，以及能够随时切换小白用户的视角。而它们的完整解读应该是这样的：

不是只从一个用户（你自己）的角度看问题，而是要从所有用户（至少大部分用户）的角度看问题。

随时切换为用户，就意味着 要能随时切换回产品设计者 ，这才是产品经理，否则不就只是用户嘛。

4

有的人概念里，好像产品经理就应该焚香沐浴，然后坐在空荡的院落冥想，过了一段时间忽然就可以顿悟了用户的痛点或者产品的迷思。事实当然不是这样的。

像宗教仪式里那种祈求自己的灵魂与大自然或者上帝产生某些联系的行为，正好与产品经理思维在两个极端。产品经理偏偏应该是最不该相信直觉而是相信事实的，是最不应该深入自己的灵魂而是探索社会和大众的。

5

四个方法，能够帮助我们培养产品思维。

像哲学家一样去思考本质。

像婴儿一样保持好奇心。

像运动员一样去锻炼修行。

像小白一样虚心求教。

6

有一定追求的产品经理往往不会总逞口舌之快，说自己的理想和远大志向。还有一些产品经理则认为产品的工作无非就是按部就班实现功能、完成任务，并没有对产品的未来寄予多少期待。相比于「改变世界」或者「就是赚份工资」，我觉得介于两者之间的 「把事情做成、让用户更满意、为社会创造价值」 会是更好的心态。

7

产品经理如果看到一些很炫的 APP，尤其一些很炫又相对比较成功的APP，会误认为它们的成功完全归功于用户体验。

我可以负责任地告诉你，包含交互、视觉在内的用户体验，在用户需求尚未满足前，都是废物。满足用户需求是 1，而用户体验是可以在 1 后面添加的 0。

8

产品经理的任何工作都是讲目的的，文档是为了跟开发协作和留作记录，那就保证在你们项目里协作和记录都可以良好运转就行了。

或者再举个夸张点的例子，做用研访谈时，没必要完全按照之前的大纲来。如果发现每个访谈对象纠结的点都在提问范围外，那就扔掉大纲，把这个问题搞清楚。甚至发现问题已经确定搞清楚，剩下的访谈也都可以不做了。

产品经理尤其不要沉浸在每天八九个小时的工作充实感上，觉得「我忙了一天了」。充实感应该来自于真正产生的收效上，「我今天确定了几个需求，输出了几份文档，解决了几个问题」。

9

自从做 O2O 行业之后，历经美甲师、外卖配送员和网约车司机三个群体，我已不止十次八次深切体会到“原来他们会这么想！”的感受。你不像他们一样生活、一样理解世界，即使有再强的同理心也没用（除非你有先知或者窥探人心的能力），无非还是要理解别人理解世界的方式，那这就不是靠想象力了，靠的就是真真切切的感知用户。

10

曾经有做 B 端产品的同学问我，说他冥思苦想了一个星期，都分析不出甲方到底想要什么产品，问我该怎么提高 B 端的需求分析能力。我说这压根不是能力的问题啊，你明明立马就可以联系到甲方跟他们聊一聊，为什么要自己在这瞎想呢？哪有产品经理能用格物致知格竹子的方法就洞悉世间万物啊？

11

很多经典案例或者优秀产品设计总结，都会把“另辟蹊径”、“卓尔不群”、“意料之外”、“上帝之手”来作为形容，然而实际上这些优异的产品设计都是基于用户已有的需求。跟我一起念： 用、户、已、有、的、需、求！

12

从问题到产品的逻辑链条应该是完整的，且清晰和合理的。

市场->用户->问题->需求->功能->产品

13

我们不能在做产品和运营策略时把钱看得看重，把用户视作唯利是图的群体。用钱来解决各种问题，永远都是最偷懒的方法。用户当然能被钱吸引来，但用户不会只在乎钱。产品逻辑的合理、产品交互的顺畅、产品界面的美观，以及运营活动的合理性、趣味性、公平性，才是真正让用户留在平台上的产品价值。

作为互联网人，这个懒都不能偷。

14

用户的需求是动态的，并非是固定不变的，而是会不断迁移的。消费市场、需求市场从来都不是红海蓝海泾渭分明。还有很多时候，用户需求甚至用户习惯都是跟随着产品在改变的。

以静态的视角去看待用户和需求，就会陷入自己挖的坑。

15

用户在使用你产品的时候，希望听到的是“让我来帮助你解决问题”，而不是“你看看我们这啥都有，你试试这个呗，你试试那个呗，我们特别便宜...哎，你别走啊！帅哥！你不要残忍拒绝！去打个五星吧！”

16

这世界上，你说什么是创业，什么就是创业。

但剥去这个华丽外衣，具体怎么做生意，还是得怎么做生意。

这才是正道。

17

每次在“在行”上跟产品新人说完主要的几条建议之后，我都会强行加一条“ 千万千万记得，不管什么都要养成记录的好习惯，以防扯皮 ”。

乔布斯说过，关于因为无法溯源导致的撕逼和扯皮，被称为产品经理的七大噩梦之一（假的）。

18

互联网的需求更替是频繁的，一方面是大环境随时在发生变化，去年你还在刷微博，今年已经是朋友圈了。另一方面，需求获取的渠道也是多样的，产品经理可能会有新的发现和新的判断，未必都是之前没想清楚。

当然，如果需求都是老板从什么《易经》中得到感悟、从云卷云舒花开花落里得到启示，让你手忙脚乱给他改来改去，那也没意思了。

19

有的技术团队和产品团队都坐在同一间办公室了，居然都经常缺乏沟通。技术团队不知道当前做的功能是给谁做的、是提供什么功能、满足用户什么价值的。

这些不是很高深的理论，也不需要深入学习，只需要通过产品经理做些了解，就能少挖一些坑，也就不会轻易返工。

20

之前在锤子的时候，做安卓系统，我们会对原生提供的一些可复用的模块很熟悉，这样我们会设计出成本更低的方案；在做上门美甲以及现在的众包物流时，我们会跟开发的同事一起设计订单逻辑和数据结构，因为这些既跟具体实现的方法有关系，也跟用户对产品的使用效率有关系。

这些可以算作技术，却并不是日常生活里理解的“用 C 语言写一个排序”那样的技术。比较让人头疼的是，很多人问出产品经理是不是需要懂技术的问题，脑海里想的是下个星期要不要报个 Java 学习班或者买本《7 天学会安卓开发》，这是很荒谬的。

21

一旦有了问题，要表现出“我们马上改”和“下次不会犯”的态度，这才能让工程师更信任。硬说“人都会犯错啊，你不是也会出 bug 嘛！还不高兴我们也出点问题嘛！”既不能挽回颜面，也不能挽回工程师的认可。

22

还存在着一种特殊情况，就是某些工程师确实性格或者职业操守比较一般，会以各种借口做挡箭牌，习惯性跟产品经理撕逼，故意推延实现需求甚至刻意删减需求。这种是我认为的唯一能接受撕和吵架的场景。不过针对这种情况，最好的解决方案是反馈给他的上级，让上级来判断孰对孰错，同样不要指望撕逼能带来质的提升。

23

懂技术并不是就要能自己成为架构师、自己成为工程师，又可以规划技术架构又能实现产品功能。 懂技术是要明白技术实现的逻辑。

24

在一个组织内生存，最重要的事情是体现你的价值，组织才会重用你。产品经理的价值当然最重要是在决策、出方案，但一个方案，用户不认可，价值是0；一个方案，没有落地，同样是0；一个方案，出了严重的产品逻辑问题，也还是0。

25

我团队有个同学入职一个月找我聊，哭得梨花带雨，说她在之前公司里，做的都是从0到1的“大项目”，能深度决策影响这个产品，现在做的事情太小了。

我问，这个产品最后上线了吗？她说是实验项目，做了半年还没上线。我说那你反思回想一下，虽然你做项目时感受很好、自己是负责了不少东西、有指点江山的意思，可作为新项目产品都没上线、都没接触过用户，你会有什么成长吗？

要求低的事情，再大也不会有成长； 要求高的事情，再琐碎也能有进步 。

26

都说产品是产品经理的孩子，要悉心呵护。只是有的产品经理会过于溺爱，不愿否定自己过去的需求，在别人质疑时也常常是保护的姿态。

要证明一个需求“有用”实在太简单了，提高10个pp有用，提高0.1个pp也是有用，但要证明是不是要一直把这个需求养大、是不是有更重要的需求值得尝试，这其实是难题，也是考验产品经理对真正用户价值的理解。

27

有的产品经理并不在意用户，他们在意的是功能的酷炫、项目的完成、商业的成功，也不会考虑用户的感受，想象用户所处的环境，不会“先天下之忧而忧、后天下之乐而乐”，那做出的产品就总会缺点什么，无法直击别人的痛点。

28

有的产品经理会苦闷明明很努力却不受人待见。反思往往会发现，在做的事情都是苦力活，并不存在竞争力。能做许多别人做不了的事情，才能凸显价值。