[3]_人人都是产品经理

末蓝、 2024-05-28 10:21 65阅读 0赞

## \[3\]\_人人都是产品经理 ##

### 从《人人都是产品经理》这本书认识产品经理 ###

最早接触“产品经理”这个词，是在工作的第二个年头，当时所在公司很小，1个程序员+1个美工+半个网管，项目基本都是按照销售或者美工决定，大致搞搞就上线，而老板就是我之前提到的，完全放手型。当时折腾了很长时间，都是在忙碌又杂乱的日子中渡日子，大半年改版了3次，现在想来，基本上都是领导拍脑袋的结果。在这混乱之后，我们当时的COO（从500强挖过来的快消品品牌经理）引进了“产品经理”一词，我记得当时花钱买了3～4本《人人都是产品经理》，从那开始，我才知道，哦，其实有个产品经理很重要。而在后面的工作中也证实了一名优秀的产品经理，非常有利于产品的良性发展。  
在我观念里，产品经理这个角色的定义应为：

**根据市场规律与用户需求，设计出符合用户习惯，并能帮助用户解决问题的新事物，同时能够协调整合各部门，并跟踪项目进展，且对未来能够有把控的人。**

通过上面的定义，就引申出产品经理的职责范围至少包括以下几个方面：  
1. 根据市场情况，制定出符合市场规律的产品。  
2. 制作产品原型图，了解现阶段的用户习惯，使产品具有良好的用户体验。  
3. 协调各部门，如市场部、技术部、UI部等，需起到协调作用。  
4. 产品的短期计划与长期规划。  
5. 对产品质量的把控，尤其是在验收阶段，一定要保证质量。  
6. 需要良好的理解能力，能够将需求方（此处往往是高层 OR Boss）的语言，转化成产品描述语言，以方便与其他部门沟通。

产品经理，这个职业在互联网行业其实出现不久，也没有形成专门的学科，成为产品经理的渠道相对集中，通过我之前接触过的产品经理来看，主要是由这么几种类型：  
1. 技术转做产品经理  
很多技术人员在后期，会转做产品经理，这种类型的产品经理，我接触过几个，技术人员转做产品经理，往往还带着很浓烈的研发味道，虽然这类产品经理不觉得有影响，但是在做产品规划的时候，时不时的会思考实现逻辑，从而导致在思考功能的时候有一定的局限性，但是逻辑性相对较强。此类产品经理特点：  
逻辑性：★★★★★ 沟通性：★★★☆☆ 用户体验：★★★☆☆ 市场敏锐：★★★☆☆  
2. 美工转做产品经理  
美工转做产品经理的情况，也是比较多，我之前公司就有这样的情况。给我的感觉，这类产品经理相对会比较注重产品本身的美感，而在逻辑性上而言，会有一定的缺失，而沟通能力方面和技术人员差不多：  
逻辑性：★★★☆☆ 沟通性：★★★☆☆ 用户体验：★★★★★ 市场敏锐：★★★☆☆  
3. 其他职位转做产品经理  
此类的情况相对复杂，我之前有见过项目经理转做产品经理的，也有部分在外包公司负责业务需求人员，纷纷转为产品经理，此类情况还需要各个分析。  
4. 纯产品经理  
随着产品经理这个角色越来越被一些公司认可，也导致一些毕业生从开始就从事产品经理角色，其实这个有一定的弊端，很容易变成空洞的理论知识，既没有技术人员出身的强逻辑，也没有美工人员的美感，很容易流入“天下一大抄，不抄白不抄”的状态，此类的产品经理特点如下：  
逻辑性：★★★☆☆ 沟通性：★★★★☆ 用户体验：★★★★☆ 市场敏锐：★★☆☆☆  
5. 产品经理是老板  
相信很多朋友在公司里面经常听到老板说“我才是最大的产品经理”。这个要分情况看这个问题，假如专科出身的，而且之前有产品经理的相关经验的情况，的确是能够成为出色的大产品经理。但是很可惜这种情况太少，尤其在传统行业，也多时候那些所谓最大的产品经理，只关心产品的长相和市场效应。所以绝大多数此类的产品经理不算是产品经理，只能算企业内部产品需求方。  
逻辑性：★☆☆☆☆ 沟通性：★★★★☆ 用户体验：★★☆☆☆ 市场敏锐：★★★★★

