这篇就不写具体的工作感受了，就写一下自己在产品管理工作中的学习心得吧。

产品管理虽然在国外的发展有很长时间了，但大家都知道，在国内的发展也就是那么几年，具体到我所在的互联网行业，更是没多长时间，我记的在我刚转行成产品经理的时候，就和联盟里好多新入行的朋友一样，一头雾水，根本无从下手，身边连一个可问的人都没有，那是相当的郁闷。

但是郁闷归郁闷，工作是不能停下来的，老板可没说“带薪进修”，哈哈！

那怎么办呢？唯一的方法就是“边做边学”。

我总结了一下自己学习产品管理技能的思路和方法，具体如下：

       思路：从实践到理论，再通过实践来检验，逐步增加个人经验。 

       方法，主要有三个，我一一说来：

直到现在，我也始终认为国内的产品经理要学习产品管理方面的知识，最佳的途径就是“从实践中获得”。

我刚做产品经理的时候，面对的问题有很多，记的当时有一个任务就是让我写一份产品设计文档，在现在看来，产品设计文档这个名称是有问题的，不能说错，只能说是不够准确，什么是“设计”，设计是属于工程类的名词，强调的是数据和量化的内容，确切的说，设计只能由工程技术人员来完成，但是公司就是要你来写这个文档，当时可难死我了。

第一，没有可参照的东西，倒是找了一大堆相关的文档，不是编码设计的，就是模块设计的，看似都有用，但是我一想，如果这些就是我要写的东西，那开发人员就搞定了，还需要我多此一举吗？估计不是要这样的文档，那又是要什么样的文档呢？

最后没办法，只能向老大不耻下问，问问老大希望要的文档是什么样的，其实，在我看来，虽然老大们提出了这样一个文档撰写要求，但是，在他们的意识中也是模模糊糊的，也无法准确说明这个文档应该包含什么信息。

因此，当面对这种问题的时候，就不能用“问答题”了，要采用“选择题”办法了。

首先是“排除性”的选择。这是用来排除现有文档内容的。

例如：

问：在这个文档是否要和《模块设计文档》一样，说明功能模块呢？

答：是的。

问：那是否要从技术实现的角度来说明呢？

答：不用。

……

通过这种排除性选择，就可以明确出“产品设计文档要有产品功能的说明，但是不是在技术的层面上定义”。这就能够使自己知道现有文档哪些是和即将写的产品设计文档有关的。

通过这种排除性选择的方法，其实就是把最大化的缩小了产品设计文档中要出现的内容范围。

但是产品设计文档不是一大堆文档的“精简整合版”，里面肯定有自己的重心和要求，因此，接下来你还得把你的想法和老大们说一下，这就是“确认性”的选择。

例如：

问：我考虑这个文档中应该加一些对产品市场的分析，可以吗？

答：可以。

问：那从市场前景，市场风险这些方面进行描述可以吗？

答：可以。

问：需要市场收益的内容吗？

答：不需要。

……

通过这种确认性的选择，就可以明确出“产品设计文档除了对现有文档的内容参考外，还可能要加入的信息”。

因此，一个“排除”，一个“确认”，就能够把产品设计文档的主要出现的内容范围确定下来了。

以上就是一个简单的例子，根本还是想说明，当你不知道如何去做的时候，采用这种方法能够最有效、最方便的去协助你确定工作方向。

尤其是对产品经理来说，工作中面临的问题要比机会多的多，还说文档吧，咱们不像程序员，项目经理什么的，他们手里都有整套的规范文档，甚至微软都为项目经理提供了project这样的工具，咱们有什么呢？可以说是一穷二白，再加上不少公司的老大们虽然采用了产品管理，但是都处于模模糊糊的状态，有时候他们提的一个要求，按说不是咱们该做的，但是他就认为是产品经理该做的，去说明吧，胳膊又拗不过大腿，做就做呗，那怎么办呢？我个人的体验就是“实践出真知”。

暂且不说是应该做还是不应该做，就说这种实践的过程，其实就是对自己的提高是有很大帮助的。

所以，我个人是不太赞同大家在遇到问题的时候立刻想到的不是“个人尝试”，而是“求助他人”，多次失败的尝试带给自己的体验要比直接获得求助更加深远。

这里就不说那个“苹果换苹果”的故事了，再说就有些俗了。

但是话说回来，俗归俗，但道理不俗。当你有了一些想法，有了一些体会，甚至有了一些思想的时候，而你周围却没有一个可以交流的对象，那种痛苦，我是深有体会，就如同一个人在跋山涉水，历尽艰险以后达到了世外仙境，但是却发现，这个世外仙境竟然只有你一个人，这种折磨想想都可怕。

因此，我个人的体会是，在自己通过实践获得一些体会后，希望能够和同道中人一块来交流和分享，说不定别人在同一个问题上有比自己更深入的感受呢，如果经历过这样一次交流，那我可就赚大发了。

