人人都是产品经理[试读]

我从事的是IT行业，具体点说，是互联网和软件行业。很多人可能都会和我一样，入行久了，看了一些资料，发现里面说的产品经理和我们平时做的事情似乎不大一样，于是做得越久越迷茫，总在问自己――我们到底是不是产品经理？ 有这样的疑问很正常，因为有“产品经理”这个词的时候，还没有我们现在熟悉的“互联网”和“软件”的概念呢。从互联网、软件行业巨头的“产品经理”招聘广告中，就可以发现这个职位的内涵和以往的产品经理已经有着很大的不同。那么，互联网、软件行业的产品经理在概念上究竟有了哪些变化，有了哪些发展？为什么会有这些变化和发展？这会导致产品经理的职责、技能要求有哪些不同？我试着在这一节中给出自己的认识和分析... 查看全部[ 1.2 我们到底是不是产品经理 ]

经常被问到这样的问题： “我快毕业了，对产品经理这个职位特别感兴趣，怎么入门？” “产品经理都是招有几年工作经验的，我原来做技术，要转行怎么做？” …… 经常看到这样的帖子： “研发转产品，真的很痛苦！” “我是软件产品项目经理，如何成功转型做产品经理？” …… 既然想做产品经理，我们就学着用产品经理的思路来解决“怎么入行”的问题，分几步走吧。 首先来看看招产品经理的公司到底需要什么样的人。然后，再问问自己真的是，或者想成为这样的人么？接下来，在出手之前必须找准自己的位置。最后，我试着给出几个可能的切入点。 产品经理的招聘广告 回顾一下前面列过的阿里巴巴、百度、腾讯这3家公司... 查看全部[ 1.3 我真的想做，怎么入行 ]

2.2.1 定性地说：用户访谈 用户访谈通常采用访谈者与被访者一对一聊天的形式，一批次用户访谈的样本比较少，一般是几个到几十个，但在每个用户身上花的时间比较多，通常为几十分钟到几个小时，围绕着几个特定的话题，我们问，用户答，用户说，我们听，这是一种典型的定性研究。用户访谈可以了解用户怎么说，即他们的目标和观点。根据我自己的经验，用户访谈经常用在新产品方向的预研工作中，或者通过数据分析发现现象以后，去探索现象背后的原因。 用户访谈的常见问题与对策 用户访谈经常出现如下问题： 第一，“说”和“做”不一致的问题。 用户经常会骗我们，先看一个经典的索尼游戏机的故事。 索尼找了一些用户来，问... 查看全部[ 2.2.1 定性地说：用户访谈 ]

同样是听用户怎么说，常见的定量研究方法是――调查问卷。 调查问卷和用户访谈的提纲是有区别的：用户访谈的提纲通常是开放式问题17，适用于我们心里还比较疑惑的时候去寻找产品的方向，适合与较少的访谈对象进行深入的交流；而调查问卷通常封闭式问题比较多，适合大用户量的信息收集，但不够深入，一般只能获得某些明确问题的答案，调查问卷不是考试卷，不适合安排问答题。用户访谈与调查问卷之间也有联系，我们经常通过前者的开放式问题，为后者收集具体的封闭式问题。 无论是网上还是线下，作答时间最好不要超过10分钟，否则很多人看一眼就被吓跑了。开篇一般放一些简单的不需要思考的问题；很想知道的内容，需要思考的，较敏感的问... 查看全部[ 2.2.2 定量地说：调查问卷 ]

可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题，通常只能做少数几个用户的测试，看他们怎么做，属于典型的定性研究。 它是UGC21理念的一种很漂亮的实践，在目的明确的前提下，简单介绍一下主要过程。 首先要招募测试用户。招募测试用户的主要原则是，这些用户要能尽可能地代表将来真实的用户，比如说，如果产品的主要用户是新手，那么就应当选择一些对产品不熟悉的用户。 然后是准备测试任务，测试的组织者在测试前需要准备好一系列要求用户完成的任务，这些任务应当是一些实际使用中的典型任务。 接下来的重头戏是测试过程。可用性测试的基本过程就是用户通过使用产品来完成所要求的任务，同时... 查看全部[ 2.2.3 定性地做：可用性测试 ]

只要你做的是一个大用户量的产品（互联网产品往往都有这个特点），那么我们总会惴惴不安：上述3种方法，就算做问卷的普查，回收到的有效问卷也可能不到用户总数的10%，或者说，在样本的选择上都有一定的被动性――需要样本同意参与，所以它们都只能接触特定的少部分用户，那么到底能不能代表目标用户群体？ 虽然绝大多数情况下的经验证明，只要在用户的选择上没犯什么低级错误，他们是“具有代表性的”，或者说接受这种假设是一种性价比很高的廉价解决方案。不过，我们还有数据分析，一种定量的研究方法，数据来说话，看看用户到底是怎么做的，不论是考察目标用户全体、还是采样，都完全可控，所谓“According to the d... 查看全部[ 2.2.4 定量地做：数据分析 ]