不同出身的产品经理，也就决定他的技能强弱，间接的也就影响着担当的职责了，不过，本人认为这些都可以在后期中补全技能，下面会针对性的提一些提升意见。

### 从《神一样的产品经理：基于移动与互联网产品实践》聊起移动应用 ###

关于产品经理相关的书籍和资料，现在互联网上也是非常之多，此处就不多碎语，就聊聊现在比较火的移动应用，这本《神一样的产品经理：基于移动与互联网产品实践》没仔细看完，粗略了看了下目录，其实这本书不太合适我看，里面很多知识点其实有点囫囵吞枣的味道，而真正说道移动互联网的核心产品定位少了些，当然既然做个引子，我就继续说些移动应用的特点：  
1. 移动应用体积小，操作空间小。绝大多数的手机都是在6寸以下，这导致移动应用相对能展示的内容少，所以不太可能像PC端那样将什么内容都一股脑儿的都扔进去，最佳的实践方法是将用户常用并且能够在移动端实现的功能放到手机上。  
2. 移动设备上具有操作性简单的特点。基本上都是由输入+触摸完成操作，而很多时候用户又喜欢使用触摸的方式选择，所以在设计功能的时候要符合用户的一些操作习惯。  
3. 符合现在的玩法。PC上的Web开发相对较成熟了，一些常见的处理方式也耳熟能详了，但是在手机端，很多的操作习惯和玩法还在探寻中，而最好的处理手段就是在某些功能上，模仿一下大家都熟悉的软件做法。如聊天，QQ或者微信的模式很值得借鉴。  
4. 使用场景的变化。传统方式，尤其是台式机基本上都是固定在某个地方去使用软件或者上网冲浪，但是移动应用经常会变化场景，这样也容易导致朋友与朋友之间直接共享的便捷。  
5. 网络的不稳定。这个因为在国内高速网还没完全普及，即使用4G,也还存在费用较高的情况，所以我们在设计移动应用的时候也需要为用户考虑如何能够快速的获取内容。

上面的几点主要是说移动应用与传统应用的不同之处，其它的一些遵从原则，可以从此本书上获取，或者多看一些相关文章多做了解。

### 他们家的产品 ###

他们家的产品，这个其实就像我们小时候经常被大人说的，你看看，他们家小孩多么多么聪明，他们家楼盖的多么气派，他们家那个XXX多么OOO，好吧，为什么受伤的总是自己。为什么到现在还没出一款好产品，看看他们家的产品。  
他们家的产品：  
腾讯的微信  
网易的新闻  
秀秀的美拍  
google的Youtube  
…

这几年涌现出一批优秀的移动应用，用户数量级也从原来的百万级，开始迈入千万级，甚至亿级。当然这些产品的出现，都是为了解决实际问题的，游戏不是？其实游戏解决了很多人的虚荣心和空闲期，这个问题有时间再去做探讨，游戏从某种角度还是造就了世界和平，你想如果非洲年轻小伙给他们有条件玩游戏，我估计非洲也会太平很多。

虽然产品很多，但是现在真正优秀的产品却屈指可数，很多都是人云亦云的抄袭和伪创新，模式其实抄袭很正常，最怕没有自己思想了，千万别认为他们家的XXX都很OOO，其实合适自己的最合适，当然经常去看看他们家的产品，有利于快速原型。  
扔个专门做app世界排名的网站（我估计绝大多数人都知道）：

[App Annie][]

