所谓光阴似箭，日月如梭。回头一看，突然发现自己出道已经快十年了。回顾自己之前演过的角色，其实并不复杂。我当过翻译、测试员、开发人员、测试主管、项目经理、产品经理，甚至是销售员，徒步拜访潜在客户。这期间，我觉得让我感触最深的还是在做产品经理的时候的一些得失。所以我打算在这里写下来，分享给同事们。 其实我觉得我之前做的“产品经理”这个角色应该打上引号。因为真正跑市场的是一个德国的同事，飞遍全球，挖掘需求，但是开发团队在珠海这边，正好我的英语沟通能力还不错，所以就分到了这个所以——一个叫“产品经理”的角色就上来了。 所以，如果我们把customer这个概念抽象封装起来，我们也可以说德国同事其实就是我们产品的客户。所以，其实产品经理的概念还是比较笼统的。你可以做一个以产品为导向的产品经理，你必须把控一个产品创意从诞生到最终实现交付给客户的全过程；你也可以做一个市场导向的产品经理，针对正在销售的产品，发现市场的需求，然后交给开发团队不断迭代等等。 技术债 这可能和我当时工作的“产品经理”的特殊性有关。我大部分时间都花在我们的产品积压和每个冲刺的积压上。不断的和德方讨论需求，和团队提炼需求，然后紧张的把功能分优先级和各种人讨论，然后放到对应的sprintbacklog上。.. 前一两次冲刺，其实整体还是不错的，燃尽图也不算太难看。但是这样做之后，曲线开始越来越高，离理想的曲线越来越远。最后不得不从原计划的7个冲刺调整为10个冲刺。 后来仔细反思了这个问题。我认为有几个原因，但最重要的一个是“技术债”没有及时清理。 其实这个原理看起来很简单。基本上，经历过敏捷开发的人都知道技术债给项目带来的危害。但在真正的项目开始时，我们往往因为时间匆忙而匆忙实现新功能，而忽略了代码的可扩展性和健壮性等，最后这些“技术债”越来越累，变得越来越累后面越来越难去掉尾巴，修改一个地方可能会影响到全身。 看似只和程序员有关，其实不然。这跟产品经理的概念更相关。像我之前，只想让团队快速完成产品backlog中的功能，却没有花足够的时间去思考产品表层下的东西，也没有关注实施的质量。如果把一个产品比作一座建筑，那么我觉得功能就是客户看到的地面以上的部分，而质量就是地基隐藏在地下的部分。也许你现在看到的房子，外观富丽堂皇，功能齐全，连厕所都是自动化的，但一旦遇到大风大雨，或者你要加一层、两层，整栋楼可能马上就倒塌了。 所谓欲速则不达，产品经理不能只盯着特性列表，更要花更多的时间在解决“技术债”等事情上。 用户体验 相信没有一个产品经理会忽视用户体验的重要性。当用户购买你的产品/软件时，他们真正购买的是解决他们痛点的方案。如果在用了你的产品之后，原来的痛点解决了，但是用户体验差变成了他们新的痛点，那么用不了多久用户就会逃离。 根据我之前做产品经理的经历和后来在创业公司的经历，我发现我们在用户体验上容易犯的错误主要有以下几点： 把自己当成用户：这个很容易发生在创业公司，因为公司自身经验不足，产品经理过于自信，也因为创业初期目标客户与项目没有关联（其实在Scrum中,非常强调用户参与)),所以当一个sprint下来开始一个demo的时候，demo的目标往往是项目中的同一群人。产品经理在考虑下一个冲刺的用户体验时，常常觉得自己可以像周鸿祎一样瞬间变成小白。就这样一次又一次，冲刺几次后，产品拿出来试水，发现什么都没有，结果就是再无结果。 这个错误也可以称为敏捷团队中的“小瀑布”错误，这是没有让用户过早参与的结果。看似在跑Scrum，实际上是把原来的瀑布模式分解成几个小的瀑布，然后套用Scrum的概念，名副其实。 忽视用户体验：其实用户是很没有耐心的，尤其是互联网产品用户。你的产品可能很强大，UI呈现也很逼真，但是用户要花很多时间，甚至读你几十页的用户手册才能弄明白怎么用你的产品来解决他们的痛点，并最终找到解决他们痛点的功能埋在三级菜单或以下，所以你期望他们爱上你的产品吗？ 解决这些问题我觉得也很简单： 让用户尽早参与：比如我们做创业公司的时候就是因为做一个适合个人的私有云产品和小企业，所以我们去附近的一所大学找了一些学生过来试用，给他们做一个演示，然后收集反馈。他们试玩的过程中，必须要有专人跟踪记录，记录者不能给对方任何暗示。当然，***别忘了给学生一些报酬。当时我们给学生发了100元左右的话费充值卡。 竞品研究：除非你做的产品非常具有开创性，行业内没有同类产品，否则你绝对可以在国内外找到一些功能相似的产品。在这里你可能会说抄袭是可耻的。且听传奇史玉柱是怎么说的：“抄袭不仅要厚脸皮，更要开发优化，你复制超越对方，别人就不会说你抄袭了。”所以作为产品经理，你经常要做的就是不断研究别人的产品，而不是只盯着产品积压，这不仅仅是用户的问题，上面的经验还包括其他功能点的调整，因为现在信息瞬息万变，这一点下面会详细说明。 支持销售团队 这里就得从我们当时搭建的另一个二手房房屋管理系统说起，目前，二手房中介广泛使用的房xxx等商品房管理软件，会将自己的房源数据上传到软件商自己的数据中心。而房源信息其实是中介的命脉，所以他们希望这些数据中心会放在他们自己的公司，所以我们当时做的是提供一个数据中心服务器和一套相应的物业管理软件，管理软件支持PC端和移动端LS。 MVP出来后，我就开始去各个二手房中介demo，搜集更多的资料。问题来了，上面说了，用户是没有耐心的，不管你说的是炒作还是眼见为实。但是，设置整个服务器仍然需要花费大量时间。其他人需要为您腾出空间并提供网络访问权限。比较尴尬的是，因为这还是一个很早的产品，在你们公司跑的时候一般都是正常的。你在别人的环境里跑来跑去，不是有问题就是有问题。最后，很多客户因为忙而中断了演示。 其实第一次demo完全没必要搭建整个环境。你可以在数据控制层下嫁接一个服务器模拟器，这样你的数据就不用通过网络和数据中心交互了。这样做之后，销售人员去演示的时候，只需要给对方看一下服务器的外观，就可以直接在电脑上安装软件进行演示，不需要连接服务器。该过程只需要通过网络向对方展示数据实际存储在数据中心，只是为了方便demo，暂时存储在本地。 所以这里产品经理不仅要考虑产品的真实性，还要考虑如何方便销售团队在外面进行演示，尤其是产品在前期得到用户反馈的时候。否则，如果没有足够的用户反馈做支撑，最终还是会走回闭门造车的老路。 不要假设架构师或项目经理会帮你考虑销售团队遇到的困难。这个产品就是你的（其实在Scrum中，产品经理的名字叫ProductOwner，就是产品负责人）。经理和架构师等团队成员只负责在预期的时间范围内实施您交给他们的产品待办事项。 竞品分析 上面讲用户体验的时候提到过这个。产品经理应该时刻关注市场的动态和竞品的动向。比如我们开始做的云产品就犯了这样的错误。一开始，市场上很难找到竞争对手，战线??开始拉得太长。某天，突然冒出一则新闻，“百度云最大容量1T，率先进入云空间T时代”，我们的心已经凉了半截。 当然，其实当时我们的产品没有上市的原因是复杂的，但毫无疑问，其中一个不可忽视的原因是对市场动态的分析和把握不够，竞争产品。 所以作为产品经理，一定要时时刻刻关注各个方向，倾听各个方向。可能出现了竞品新版本的新特性，你需要立即有针对性地调整产品实施策略。 你要知道，一个产品经理不仅要知道如何不断地为产品backlog增加新的功能，更重要的是，你应该知道如何不断地为公司增加新的附加值。 除了上面提到的几点，其实我在做产品经理的时候觉得还有很多值得优化的地方，比如把握功能点的优先级，功能点的优化，产品扩展性的把控，团队合作.与项目经理的互动、配合等，但是限于篇幅和时间，暂时就说这么多，以后可能会在另外的章节继续细说。当然，也希望大家在评论中发表自己的看法。