上面用很大篇幅说了一些常用的需求采集方法，这一节，我想先抛出一个“一手需求与二手需求”的概念，有个很形象的比喻就是“生孩子与养孩子”，话糙理不糙，我们内部经常这么说。 我们首先把“生孩子”――需求采集视为己任，人人有责，希望所有人都参与，都来“生孩子”，我们帮大家养，这就要给他们一个简单的“生孩子”的工具――“单项需求卡片”，最后，简单介绍一下其他常用的方法，这样才能做到“尽可能多地采集”。 生孩子与养孩子 之前所述的各种方法，都是直接从用户那里得到需求，我称之为一手需求，就像“生孩子”。其实很多时候，我们还会接受二手需求，比如老板说要给用户做个××功能、销售人员说用户哪里用起来不顺等，... 查看全部[ 2.2.5 需求采集人人有责 ]

2.3.1 明确我们存在的价值 用户跟福特要一匹更快的马，福特却给了用户一辆车。 这就是我们存在的价值。还记得小明么？ 他说他需要一个电钻，这是他提出的解决方案，但在大毛的刨根问底之下，发现小明其实想要的是一种温馨的家的感觉，有了这个认识，我们就可以给出很多产品来满足。比如卖他一套实施方案，带着电钻、油画，上门安装；比如用背面有强力胶的钩子挂画；比如直接把画黏在墙上；比如直接在墙上画，并且让小明自己画；再比如放一组书架在那里……经过我们分析得到的解决方案，比起小明自己说的，优势就在于可能省了钱、省了时间、更温馨，等等。 对同一个问题，这两套解决方案的区别就是，一个是用户需求，一个是产品... 查看全部[ 2.3.1 明确我们存在的价值 ]

在整个检测过程中，我们先把用户需求转化为产品需求，然后一步步确定每个产品需求的基本属性、商业价值、实现难度、性价比等。 特别提一下，这里确定的是产品需求的各种属性，不同于之前提到的“单项需求卡片”，那张卡片里描述的是用户需求的各种属性。 把用户需求转化为产品需求 检测的第一步就是“需求转化”，现在我们有很多用户需求，可能记录在“单项需求卡片”里，可能记录在Excel里，可能是用Word随意写的几段话，也可能是一张思维导图。当然，在一个团队里，还是建议大家统一一种记录用户需求的形式。 现在我们就要发挥出“我们存在的价值”，在这个阶段，团队经常举行头脑风暴25，大家天马行空地讨论一番之后，... 查看全部[ 2.3.2 给需求做一次DNA检测 ]

2.4.1 永远忘不掉的那场战争 为什么原来没有这样的战争？ 我没找到理论支撑，但就个人经历和与同事的交流来说，下面是一个因素：更早的时候，公司是按照产品线划分部门的，对于某个产品来说，有自己的产品设计师、开发与测试等，下一段时间要做哪些需求，完全可以在产品经理的层面上决定，所以就算有战争也是部门内部的，比较温和，基本上在分析商业价值的需求讨论会上，也就顺带着确定了下一段时间做哪些。 为什么现在有战争了？ 2008年初，公司组织结构调整，变成了按职能线划分团队，有了统一的产品中心，包括所有的产品经理和设计师；研发中心，包括所有的开发工程师、架构师等；质控中心，包括所有的测试工程师……这... 查看全部[ 2.4.1 永远忘不掉的那场战争 ]

有100个需求，资源只够做10个，是的，当时就是这样。 一直都是这样。 2007年国庆长假回来，我在全力做网店版“自动上架”的功能，简单解释一下:淘宝为了防止一些没人打理的商品始终在搜索结果中，稀释了有效信息，所以所有商品会隔一段时间后自动下架，不再被搜索到，这时就需要用户重新将商品上架。而网店版的用户都是淘宝的优质卖家，所以我们给他们提供了一个“自动上架”的功能。 这是一个确定“怎么做”的过程，当时的体会能很好地表达我的想法，借用一下。 两个礼拜，整天的PK、评审、确认，搞得头昏脑胀，不过终于算是把需求定下来了。 一个功能的多次需求会议中，必然有这样一个过程：开始对一个功能想得不完... 查看全部[ 2.4.2 别灰心，少做就是多做 ]