### 看看，了解些营销知识也很重要 ###

营销知识的重要性，不仅仅在其他行业，在一款新产品上线后，配合恰当的营销方案，也会让产品锦上添花。如最早期做廉价智能手机的小辣椒、佳域等，经常搞饥饿营销，名气出去了，销量也出去了。还有XXX视，经常会发布一些概念性产品，把本来一款很普通的产品包装成了高大尚。诸如此类的营销方案太多了，多的让小米自己都忍不住出了一本书叫《参与感》，个人觉得“品牌”和“新媒体”两块的东西很值得研究一下。  
那么，作为产品经理适当的了解下营销知识，与市场推广的同事沟通，在不影响用户体验的前提下，融入一些切合市场营销的策略，更有利于产品的推广。

### 你得知道如何监测你的产品 ###

在产品上线之前，作为产品经理，应该要规划好一些数据收集的方案，以下就举一些数据：  
1. 访问统计数据，如注册量、访客量、访客趋势等。这些都是最直观的反应款产品受欢迎程度的数据。在pc端，我们可以利用第三方工具，如百度统计、51统计、Google统计。在App端，我们有友盟、百度移动统计、cnzz移动统计等。也有一些收费的统计工具，如果没有更高定制化要求的情况下，选择免费工具基本够用了。当然，现在也有很多公司自己收集数据，通过云计算进行访客数据分析。  
2. 业务数据分析，除了上面的指标外，业务数据的分析，可以用来验证商业模式，以及业务相关的策略方针的正确性，此处如客单价、访客转化率、购买重复率等。  
3. 效果统计，此类情况主要针对新旧版情景之下，通过一定时间的新旧数据对比（一般为一个月），来对应用的效果进行评估。  
4. 用户反馈，feed back永远是对用户的尊重。通过用户的直观反馈，会让你及时发现一些问题，以及用户的需求。  
5. 各大商店评价，这个也是借助第三方的评价系统，经常去看看下载量较大的移动应用商店，看看用户是如何评价的，会有利改善我们的产品。  
6. 当然朋友也是很好的反馈渠道。

基本上通过上面6个方式，很快你就知道你的产品是什么样了。

### 产品经理还得知道的一些工具 ###

![产品经理的工具][da29_edf3_pmsoft02.gif]  
至于用什么工具，就我本人而言，之前用的最多的就是Axure PR,因为使用的操作系统不一样，Window和Mac下的产品经理在做原型图的时候还是有些许差异。  
根据上面说到的产品经理的职责，工具对应的解决这些问题：  
1. 编写PRD文档、BRD文档等等，一般Office的一套足够，在讲解的时候适当加一些图表即可。  
2. 项目管理，说实话，我接触的产品经理基本没谁负责，基本还是我们研发来负责，所以项目管理的软件，作为研发就如数家珍了，重量级的jira、redmine、禅道、Excel，还有一些在线的协作平台，如明道等，这块我的经验用什么软件是次要的，主要是需要养成使用的习惯。  
3. 流程类工具，Visio、亿图、思维导图等等。  
4. 原型类工具，AxurePR（Mac & Window都有），Sketch（Mac用的比较多）。还有一些在线的，这一层软件也很多，找款自己看了顺眼的就差不多了。  
5. 测试工具，Firefox(FireBug + Yslow)足以。  
6. 交流工具，我觉得发邮件+靠嘴反复沟通即可。

差不多就这些了，这块其实网上有很多整理好的，非常不错的文章，我就不再罗嗦了，直接贴几个链接，有兴趣的可以自行查看：