刚开始的时候，公司一共有4个产品经理，都是像我这样转型的，问题大大的，思路少少的，倒是有交流，可都是交流一些“这产品经理可怎么做呀”，“不行，我得向上面说一下，我还是继续做项目去吧”，“实在做不下去了，我就只能撤了”，类似这样的牢骚和不满，说实话，我当时也打过退堂鼓，因为压力太大，不懂的太多，又怕做不好把饭碗丢了，甚至想着与其等着丢饭碗，还不如自己先行一步呢，这样，还能落个“离职”，而不是“辞退”的名声，舆论导向是一定要考虑的。

后来，和我一起最早做产品经理的4个人，到我离开这家公司前，就只有我一个了，有的走了，有的又转回去了，我能够理解他们的心情，确实太郁闷了。

因此，在那个时候，我就把交流的空间逐渐转到了公司外，有了互联网这个工具，交流真的是非常方便，周围同行少，网上肯定多，这样一来二去，就在网上也认识了一些朋友，现在又有了联盟，有了这样一个专业的平台，这么多的同行，真是工作之大幸呀！

不过我还是感觉联盟里，大家交流的欲望不是很强，不知道是因为“不想”，还是因为“不屑”，我想都不是，估计是大家觉的万一说的不对，会有人笑话的。

我想，这种想法就是多余的了，我说句招人骂的话“现在，就国内而言，谁敢说自己就是产品管理方面的大拿”，不论是个人还是一些机构，所展现给我们的无非都是他们自己的思想而已，是对是错，不是那么容易判定的。

联盟里的老白，andrew305以及时间长没见的老汤，他们写下的每一个字都是在把自己的想法和大家分享，即使文笔稚嫩，语病百出，言语拖沓，但是那是个人真实的经历和思想，这才是，咱们作为产品经理，最需要去体会的。

拿起笔，奥，应该是敲起键盘，来写下自己的体会，去和大家来交流吧。

我觉的联盟有个口号挺好：没有对错，只有思想。这就是咱们交流的原则，不错。

3、尽信书则不如无书

国内有几本从国外引进的关于产品管理方面的书，联盟网站上我看也有介绍，我个人的原则如题。

在我看来，书就是一个参照物而已，我个人对于书的作用是这样理解的（仅限产品管理方面的书）：

在个人有了一些产品管理方面的想法后，去翻翻书，对照一下，书中是否有自己想法的篇幅，如果有，说明在这个方面，自己的方向或者方法是对的，如果没有，就要分开考虑了：第一，是自己做的不对吗？如果不对，那书中又是如何说明的呢？第二，是不是书中的内容不适用于国内的情况呢？如果是这样，那就需要在接下来的工作中继续验证，国外的产品经理和国内的产品经理还是有差异的。

因此，在我看来，这方面的书，用咱们的话来说，就是“用户手册”，需要的时候拿出来看一下，根本的还要在实践中去体会，毕竟用户手册即使写的再全面，许多不可知的问题也会发生，而这种问题恰恰为继续丰满用户手册提供了实践来源。

其实，我也没看过几本这样的书，也就是《第一本书》和《第二本书》，不过都是在我有了一些经验后，断断续续翻看的。

这里说一种我非常不赞同的阅读习惯，叫“啃书”。

听这名字，都“啃”上了，这书还能用吗？在我看来，啃的前提是“营养不足”，啃的后果是“消化不良”。

管理类方面的书，最佳的阅读阶段是在自己有一些经验后再进行，如果一点经验没有，或者经验很少，去读这方面的书，那就是一种痛苦了，后果就是根本无法理解书中的知识点，或许能有一个大概的印象，也可能会去在工作中采用，但是你最终会发现，你只是在死搬硬套而已，读书要实现的“举一反三、触类旁通”，你根本做不到。

不要被这些书的内容所桎梏，作者自己还在不断的修正自己的错误，更别说咱们这些读书的人了。

我到现在，越来越感觉到做产品经理，要的不是什么方法，什么工具，什么模板，什么思路了，其实是要的一种思想，一种能够把握大局，运筹帷幄，统观天下的思想，还有宽广的胸襟，平和的心态，广阔的知识以及领袖的魅力（这组排比用的不错，自己赞一个，哈哈！）。

       因此，我在现在，反而很少去读产品管理类（延伸至其它管理类）方面的书了，我会去读一些经典的哲学类书籍（上学的时候不以为然，现在感触很深了，该补课了），还有一些历史方面的书，军事方面的书，和一些奇闻轶事的书（这个够酷吧）。

其实工作中的许多情况都是能够在这些书中找到同样思想的，半部论语治天下，连天下都能治理了，就别说咱们这点小活了。

因此，我个人在产品管理方面的学习建议是：以实践为核心，以交流为途径，以书籍为参照。