您的位置：
大话产品经理：真的 “人人都是产品经理” 吗?
作者：ux@me
　　&产品经理&, 一个重未被真正定义的争议角色. 他有时是模糊的, 有时却又清晰无比. 有时他是产品的缔造者, 但更多时候他却是开发和设计人员眼中的公敌.
　　很早以前就想抽时间来写一篇文章, 说说我对 &产品经理& 这个角色的想法. 后来一直因为时间关系没有动笔. 再后来自己也懒得动笔了. 再后来, 随着我遇见过的产品经理越来越多, 加上自己也亲自做了一年多产品经理, 从不同角度再次认识了这个职位. 今天, 我想把这些经历分享出来, 聊一聊产品经理.
　　因为没有清晰定义其职责范围, 所以在下文中我提到的 &产品经理& 将会是很宽泛的概念. 我会尽量以目前业界的事实标准来界定产品经理的职责范围并进行讨论.
　　一. 我了解的产品经理们
　　1. 新蛋产品经理: 分而治之
　　第一次接触到这个职位, 是在新蛋做对美业务时. 所有的需求文档都是美国直接发过来. 写需求文档的被称为 &BSA&, 意即 &商业系统分析&. BSA 会将详尽的需求文档发到项目参与人员手上, 然后进行电话沟通, 传达项目的背景与商业目标. 确定大家没有问题之后, 就会开始项目排期, 进入到开发阶段.
　　对于稍大型的项目, 还会有 &BSD&(商业系统开发) 参与, 负责所有技术资源的调动. 有的项目里 BSD 还会参与 coding, 负责技术方案, 架构和底层实现等. 下面的开发人员会根据 BSA 的需求和 BSD 的方案进行开发, 直至提交测试和最终上线.
　　大体上在新蛋 &产品经理& 的职责是由 BSA 与 BSD 两个职位来分担的. 前者负责需求, 后者负责实现. 而一个小项目往往从属于更大的项目, 因此 BSA 实际负责的会更多. 项目进度的把控也是由两个角色共同负责. 一般来讲, BSD 会负责掐住开发时间, BSA 则负责整体进度.
　　与其它公司不同的是, 除 BSA 提出需求之外, 还有另一个被称为 &WM& 的团队专门负责提出和验证需求, 并交由他们选定的 BSA / BSD 去执行.
　　值得一提的是, 新蛋的 BSA 与 BSD 都相当专业. 我接触过的几位 BSA 都会和我详尽沟通需求, 对问题尽其可能解答. 那时候 BSA 通常选择在电话里直接沟通需求背景, 而在文档中则详尽描述需求对应的每个功能点. 对每个功能都配上 UI 界面与交互流程. 后来我在阿里时, 一位同事拿他的 Axure 给我解释什么叫 &高保真 PRD&, 看着他那图多字少, 流程混乱的文档, 我只能蛋蛋一笑.
　　BSD 也不是虚职. 我遇见的 BSD 都有极强的代码功底, 他们本身往往就是项目的技术架构师, 在项目里负责根据情况调整技术方案, 协调技术资源和与进度把控等工作, 类似其它公司的架构师 + PM.
　　要注意的是, 新蛋的 BSA 们似乎没有涉及到与运营相关的工作. BSD 们更不会涉及. 这块工作通常交由 Marketing 部门去做. 当然也有可能 BSA 们会做运营相关工作, 只是做为底层开发人员的我并不知晓
　　2. 阿里巴巴产品经理: 大包揽
　　后来我来到了阿里巴巴 B2B. 在这里真正零距离与传说中的 &产品经理&, 阿里称之为 &PD&(Product Director/Designer)一起工作.
　　在阿里巴巴, 一个合格的 PD 首先必须是成功的 saler . 阿里内部有 &打鸡血& 的传统, 每次做项目, Kickoff 都恨不得能办成晚会. 做为项目发起者的 PD, 必须有良好的 &忽悠& 功底. 当然, 我说的 &忽悠& 是褒义词. 因为在大公司, 特别像阿里这样的巨型航母里, 不见得每个项目都有意义, 做了都能看到实际的成效. 怎么调动项目参与人员的极积性, 让他们认为自己手上的项目是最逼的? 这必须要求 PD 会说, 有些时候还要善于画大饼.
　　除此之外, 阿里的 PD 们相更贴近用户, 更加 &草根&. 由于公司的轮岗制度, 大多 PD 以前做过运营甚至客服, 在这些一线职位摸爬滚打几年后, 对公司的用户群体会有更深入和直白的理解.
　　其次, 阿里的 PD 还必须是团队的 CEO . 从产生想法, 需求调研, 到 PK 项目资源, 向项目组传达需求和目标, 再到 kickoff, 进度跟踪, 随时根据情况迭代需求, 再到安排测试 case, 验收功能, 产品上线, 直至产品运营推广, 数据分析, 用户反馈和版本功能迭代等, 都由 PD 一人负责. 并且 PD 还要为产品的表现背最大的 KPI 指标. 所以好的 PD 必须是好的 CEO, 上窜下跳, 费尽口舌为项目做好三件事: 找方向, 找人, 找资源.
　　当然, 做的事多了, 就很难精通某个方面. 所以我合作过的 PD, 大都会遇见以下问题:
　　MRD, PRD 不清晰. 特别是 PRD, 由于产品需求经常一变再变, 甚至到了开发阶段仍然状况不断. 加上项目时间永远不够(有趣的是, 我从没有参与过时间充足的项目, 每个项目都号称时间紧迫资源紧张)因此很多时候 PRD 成了一纸空文, PD 不会持续更新, 就算写也只是草图画画. 到最后各种需求变成了口头交流.
　　流程进度把控能力较弱. 我做项目时就常遇见为赶 deadline 或初期没想清楚中途再改需求导致增/砍功能的情况. 常常搞得 UED / 开发团队一片怨声.
　　PD 大多不了解(广泛意义上的)技术却又自持理解用户. 这是个很大的问题, 常常导致 PD 想做的东西开发人员并不真正理解, 而开发的问题又很难被 PD 真正重视. 长期以往, PD 与开发产生了各种互不信任.
　　但即使有各种问题, 公平的说阿里的 PD 们还是具备强大的专业能力与敬业精神. 特别是在用数据说话这方面, 我遇见过多位强大的 PD. 但我的映像是, 阿里的 PD 们总是缺乏一些互联网 sense. 当然, 一家之言.
　　3. 创业团队产品经理: 铁人汉堡
　　离开阿里后, 我加入了一家创业公司. 在那里我的身份由开发人员转变为了团队管理和产品经理. 和老大谈职位时, 做为 UEDer 我聊了很多对产品设计的空想. 于是老大让我负责这块东西. 就这么着我开始了产品经理的生涯. 前后一年多时间, 做出了一个移动端产品. 这次亲身体验, 让我有了机会从另一个角度看待产品经理.
　　在创业团队里, 要求每个成员都能够 &一专多能& . 如果说阿里的 PD 是 CEO, 那创业公司的产品经理无疑是 CEO 中的铁人. 在事情的每个环节上, 都要求产品经理想得更清楚更加深入. 因为这时候产品经理背的不再是 KPI, 而是公司的方向, 甚至是公司这么多兄弟的饭碗(这么说一点也不夸张. 虽然有的公司老大很强势, 但也需要下面一帮产品经理帮着去实现他的想法). 这时的心理压力和所处环境与大公司做项目是不一样的. 事情变得极其琐碎, 需要搞定内(老板, 开发人员)外(商业, 渠道, 媒体等)各种事情. 至于客串 HR 招人, 清洁员工打扫卫生那更是便饭.
　　在创业初期, 基本没有自己的休息时间. 产品开发时我跟着开发一起加班, 连续一个月凌晨两三点回家. 产品刚上线时又常在周末被电话叫起来看数据. 所以那个时候, 我真的成了铁人.
　　同时, 创业公司的产品经理又是 &汉堡&. 为什么呢? 因为产品经理常常被夹在老板与开发人员之间 . 老板看到的方向, 想做的事, 由产品经理负责转化为产品功能. 另一方面对于 UED, 开发等团队而言, 因为信息不对称常常不理解为什么要做这样的功能? 所以产品经理需要不断与团队成员沟通, 分享数据, 解释问题. 但要命的是, 一方面产品经理们没那么多精力, 另一方面并不是所有需求都能事前想通, 事情总在不断变化. 所以产品经理的想法经常修改, 难以执行下去. 久而久之, 产品经理成了大家的出气筒. 老板认为产品经理执行力不强, 而开发们则总认为产品经理没有想清楚, 不想投入太多资源和精力. 这是我在一年多的创业里所体会看到的.
　　二. 真的 &人人都是产品经理& 吗?
　　每个职位都有几本人人推崇, 称之为 &必读& 的入门书籍. 做前端的有 O&reilly《xxx 权威指南》动物书系列, 交互有 Alan 写的《交互设计之路》或《Don&s make me think》. 而对于产品经理, 放眼望去最具人气的应该是《人人都是产品经理》了吧. 可惜的是, 前几本书都经受了时间的考验,确为经典. 而后者近来却质疑不断.
　　当然, 首先声明我这里并非要讨论这本书 . 因为我没有完整读完它, 仅仅看过一些片断, 在阿里内网里看过作者的一些东西. 这里只是想说说它的书名: 人人都是产品经理.
　　真的吗?
　　其实我十分理解作者取这个名字的用意. 但这个名字就如同魔盒, 一旦开启便失去了控制. 特别是对那些和我一样没有读过本书的人. 它似乎在告诉大家, &产品经理& 没什么了不起的, 人人都可以做. 就像滥大街的 &客户经理&, &销售经理& 一样. 但产品经理门槛真的这么低, 这么好做以至于刚毕业没任何经验的大学生也敢来应聘这个职位?
　　其实通过上面我所描述遇见过的产品经理们可以发现, 和任何职位一样, 想真正做好产品经理并不轻松. 很多时候甚至是痛苦.
　　《人人都是产品经理》告诉人们拥有哪些特质就可以成为产品经理, 而我则要列出一些点告诉你缺乏了这些不能够成为产品经理.
　　缺乏抗压能力.
　　如同上面谈到的, 虽然产品经理在不同的公司团队职责不一, 但都背负着极重要的责任. 对于大公司而言, 你的眼光和思考决定了项目组一票兄弟 KPI 是否过关, 大家忙活了几个月能否看到实际的功效反馈, 是否让大家觉得在做的事情是有意义的 .
　　而对于小公司或创业公司而言, 产品经理认定的方向更有可能关系着大家伙吃饭的问题, 马虎不得.
　　除这些职责之外, 你还得做好准备随时被老大叫到办公室臭骂一顿, 亦或者每天被设计, 开发同事呼来唤去, 还得两边陪着笑脸, 一定不能崩溃掉. 在前期过需求讨论时, 请随时做好接受众人从不同角度的全方位 &拍砖&, 直到你觉得自己做互联网这一行就是个错误为止. 当然并不是说不该拍砖, 我只是把这些真实的日常会发生的常景说出来, 给没有任何经验的同学一个参考.
　　另一个压力来自于高层想像出来的 &需求&. 往往这些东西被称为 &行政任务&, 虽然和自己的理念不合, 但抗争无效后还是只能强加在当前版本里. 这等于是把压力推给了下面的开发同学, 搞得开发不配合, 老大又不停催促. 只能让自己夹在中间, 两边受气.
　　所以, 做产品经理, 请做好准备担责任, 受委屈, 背黑锅 .
　　不能接受工作时间碎片化.
　　刚工作的朋友可能对这条不是很理解. 但有经验的朋友都知道, 当我们集中精力认真投入一件事时, 不仅效率非常高, 心情也会十分愉悦. 但如果你选择成为产品经理, 那就请和这种状态说 bye bye 吧.
　　产品经理的时间被分割得极碎.通常一天的工作时间都会在不同的需求会议, review 会议, 头脑风暴会议, 数据分析会议等等各种大小会中渡过. 真正写 PRD 画产品原型的时间, 往往只有等到下班后自己补上. 特别是在创业公司, 好不容易坐下来理清思路开始写文档画原型, 老大一个电话叫到办公室, 聊上几小时, 出来后发现不仅文档不用写了, 整个项目都可能暂停重来.
　　所以, 做产品经理, 请做好准备随时变化/被变化, 和 &专注& 说再见, 多线程运作起来 .
　　没有一线工作经验.
　　个人觉得这是最忌讳的一点. 如果没有任何一线工作经验, 请从基层做起, 产品经理并不是捷径. 前些日子我总在思考什么样的人才适合做产品经理, 有很多感悟. 其中最重要的一条, 如果一个人没有积累大量的基层工作经验, 那么是无法胜任产品经理职位的.
　　因为从专业性上来说, 产品经理要求必须打通横向技能, 对 UED(用户心理/体验, 交互设计, 视觉表达等), 开发(实现的边界在哪里, 怎么合理安排资源), 运营推广(产品外部环境, 渠道, 成本), 内容(产品气质, 玩法, 功能), 数据(指标) 等几大模块都要有相当深入的了解, 进而形成自己的见解.
　　从产品上来说, 只有当产品经理对上述各模块融会贯通有机吸收后, 才能够做出真正贴合用户需求, 甚至如乔帮主般产生用户需求 的东西. 才能够合理设计产品功能和规则 . 才能够知道在什么时候应该坚持什么, 放弃什么 .
　　而要做到这点, 需要花费大量时间精力去研究每个模块. 这并不是简单读几本书, 说几个专业名词, 或者扒几句别人的 blog 就可以的, 这需要学习和积累, 漫长的学习和积累 . 但眼下整个行业却弥漫着浮噪, 我们一边标榜着乔帮主信徒, 一边肆意抄袭. 各种粗放的产品应接不暇. 产品经理们活在自己的世界里考虑各种用户需求和场景, 唯独忘了想想用户真的要什么.
　　在知乎上看到有人问 &产品经理(尤其是创业的)需要懂技术吗?懂到什么程度?&, 感觉挺杯具的. 提这种问题, 是没有真正认识 &产品经理& 的人. 做产品, 就好像手工艺人打造玉器, 或农民耕种土地. 如果对 &石& 或 &土地& 不了解, 看再多教科书也无法烧出温润的玉品, 耕出成片的麦浪. 看看缔造出我们身边真正可以称之为 &成功& 的互联网产品的人们, 谁不是从最基层做出来的? 马云从销售做起, 挨家挨户做推广开启了阿里巴巴; 李彦宏, 马化腾, 张小龙自己就是技术出生; 现在的 &反流氓大王& 360 当年不也是从流氓开始做起来的吗?
　　所以, 做产品经理, 请做好准备摆正心态, 不停学习, 先做专家再做大师, 切忌浮噪 .
　　不了解自己的用户 .
　　这点是接着上面的话再讨论. 由于缺乏一线工作经验, 不清楚自己的用户在哪里(对于开发而言, 技术就是他们的 &用户&), 不了解他们是怎么样一群人, 有着什么样的生活习惯, 价值观和追求, 常以虚拟的 &用主角色& 聊以自慰. 或者潜意识里把自己当成了典型用户. 这样设计出来的产品也难怪表面好看, 实际打不中用户的需求点.
　　还有另一种产品经理, 几乎从来不用自己的产品. 下班回家就和产品脱了节. 这样的产品要么太高端, 和衣食住行这样的平凡生活不搭勾, 要么就是产品经理自己都不愿意当产品的重度用户. 这样做一是发现不了产品有哪些毛病, 二是是将最后一条了解用户的路给堵死了. 我在这点上走过很多弯路. 在阿里和创业公司时都犯了这样的错误, 即把自己当成典型用户来设计产品, 又不愿多投入精力来用自己做出的东西. 到最后才发现, 我不用, 也没有其它人会用.
　　所以, 做产品经理, 请做好准备成为自己产品的头号重度用户, 在不同的地点时间场景下, 使用它 .
　　缺乏必须的沟通能力 .
　　沟通能力分为口头表达与书面表达. 口头表达, 要求产品经理能够条理清晰的阐述产品意图和思路, 能够给老大或开发讲清楚用户的需求和对应的功能点之间的关联.
　　书面表达则需要产品经理能将脑里的产品蓝图化为文档, 原型, 流程图等一一展示出来.
　　除此之外, 做为项目组 &CEO&, 你还得随时关注项目成员们的工作状态和情绪, 有什么不满的地方, 必须及时与他沟通. 一般跨度稍长或压力特别大的项目, 随着时间推移大家都会滋生出各种负面情绪. 这时候仍然需要你不断沟通来鼓舞士气.
　　所以, 做产品经理, 请做好准备练习保姆心态与三寸之舌, 通过沟通不断 push 大家前进 .
　　想走上产品经理这条路的人们, 能停下来问问自己这五个 &准备& 有做好吗?
　　三. 产品经理: 我的反思
　　知乎上曾经有一篇神贴: 《豆瓣的产品经理面试题, 你能做出来么? 》(现在已被锁贴了), 相信很多人都看过. 贴子的回复里很多人都在对产品经理这个职位做反思. 有人问, 中国互联网已经发展到了需要职业产品经理的阶段了吗? 你看看当年的 QQ, 阿里巴巴, 百度, 哪一个是 &产品经理& 做出来的?
　　话是不错, 但眼光未免稍显狭隘, 忽略了当时与现在的环境差别. 暂且不论国内互联的发展阶段, 看看现实就知道, 产品经理职位确不可缺.
　　产品经理扮演着将不专业甚至不懂行的老板的想法转化成产品的角色(以及质疑推翻这些不合理的需求的角色). 所以老板们需要他. 有了产品经理, 老板们可以放开手来做更专业的事: 找方向, 找人, 找资源.
　　产品经理扮演着 &保姆& 的角色. 给团队打鸡血讲需求, 找成员聊天谈心画大饼, 为大家订饭搞活动. 同时产品经理也 &解放& 了很多技术人员, 可以让他们远离碎片化需求的干扰.
　　但不得不承认, 现在行业里的产品经理们是有问题的. 在上述 &真的人人都是产品经理吗?& 一节中提到的诸多不利于做产品经理的因素, 实际上就是我自己身上表现出来亦或观察到别的产品经理身上的毛病.
　　我认为现在各个公司似乎夸大了对产品经理的需要. 实际上有些工作可以由运营人员或技术去完成. 大包大揽导致人为扩大产品经理岗位缺口, 让很多没有经验的朋友误认为产品经理是 &万金油& 职业, 是没有技术要求的职位, 甚至是一块敲门砖, 摇身一变成为产品经理, 去决定他们的用户应该使用什么功能. 但大量同质化, 粗放的产品告诉我们, 这样做是有问题的. 并不是人人都是产品经理, 人人只是一个网站.
　　理想情况下产品经理不应该成为一个人的 &目标职位&, 而应该是顺其自然, 水到渠成的职位. 也就是说, 不应说 &我要当产品经理&, 而是当各方面积累到一定程度后, 自然而然转变为 &产品经理&. 很难想像一个有充分积累的人一点不会关心产品本身.
　　本来只想写写我见过的产品经理, 没想到花了三天时间写出这么多. 权当成对自己几年工作里的一些想法的总结吧. 欢迎大家和我讨论.
(转载请保留)
热门话题大家都在看
互联网的一些事，已超50万小伙伴关注！一个产品从无到有的过程中产品经理需要做些什么？-马海祥博客
新型SEO思维就是从一个全新的层次上提升seo优化的水平，达到网络信息最佳化的展示效果！
> 一个产品从无到有的过程中产品经理需要做些什么？
一个产品从无到有的过程中产品经理需要做些什么？
时间：&&&文章来源：马海祥博客&&&访问次数：
从事产品的工作好多年了，但自己一直苦于这样或者那样的困惑，很多人想要从事产品，或者老板自己要亲自承担产品一职，但他们对产品这个岗位的认识却不明晰，有的以为是纯粹的画原型，有的是以为做项目管理跟踪项目进度，有的是做竞品分析给老板看。
实际上，这些都不是产品经理的核心和重点，在较为成熟的企业，因为产品的壮大和人员的增多，为了便于协作和沟通，岗位会细化的很清楚，如产品经理、师、UI设计师、用户体验分析师、数据分析师、运营等等。
但是创业型公司中产品经理往往都是身兼数职，创业公司追求的是效率最大化、成本最低化，根本没精力将岗位分的那么细致，下面我以一个创业者的视角或者说负责一个产品项目的产品经理角度出发，来审视整个过程，看一个产品从无到有，产品经理需要哪些事情。
一、项目启动前
做任何东西之前，首先要考虑其背后的用户需求、商业价值、技术难度，只有用户有需求，你的产品才会有人用；只有其商业价值成立，才能为企业带来利润，毕竟企业最最基本的目标就是要盈利；只有技术上的总体评估是可行的，整个项目才可被执行。
现在的，大家都在追求&快&，比如2个月融资，4月用户过百万，3年后纳斯达克上市，但是这都是大家看到别人创业成功的表象，殊不知做任何事情的前提是，你得了解你在做什么，诚然，不排除哪些胆子大运气好随便干就成了的，但那只是个案，不值得深究。
1、产品定位
在项目的执行过程中，我们经常陷入一种情景，就是一堆人在一块，讨论的氛围可谓是情绪高涨，A说这个地方的按钮不行，B说这个地方应该像人家APP那样做，C又说你们都不对应该是这个模块不要换成这个云云。
经常参加这种讨论，会无比的耗费时间和体力，动辄好几个小时过去，但一散会，发现什么结果也没得出来，多数情况下，一定是产品定位出了问题，执行的人一定要清楚的明白产品是用来干什么的，给什么人用，才能正常的去讨论具体细节。
如果热血沸腾、蹬鼻子上脸的的讨论了好久，发现没结果，发现会议的讨论跑偏了，不妨回归本质，想想我们的产品定位是什么。
2、产品定义
产品定位包含两个大的内容一个是产品定义，另一个是需求定义，产品定义要分析的内容包含产品的使用人群、主要功能和产品特色。
举例，你现在要创业搞一个移动端招聘APP取，作为产品经理首先应该干什么？中国每年的就业人口非常庞大，行业也各种各样，那你就有要想，你的产品是要给什么样的人提供服务，你如果想服务所有行业的人群那是不可能的，首先一个小公司去整合这么多行业招聘信息本身就非常困难，另外，并不是每个行业的人对互联网的 接受程度那么高。
通过数据分析和调研，发现现在国家鼓励创业，创业的高峰期必然产生大量的人力需求，尤其是现场几乎说到创业没有哪个是跟互联网无关的，而且从事互联网的人对于APP的接受程度也很高，至少都愿意尝试，所以你把互联网这个行业的从业人群作为你产品的使用人群。
当你分析完其他招聘类APP后，你发现这些APP有很多问题，比如我就是要找上海浦东新区那边的工作，但是很多APP目前都是没位置筛选；虽然可以海投，但是得到的反馈的寥寥无几；能够了解的企业信息太少；在投递建立前，作为求职者希望知道这个公司的老板是谁；现在都互联网时代，电子简历完全可以了，为什么每次招聘还需要招聘者自己打印简历，要知道打印简历对于求职者来讲并不是很方便，因为随时会改动，这对求职者非常不方便。
所以你打算做这个APP，他的特色功能就是：岗位支持企业所在位置分类；招聘方应该时时给予求职者反馈；取消纸质简历。
3、需求定义
需求定义的分析包含目标用户、使用场景、用户目标三个方面。目标用户是什么类型的人会用你的产品；主要功能是指你的产品是用来干什么的，是工具是社交还是其他；你的产品相对于其他市面上的产品有什么不同的地方，这就是产品特色。
刚才明确了APP的适用人群、主要功能和产品特色，市面上的招聘APP，有的是做猎头的专门针对于希望跳槽的，你的APP的目标用户是谁？基于特色功能分析和用户痛点，分析出出产品的目标用户是那些有想在具体位置找工作的人，比如已经定居北京后沙峪的人，希望工作在望京；当你刚刚搬家到回龙观时，此时你面临着换工作，你可能会倾向于找西二旗那边的工作。
4、需求分析
以上就是所有产品定位的内容，这些完成之后，紧接着的就是竞品分析和用户调研，一方面这是对我们的需求进行一定的验证，另一方面也是我们直接接触用户的一个机会，看用户存在什么需求。
5、需求筛选
早期需求筛选是个非常苦逼的事情，如果产品经理自己就是老板，自己心里很清除还行，如果不是很容易陷入海量的需求中拔不出来，讨论着讨论着就跑偏了，讨论完之后好像什么功能都需要，这个功能有用，必须加；那个功能太好玩了，用户肯定有趣，这话总完全凭个人主观臆断的东西，往往都是当时听起来貌似合理，但事后却经不起推敲，所以我们需要始终把握住我们的产品定位和优先级，万不可盲目的在这个地方做很多无畏的牺牲和奋斗（少做不经思考的、拍脑袋的、不经过大脑的决定）。
早起需求筛选期间，会出现很多这样或者那样的需求，有些我们不能立马做出判断说做还是不错，这些点子有可能以后会成为我们产品迭代的启发点，也会给产品的发展带来更广的思路（具体可查看马海祥博客《》的相关介绍）。
做好管理，尊重每一个人的想法，在出现模棱两可时，记录下载，对会议的推动和进展会有很大的帮助。
二、商业价值
市场需求文档和商业需求文档，一般在大公司会得到比较成熟的体现，小公司往往多数都是老板自己决定，老板可能不会搞这样或者那样的文档，但他自己肯定会去做基本了解，或者本身自己就很了解某个行业。
这两个文档并不是多余的，也不是累赘，如果在项目启动前，能够花一定的时间去深入了解行业和用户是非常必要的，具体文档细节在这里不做阐述，网上有很多可以去借鉴的，或者看下马海祥博客《》的相关介绍。
三、产品层面
需求产生了之后，紧接着产品人员就可以产出需求文档，需求文档对接下来交互设计(创业公司往往产品经理会担任)、UI设计起着关键性的作用，当然在需求闻文档产生的过程中，如果有专职的交互设计，在需求阶段最好和产品人员一起来探讨需求文档的细节，这对于交互设计自己理解整体的需求有帮助，也对他进行原型设计和撰写交互说明有很好的帮助。
需求文档大致包含的内容会有如下几个方面：
背景描述：为什么开展这个项目?解决用户什么问题?会有多大的价值?大致就是把项目启动前做的功课进行一下总结说明，务必精简明了。
用户画像：对用户特征进行虚拟说明，阐明用户情况。
项目时间规划：什么时候出来原型？什么时候出来真实设计稿？什么时候进入开发？什么时候开始测试？什么时候开始提交应用商店？这些都需要明确出来，不然如果没有时间概念，什么事情都会拖拖拉拉，没有紧迫感（具体可查看马海祥博客《》的相关介绍）。
信息结构图：产品的内容组织结构，下面是举例，简单的给出微信的基本结构。
任务流程图：对于APP中的大功能，把用户从开始到结束的整个过程梳理出来，把各种可能性考虑进来，否则之后如果开发碰到问题了问你，你还得重新考虑，更可怕的是开发不问你直接就开发了，而结果还不是你想要的，下面以一个简单的登录为例：
需求说明：把每个操作的条件和结果说清楚，如果能够用文字说清楚的就用文字，说不清楚的最好用图片。可能有的人会说，这个时候还没有线框图，怎么解释啊。这个并不矛盾，早起的需求文档是用来给交互看的(再次强调，创业型公司的产品可能会兼着交互)，交互设计师再根据你的功能结构和流程梳来设计线框图和高保真的原型图。
数据埋点：把后期需要查看的数据列成清单，比如说这个按钮的点击率，这个页面的打开率等等，这个时候需要和运营多交流，对需要做埋点的地方理清楚。这对于产品上线后的数据分析很有帮助，数据也可以辅助产品功能的迭代。
四、交互设计
需求整理完成之后，接下来大致要进行的就是线框图、页面流程、高保真原型图和交互说明的设计和产出，高保真原型是具体情况来定，有的公司有要求，有的没有。
力求简单清晰的表达出每个页面的视觉效果，这里最好不要加入交互，也不要搞的五颜六色，最好是黑灰色。每个情形就是一个页面，把各个情况用页面分别表达出来，一方面你会更加清晰APP整体的界面数量，另外设计也会更加清楚你想要什么，否则加入了交互，设计也不知道怎么点，你还得解释半天。
2、页面流程图
比较类似之前的信息结构图，页面流程图这是用各个页面来做连接，视觉上更加清晰各个环节的衔接和跳转。
3、高保真原型图
对交互的要求会更高。需要比较完整的展现各个功能之间的交互动作，另外在视觉上尽量还原真实产品的样子(关于Axure，可以学习金乌的课程，很不错，很多人觉得讲的太罗嗦，但是你认真看下来还是很有收货的)。
4、交互说明
个人觉得，交互说明和高保真原型有重合之处，如果做了高保真，那么多数的交互动作基本上都可以展现，但是有些地方的交互动效是软件无法搞定了，这个时候就需要你用交互说明了。
如果文字和图片都不要说明的就直接用纸片来模拟，不要小看这种方式。
这里做交互标记的工具推荐几个给大家：mac电脑果断是sketch了，windows下有snagit、圈点、FScapture，另外viso也可以标注。
五、UI设计
一般情况下，交互设计师讲线框图交给设计师，设计师就可以开工了，这个过程，交互也要多和设计去沟通，毕竟UI也会有自己的专业度，她会有自己的设计见解，这很正常。
好的UI设计不仅是让软件变得有个性有品位，还要让软件的操作变得舒适简单、自由，充分体现软件的定位和特点。
与之相应，UI设计师的职能大体包括三方面：一是图形设计，即传统意义上的&美工&，当然，实际上他们承担的不是单纯意义上美术工人的工作，而是软件产品的产品&外形&设计。
二是交互设计，主要在于设计软件的操作流程、树状结构、操作规范等，一个软件产品在编码之前需要做的就是交互设计，并且确立交互模型，交互规范（具体可查看马海祥博客《》的相关介绍）。
三是用户测试/研究，这里所谓的&测试&，其目标恰在于测试交互设计的合理性及图形设计的美观性，主要通过以目标用户问卷的形式衡量UI设计的合理性，如果没有这方面的测试研究，UI设计的好坏只能凭借设计师的经验或者领导的审美来评判，这样就会给企业带来极大的风险。
六、项目执行
设计产出了，交互的工作也做完了，该去交给项目经理执行了，这个身份目前来看那只有很大的公司里才会有，一般情况下是由产品经理直接兼任了，这里马海祥需要提醒大家的是，在执行前，各种相关的规范要先建立起来。
1、apk、api文件的命名规范和不同类型安装包的管理
这里全是我个人的经验，做好这些，会对以后安装包的管理会有极大的帮助，我们当时把搭建了一个开发者环境，这个环境下的APK、API文件只能在局域网类使用，在这个环境下可以任意折腾和测试，不会影响到已经上线的应用。
开发者环境下打包的安装包图标和命名要和线上环境下的应用区别开，以后在续测试时就不会因为各个版本搞的手忙脚乱。
2、APK、API文件管理
（1）、开发版：纯开发自己使用或者产品使用，其他无关人员一般情况下不会接触到这个版本。网络环境：仅特定网络环境下使用(需要技术人员搭建环境)。
（2）、公测版：经过产品和测试人员的详细测试后，基本没有什么BUG了，就可以拿出来给公司的人使用，也算是上线前的稳定性测试。网络环境：仅在特定环境下可以使用(需要技术搭建环境)。
（3）、商店版：准备提交到市场的APK、API文件。在经过开发版本、公测版的全面测试后，排除一切不稳定bug，此时打包的商店版仍然需要经测试人员的最后把关，最后一定要保证的是，准备上线的APK、API文件是经过测试人员的最后把关的，否则如果开发如果做了改动不通知测试和产品人员，上线后出了问题再改就晚了。
七、APP测试和版本号管理
版本好号的管理，前期就要搞清楚，否则后面产品上线后，出现bug要改进，或者添加新功能后对老版本是否有影响，这个时候版本号管理的好就会起到很大的作用，一方面你可以随时找出之前上线过的apk、API文件，另一方面面对不断修改打包的文件不至于把自己搞混。
下面是我个人的意见，如哪个大牛有好方法可以分享出来。
1、测试须知
UI、交互、产品在技术人员开发阶段，要多和技术人员沟通，最好是将大功能细化成小功能模块，每次做好一部分就通知相关的人进行检查，以免累计到最后问题过多修改动作太大。
UI负责盯着开发是否按照自己的设计实现的，交互负责关注交互效果是否符合你的标准，产品负责关注各个功能的实现是否正确。
2、测试用例
好的测试用例能够有效的推进测试的进程，好的测试用例在于尽可能的把APP的各种需要测试的情况用人话描述清楚，这点就看你的文字能力了，测试用例写出来会交给测试人员来测，这也是他们评判APP是否达标的标准。
3、Bug管理工具
bugtags,bugclose等等，市面上有很多，多是免费的，即使是收费也不要在意那么点钱，借助bug管理工具能够有效的提高测试人员和技术人员的协作效率。
最后，提醒大家一点：版本号始终是唯一的，是依次迭代递进的，不要为了上线时版本号好看就去刻意干扰版本号，严禁搞多套版本号。
八、产品上线后
产品上线后，作为产品经理，马海祥觉得你需要关注的事情有几个方面，一是产品数据；二是用户反馈；三是需求提取。
1、产品数据
新增用户：第一次启动应用的用户；
新增独立用户：全体应用的新增用户的总和（去重）
活跃用户：当天启动一次的用户即为活跃用户，含新用户和老用户；
活跃独立用户：当天应用的活跃用户总和（去重）
MAU：MAU（monthly active users）月活跃用户人数。
DAU:DAU(Daily Active User)日活跃用户数量。常用于反映网站、互联网应用或网络游戏的运营情况。
用户留存率：在互联网行业中，用户在某段时间内开始使用应用，经过一段时间后，仍然继续使用该应用的用户，被认作是留存用户。这部分用户占当时新增用户的比例即是留存率，会按照每隔1单位时间（例日、周、月）来进行统计。
用户留存率中的40-20-10法则：如果你想让游戏、应用的DAU超过100万，那么日留存率应该大于40%，周留存率和月留存率分别大于20%和10%。
次日留存率：（当天新增的用户中，在往后的第1天还活跃的用户数）/第一天新增总用户数；
第2日留存率：（第一天新增用户中，在往后的第2天还有活跃的用户数）/第一天新增总用户数；
第7日留存率：（第一天新增的用户中，在往后的第7天还有活跃的用户数）/第一天新增总用户数；
第30日留存率：（第一天新增的用户中，在往后的第30天还有活跃的用户数）/第一天新增总用户数。
2、用户反馈和评论
产品上线后，用户的反馈和评论对于产品人员来讲是尤为珍贵的材料，一方面这是你的真实用户的直观感受，另一方面他们再表达直接的需求，那么，怎么样处理用户的意见就显得格外重要，用户反馈什么我们就做什么，这是肯定不行的，很多情况下用户表达的只是一种表面现象，要学会去挖掘用户背后的需求本质，多去研究世界上一些革命性的产品，多去了解人。
当看到四处飞来的意见时，我们要学会思考，而不是全盘接受、全盘照抄。
是不是我们的目标？想想我们的目标用户是谁。
使用场景是否成立？还是这只是极个别人的场景需求。
用户目标是否正确？我们的APP是不是用来满足用户这个需求的？
产品定位还正确吗？如果做了这个功能，还符合我们产品的定位吗？
如果要做这个功能，那么自身的项目资源是否能够满足？如果需要举全部资源来做这件事情，那就要慎重再慎重（具体可查看马海祥博客《》的相关介绍）。
3、需求提取
也许用户的意见是个圆形，但经过分析之后，很有可能得到需求是个三角形。
&如果我最初问消费者他们想要什么，他们应该是会告诉我，&要一匹更快的马！&&&&这是亨利&福特的一句经典名言，如今我们在《乔布斯传》里又见到了它。
100多年前，福特公司的创始人亨利&福特先生到处跑去问客户：&您需要一个什么样的更好的交通工具？&几乎所有人的答案都是：&我要一匹更快的马&，很多人听到这个答案，于是立马跑到马场去选马配种，以满足客户的需求，但是福特先生却没有立马往马场跑，而是接着往下问。
福特：&你为什么需要一匹更快的马？&
客户：&因为可以跑得更快！&
福特：&你为什么需要跑得更快？&
客户：&因为这样我就可以更早的到达目的地。&
福特：&所以，你要一匹更快的马的真正用意是？&
客户：&用更短的时间、更快地到达目的地！&
于是，福特并没有往马场跑去，而是选择了制造汽车去满足客户的需求。
客户需求有显性需求和隐性需求两大类，我们通过市场调查得知的往往都是一些诸如&我要一匹更快的马&这类显性需求，客户的显性需求并不是客户真正的需求，企业需要根据所收集的显性需求信息进行深度挖掘和捕获，以了解客户的隐性需求是什么，进而分析出客户的真正需求是什么（例如：用更短的时间、更快地到达目的地），这就是一个需求分析的过程。
乔布斯所言：&我们的任务是读懂还没落到纸面上的东西。&实际上就是用户隐性需求的深度挖掘。
马海祥博客点评：
对于大公司而言，产品经理是一个非常重要的角色，因为产品经理要负责整个产品的成败，所以从研发到生产到销售，产品经理都有权进行干涉，但是在小公司境遇就不尽相同，权力会相对小一些，但是产品经理对于提高自己的创新能力，选择创业是非常有帮助的。
本文为原创文章，如想转载，请注明原文网址摘自于/cpyy/1457.html，注明出处；否则，禁止转载；谢谢配合！
您可能还会对以下这些文章感兴趣！
一个漏洞的公开之日就是死亡倒计时的开始。如以前所有的漏洞事件一样，在它被慢慢补上并淡出人们视线之前，……
近日百度百科又改版了，其中明星词条改版最大，不仅全民女神范冰冰、气质女神刘诗诗、教主黄晓明、喜剧天王……
日，微软在全球190个国家和地区提供Windows 10正式版的免费升级，Windows7、Windows 8和Windows……
新闻源是指符合百度、谷歌等搜索引擎种子新闻站的标准，站内信息……
目前，在中国做seo的在大多数时候，我们都是以百度和Google作为……
对于一个合格的SEOer来说，要想分析一个网站的目前状态，首先要……
网站PR值的变动原因有很多，特别是被谷歌降低PR值的时候，可能发……
对于混迹于国内站长圈的朋友来说，每天起早贪黑发外链的网站被百……
一说到网站作弊方法，那就不得不说SEO优化中的黑帽SEO了，黑帽SE……
本月热点文章}