线框图与原型图的区别：[http://www.uisdc.com/wireframes-vs-prototypes-difference][http_www.uisdc.com_wireframes-vs-prototypes-difference]  
常见产品经理工具介绍：[http://blog.csdn.net/c504665913/article/details/8013910][http_blog.csdn.net_c504665913_article_details_8013910]  
人人都是产品经理：[http://www.woshipm.com/][http_www.woshipm.com]  
百度出的一款在线脑图：[http://naotu.baidu.com/][http_naotu.baidu.com]

### 技术产品为什么总相处不好？ ###

好吧，最后再聊个比较八卦的问题，经常在网上看到产品经理和技术人员之间争吵的情况，还好从业这么多年，我很少遇到这种情况，在此非常感谢与我和平相处的产品经理们：）。  
这个问题，我觉得因为一下原因造成的：  
1. 产品经理逻辑性不强的情况，所以很多时候给到技术的是无逻辑或者逻辑不全的描述，这样逻辑严谨的程序员们需要费事帮忙去理逻辑。  
2. 产品经理不懂技术的情况，这点就导致很多产品经理觉得实现起来很简单，同时给技术人员的反馈就是“这么简单的东西，你肯定容易搞定啦”，这时候技术人员很反感。  
3. 产品经理强势的情况，有些产品经理会很理直气壮的说，这个东西我一定要这样那样，会让本来就很抵触的开发人员更加的怨恨产品经理。  
4. 技术人员遇到需求不明确的情况，这个做开发的都挺反感的。

当然还有很多奇葩的情况，也会导致技术产品矛盾重重，轻者影响进度，重则影响公司发展，结合上面的原因，我说说如何来处理两者关系吧：  
1. 回到本文提出的第一点，人人都是产品经理。我觉得和产品沟通的时候，如果你也是懂产品的产品经理，沟通起来你会发觉很顺畅。我记得去年做多店铺的时候，产品经理对产品属性什么的也是一知半解，当时我就抽空了解了下淘宝如何玩产品属性的，之后再给他做讲解，这样的沟通方式，很显然就顺畅很多。  
2. 与人方便，在产品的探讨及研发过程中，进行耐心的探讨，同时能够给对方提出专业性建议，帮助一起解决遇到的问题，很容易就统一思想了，自然而然就化解了矛盾。  
3. 同甘共苦，在早期没有产品经理的时候，很多时候是技术负责人和老板或者高层打交道，经常会遇到需求不明确的情况，有了产品经理后，此类反复沟通的事情，在产品经理那一层做了过滤和缓冲，对项目的进展也有帮助，所以从某种程度而言，还的感谢产品经理给我们喘息时间，同甘共苦也是需要的。  
4. 主动沟通，经常会有这样的场景，东西完工后，产品经理说这个东西不是我想要的，究其原因是产品经理没说明白呢？还是技术人员没弄明白？所以当遇到问题的时候，要及时沟通，以免造成后期的返工。  
5. 适当Team build，团队建设不仅仅是本部门的，跨部门的沟通也非常有利于项目的进展，在之前的公司我就经常会和市场部门和销售部门的同事一起吃饭，沟通。

上面的方法基本是我亲身经历的，当然每个人由于性格以及环境不一样，可以选择性使用。但归根到底，先学会尊重别人，也很快得到对方的尊重。

### 产品打造，路漫漫其修远兮！ ###

一款好的产品需要打磨的时间很长：  
1. 微信2011年开始，有4年多时间…  
2. 嘀嘀打车、快的打车2012年开发，有3年多时间…  
还有很多成功了的，和未成功还在努力的产品，路漫漫，还需要慢慢打磨…

[App Annie]: https://www.appannie.com/apps/google-play/top/united-states/
[da29_edf3_pmsoft02.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/28/183dea81f8ab4610b9fe408b84c1d30d.gif
[http_www.uisdc.com_wireframes-vs-prototypes-difference]: http://www.uisdc.com/wireframes-vs-prototypes-difference
[http_blog.csdn.net_c504665913_article_details_8013910]: http://blog.csdn.net/c504665913/article/details/8013910
[http_www.woshipm.com]: http://www.woshipm.com/
[http_naotu.baidu.com]: http://naotu.baidu.com/