豆瓣
扫码直接下载
LEON
2012-02-22 17:56 44人喜欢
附录：他山之石，可以攻玉 一些值得看到博客： UCDChina http://ucdchina.com/ 以用户为中心的设计 ExcelPro的图表博客 http://excelpro.blog.sohu.com/ Excel、PPT的技巧 人月神话 http://blog.sina.com.cn/cmmi/ 项目管理、CMMI、PMP（Project Management Professional 项目管理师培训考试） 刘未鹏IMind Hacks http://mindhacks.cn 思维方法 褪墨 http://www.mifengtd.cn/ 时间管理 左岸读书 http://www.zreading.cn/ 战隼的学习探索 http://www.read.org.cn 如何学习、如何记忆、如何阅读 知识管理 译言 http://www.yeeyan.org/ 翻译国外技术与创业的文章 可能吧 http://www.kenengba.com/ 互联网趣事 爱枣报 http://www.izaobao.us/ 草根的新闻联播，每天早上一篇 FT中文网 http://www.ftchinese.com/ 财经译文 打喷嚏 http://www.dapenti.com/blog/index.asp/ 有思想的好文章 科学松鼠会 http://songshuhui.net/ 各种好玩的科学知识 疯狂的设计 http://hi.baidu.com/madesign/ 前百度首席设计师郭宇的博客 煎蛋 http://jandan.net/ 看图、看片 我们爱讲冷笑话 http://lengxiaohua.net/ 一些值得读的书： 产品经理：《产品经理实战手册》《产品经理的第一本书》《产品经理的第二本书》《走出软件作坊》 用户体验：《用户体验的要素：以用户为中心的Web设计》《赢在用户：Web人物角色创建和应用实践指南》《一目了然：Web软件显性设计之路》《点石成金：访客至上的网页设计秘笈》《设计心理学》《情感化设计》《软件观念革命：交互设计精髓》《交互设计之路》《GUI设计禁忌》《可用性工程》 项目管理：《软件工程》（英）萨默维尔 机械工业出版社；《人月神话》《人件》《UML基础、案例与应用》 敏捷开发：《敏捷估计与规划》《敏捷迭代开发：管理者指南》《用户故事》 其他：《公司进化论：伟大的企业如何持续创新》《跨越鸿沟》《罗伯特议事规则》《决策与判断》《别做正常的傻瓜》《学会提问——批判性思维指南》《黑天鹅：如何应对不可预知的未来》《美第奇效应：创新灵感与交叉思维》《社会性动物》《统计数字会撒谎》《中国历代政治得失》《激荡三十年》《万历十五年》《常识》梁文道著《大败局》(I、II）《长尾理论》《世界是平的》《维基经济学：大规模协作如何改变一切》《未来是湿的》《众包：大众力量缘何推动商业未来》《轻公司》《影响力》《把时间当作朋友——运用心智获得解放》《当下的力量》《少有人走的路》（1、2、3）《遇见未知的自己》
Susielovely (A little bit stronger)
2012-06-10 10:04 28人喜欢
蘑菇 (you never know)
2011-04-11 19:31 31人喜欢
[已注销]
2012-03-04 19:21 12人喜欢
melon (祝这世界继续热闹，祝我仍是我。)
2012-12-18 17:34 12人喜欢
第1章 写给-1到3岁的产品经理 产品是一组将输入转化为输出的相互关联或相互作用的活动的结果，即“过程”的结果。在经济领域中，通常也可理解为组织制造的任何制品或制品的组合。产品的狭义概念：被生产出的物品；产品的广义概念：可以满足人们需求的载体。 《产品经理的第一本书》 《产品经理的第二本书》 《公司进化论》 传统行业与互联网行业： 行业形态不同；产品形态与成本结构不同；生命周期不同；盈利模式不同；用户心态不同。 【BRD】: Bussiness Requirement Ducument，商业需求文档 【PRD】: Product Requirement Document ，产品需求文档 第2章 一个需求的奋斗史 用户研究/需求采集的过程：明确目标、选择采集方法、制定采集计划、执行采集、资料整理，然后进入下一步的需求分析阶段。 常用的需求采集方法： 定性地说：用户访谈—— 用户访谈经常用在新产品方向的预研工作中，或者通过数据分析发现现象以后，去探索现象背后的原因。 出现问题：“说”和“做”不一致的问题；样本少，以偏概全的问题；用户过于强势，把我们往沟里带；我们过于强势，把用户往沟里带。 《软件观念革命：交互设计精髓》 定量地说：调查问卷—— 出现问题：样本的偏差，即样本与想了解的目标用户群体出现偏差；样本过少的问题；问卷内容的细节问题； 【可用性测试】（Usability Testing）是指在设计过程中被用来改善易用性的一些列方法。 【焦点小组】（Focus Group）是由一个经过训练的主持人以一种无结构的自然的形式与一个小组的被调查者交谈，可以视为一种一对多的用户访谈形式。 【种子用户】是指某产品的一些忠诚度很高的用户，产品设计者与他们长期保持交流，让他们试用最新产品，可以经常从他们那里获得产品的建议和意见。 【灰度发布】是互联网发布上线的一种常用形式，先让少量用户看到新产品，利用他们的反馈进行修正，逐步把新产品展现在所有用户眼前。 定性地做：可用性测试—— 是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题，通常只能做少数几个用户的测试，看他们怎么做。 首先招募测试用户；然后是准备测试任务；接下来是测试过程；最后是研究和分析。 出现问题：如果可用性测试做得太晚，这时发现问题也于事无补了；总觉得可用性测试很专业，所以干脆不做；明确是测试产品，而不是测试用户；测试过程中，组织者该做的和不该做的。 【UGC】User Generated Content, 用户产生内容。 定量地做：数据分析—— 出现问题：过于学术，沉迷于“科学研究”；虽然数据不会主动骗人，但我们经常无意或有意地误读数据；平时不烧香急来抱佛脚。 在对产品足够熟悉的基础上，先做出方向性的假设，再提取相应的数据并分析，得到一些现象，最好是之前没发现的现象，然后尝试解释，接下来做用户调研修正解释，最终指导产品发展方向。 《黑天鹅》 《统计数字会撒谎》 需求采集方法：现场调查；AB测试；日记研究；卡片分类法；自己提需求。 用户跟福特要一匹更快的马，福特却给了用户一辆车。对于同一个问题，两套解决方案的区别就是，一个是用户需求，一个是产品需求，而这中间的转化过程，就是需求分析。 【用户需求】用户自以为的需求，并且经常表达为用户的解决方案。 【产品需求】经过我们的分析，找到的真实需求，并且表达为产品的解决方案。 【需求分析】从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。 需求分析是“首先：树叶——树枝——树干，其次：树干——树枝——树叶”的分析过程。 伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给出更好地解决方案，或者说是用户真正需要的东西。 需求来源于理想与现实的差距，那么减小差距就有三种方式：改变现状；降低理想；转移需求；创造需求。 【信息架构】（Information Architecture, LA）它的主要任务是为信息与用户认知之间搭建一座畅通的桥梁，是信息直观表达的载体。通俗点讲，信息架构就是研究信息的表达和传递。 需求的基本属性：编号；提交人；提交时间；模块； 需求种类：新增功能；功能改进；体验提升；BUG修复；内部需求； 需求层次：基础；扩展（期望需求）；增值（兴奋需求） 产品功能需求+产品非功能需求=产品需求 产品需求+市场需求+开发需求+测试需求+服务需求+…=产品包需求 【KANO模型】是一种对顾客需求或者说对绩效指标分类，通常在满意度评价工作前期作为辅助研究模型，KANO模型的目的是通过对客户的不同需求进行区分处理，帮助企业找出提高企业顾客满意度的切入点。 需求的商业价值用重要性、紧急度、持续时间三个指标来衡量。 绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不做。 绝对不能因为某个需求的实现难度很小就马上去做，也不能因为另一个需求的实现难度大就不做。 性价比=商业价值÷实现难度（简化为开发量） 【鲶鱼效应】即采取一种手段或措施，刺激一些企业活跃起来投入到市场中积极参与竞争，从而激活市场中的同行业企业。其实质是一种负向激励，是激活员工队伍之奥秘。 做项目，终极目标就是：多快好省，即范围大、时间短、品质高、资源省。 “需求打包”最好打包类似的功能点； “需求依赖”，功能互相之间有依赖关系； 需求的粒度大小问题。 【MRD】Market Requirement Document，市场需求文档 BRD：项目背景、商业价值、功能需求描述、非功能需求描述、资源评估、风险和对策。 情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子。 少做就是多做。做的少不如做的巧。内部的大改动往往是外部的小改动。 第3章 项目坎坷的一生 【项目】只会进行一次，包含多项互相关联的任务，并且有绩效、时间、成本和范围限制的一项工作。 “做产品”的过程，正是通过做一个又一个项目实现的，但并不是项目的简单累加。“产品线”按不同的细分市场，推出不同的产品，表现形式上叫版本、模块、增值服务，本质上是通过合理地安排项目来实现产品的规划。 产品经理——靠想。产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润。 项目经理——靠做。项目经理是把事情做正确，把事情做得完美，在时间、成本和资源约束的条件下完成目标。 一个内部驱动，一个外部驱动。 对产品经理来说，最重要的是判断力与创造力。 对项目经理来说，最重要的是执行力与控制力。 【UE】用户体验团队 “三点估算法”评估出最乐观的工作量、最悲观的工作量、最可能的工作量。 工作量=（最乐观+最悲观+最可能）÷3 工作量=（最乐观+最悲观+最可能*4）÷6 项目沟通方式：周期、渠道、发起者、参与者。项目晨会、项目日报、评审会、项目变更申请、发布预告及公告。 Kick Off会议：项目背景；项目意义、目的与目标；需求、功能点概述；项目组织架构；项目计划；沟通计划。 【项目TRQ】项目时间、项目资源、项目质量。 做项目的本质就是在保证品质的前提下，在时间要求、人财物话费、项目范围三点上做平衡。 【WBS】Work Breakdown Structure,工作分解结构。 Blog：Michael on Product Management & Marketing 文档：BRD(商业需求文档), MRD(市场需求文档), PRD(产品需求文档), FSD(功能详细说明) PRD：修订历史、项目概述、功能范围、用户范围、词汇表、非功能需求、其他说明。 《UML基础、案例与应用》 类图，描述系统中出现的各个对象之间的关系，以及和外部系统的关系。 用例图，描述各个用例之间的关系。 状态图：表达系统里实体的状态转换。 时序图：描述事物变化在时间维度上的先后顺序，善于表达对象的交互。 活动图：描述各个动作如何引起系统变化，善于表达泳道较多、分支较多的情况。 协作图：表达不同对象之间是如何相互影响的。 UC文档—— UC概述：用例的唯一标识；用例名称；业务描述；需求描述；行为者；前置条件；后置条件；其他说明 UC主体：界面描述；业务规则；流程描述。 Demo：从低保真到高保真。 需求评审：PRD, UC, Demo评审； 设计评审：在概要设计与详细设计完成之后，由开发工程师把对需求的理解以设计文档的形式说给PD、测试听。 测试评审：由测试工程师把对需求的理解以TC的形式说给PD、开发听。 【冒烟测试】该测试耗时短，进行基本功能检查。 【UAT】用户接受度测试。 【BUG】项目发布之前发现的叫缺陷，项目发布之后发现的叫故障。 【SVN】版本管理工具。 变更事件，是指项目范围内需求的变化。 搭车事件，是指项目范围的扩展。 紧急事件，由高层的老板确认后自上而下的推动。 【奥卡姆剃刀原理】如无必要，勿增实体。 项目管理是独特工作，风险大，效率低；流程管理是例行工作，风险小，效率高。 通用的做产品的流程： 概念：启动阶段，关注商业规划，DCPI。 方案：立项，项目执行层面的非关键成员加入，关注规格、计划，DCP2。 开发：控制过程。 验证：测试，DCP3。 发布：项目团队解散，成立LMT，老人带新人做生命周期管理。 生命周期维护：DCP4。 【DCP】Decision Check Point, 商业评审点。 【LCM】Life-Circle Management, 生命周期管理团队。 当年的“英雄”把自己的个人经验转变成显性知识表达出来，而对于经常做的事情，就可以用流程这种形式固化、传承，后人在做这些事的时候起码不会太无助。在这点上，规范、模板的作用有类似，这就是团队的核心竞争力。 个人的核心竞争力是把显性知识转化为隐性知识的能力，而团队的核心竞争力是把隐性知识转化为显性知识的能力。 商业评审决定“做不做”，是产品会议与功能评审；而技术评审决定“怎么做”，是需求、设计、TC、发布评审。 《敏捷迭代开发——管理者指南》 《敏捷估计与规划》 在职场中，做任何事情，除了权责利的划分外，还要权责利对等，有权力的人、或者被授权的人，可以享受事成的好处，也要担负失败的损失，千万不能只是因为你有能力做某事就把任务接下来，这样对谁都不好。 第4章 我的产品，我的团队 产品之大—— 时间之大：产品生命周期。 五中用户群体：创新者；早期追随者；早期主流用户；晚期主流用户；落伍者。 空间之大：商业、产品、技术。这三个方面，任何一个公司必然有它的强项和弱项，它不可能也没有必要在这三方面都很强，一是因为构建“性价比团队”的考虑，而是因为都强的话互相压不住反而造成消耗，所以更重要的是找到自己公司、或团队、或产品的那个突出的刀尖，也就是所谓的公司的DNA。 设计之大—— 战略层；范围层；结构层；框架层；表现层。本能水平的设计是基础，行为水平的设计是保证，反思水平的设计师升华。 团队之大—— 矩阵型组织 《公司进化论：伟大的企业如何持续创新》 《跨越鸿沟》 《用户体验的要素》 《设计心理学》 《情感化设计》 《Web信息架构》 偶尔为之的事情只需要可行解，经常做的事情要追求最优解。 PD习惯于从内向外，从本质出发；而用户习惯于从外向内，从表面看起。 规划师更多的是“结构化思维”，保证产品有用，能满足用户的某些需求，让产品“从无到有”；而设计师更多的是“形象化表达”，保证产品好用，能让用户用起来舒服，让产品“从有到优”。 “交互设计”比较适合传统领域、成熟公司、时间资源充裕的，公司在某领域中已经处于领先地位，目的是求稳，不犯错就是胜利；而“敏捷开发”适合新兴行业、创业公司、时间紧迫，大家都在干，谁先出头谁就能占得先机，或者作为挑战者进入某个行业，团队本身灵活，失败了损失也不大，重来的成本低。 规划师是产品的父母，把产品生出来；设计师是产品的老师，把产品教育好；运营师就算是产品的老板，要把产品卖出去，让产品从“叫好”到“叫座”，让更多的人愿意使用产品。 运营师策划、制造话题，运用病毒营销、事件营销的方法，让某些人获益。 《产品经理实战手册》 《美第奇效应》 《水平营销》 销售有两大模式：直销和分销。分销要通过渠道，渠道又分为代理和经销。代理赚佣金，没有产品所有权和库存风险；经销赚差价，产品所有权发生转移。 渠道的推拉。所谓“推”是集中力量做渠道工作，用高额利润去刺激渠道主动推销产品，快速抢占市场；而“拉”是通过PR、广告、传播等手段启动市场，刺激消费者，促使渠道来找厂商。 产品版本的分类： 一种是做功能区分，打细分市场。 一种是为了促进销售，利用消费者心理，纯策略性的做出“炮灰版”。 编码设计：软件架构师、系统分析师、开发工程师、开发经理。 数据库设计：DBA。 测试设计：测试工程师。 QA：质量保证人员，主要做流程管理，文档管理等。 配置管理员SCM：针对不断发布的产品、多分支同时开发的产品。管理代码、软件版本的变更、每日构建等。 系统管理员SA：硬件方面的管理。 让老板做问答题→让老板做选择题→让老板做判断题 《别做正常的傻瓜》 第5章 别让灵魂跟不上脚步 企业的价值观：企业决策者对企业性质、目标、经营方式的取向做出的选择，是员工所接受的共同观念，是长期积淀的产物。 绝大多数现实工作中的情形是“有得必有失”，如果你发现做一个改变只有好处没有坏处，那很可能是你站的低看的近，或者说你考虑到的“全部”只是更大系统里的一部分，所谓的“坏处”在其他部分体现出来了，这时候找一个站得高看得远的人讨论，他 比较容易发现问题。 经常与高手讨论，我们更容易培养自己的大局观，可以用更广阔的视野看待问题。 系统工程相关的知识。 产品战略——可行性分析——战略层——战略规划 可行性分析的思路：我们在哪儿（市场扫描，竞品分析；自我分析）；我们去哪儿；我们怎么去。 PEST分析，分别分析政治法律环境、经济人口环境、社会文化坏境、技术环境四个方面的机会和威胁。 竞品分析的实战方法：上网搜，试用产品；看行业分析报告（看出处，作者与机构的背景）；咨询公司做调研。 SWOT分析：有时、劣势、机会和威胁。 宏观上的用户需求，说的是某一个目标用户群体面临的问题是什么，并不涉及具体的产品或工呢过，也可以视为在选择细分市场和目标用户。 你走在起点到目的地的路上，你的“速度”可以分解成“方向”和速率，“速度”是一个矢量，其中“方向”就是“正确的做事”，保证效果，而“速率”就是“把事做正确”，保证效率。考虑到边走边看会降低效率，所以我们可以将路程简化成简单的几段直线，设置里程碑，在里程碑之间集中精力加速。 产品路标规划是一个产品，乃至产品线层面上长期的时间规划，路标规划上最小的单位，可能是产品的一个版本或相关的一个重大活动，细化以后都要通过好几个项目来实现。典型的规划周期是产品大版本周期的3~5倍。 项目组合管理、管道管理。 《罗伯特议事规则》 所有人提供意见，少数人讨论、一个人排版。 SMART原则： 具体，指绩效考核要切中特定的工作指标，不能笼统； 可度量，指绩效指标是数量化或者行为化的，验证这些绩效指标的数据或信息是可以获得的； 可实现，指绩效指标在付出努力地情况下可以实现，避免设立过高或过低的目标； 现实性，指绩效指标是实实在在的，可以证明和观察； 时限，注重完成绩效指标的特定期限。 远视者把目的当手段，近视者把手段当目的。 可行性分析 从项目管理角度叫“可行性分析”，产品设计角度叫“战略层”，公司层面可能叫“战略规划”，都差不多的内容。做完这步，也只是决定了“做不做”，完全没有到“做多少”（更准确的说是“第一步做多少”），“怎么做”到阶段。不止一个人说过，中国人做执行型项目其实还可以，但是做可研（可行性研究）型项目的时候就烂了，可能是因为可研更需要“思路”吧。 把思路最简化，分三步走。 Ø 现在在哪儿？ 这点其实最早应该做，但是很容易被忽略，我们习惯于一开始就定目标，但是不知道现在在哪儿的情况下，定的目的地其实都是非理性的。试想，你有2天的假期，想去旅行，你会选欧洲、澳洲么，还是去千岛湖吃个鱼头，或者去天目山吃个本鸡煲算了吧，这时候你心里倒是很清楚的，先明确了“我在杭州”这个前提。 推而广之，这一步包括了市场扫描、竞品分析这两个有专门讨论的话题，还有企业自身分析等更多的内容，最终体现在ppt里的可能只是一页“背景”。 Ø 我们要去哪儿？ 现在可以考虑这个问题了，千岛湖和天目山也只能选一个，要综合考虑各种因素，比如市场细分，目标用户定义，产品定位，销售目标等等，我最终决定去千岛湖。确定了各方面的目标，起点和终点就都定下来了，那么接下来很明显的就是要关注“起点和终点的差距”么，也叫“理想和现实”的差距，我们可以定义成“要解决的问题”。 Ø 打算怎么去？ 解决问题，一开始是两个字，“策略”，各种各样的“策略”：定价、广告、推广、渠道、财务、技术、时间表……也就是把起点和终点之间的那条线画出来，看看能不能画出来，画出来的成本是多少。可以走高速、可以骑车、可以打车（确实可以……），看一下时间、费用等等，这叫决定“做不做”，也就是“做正确的事”。 在这之后，进入执行层面，这才到“计划”，比起开始就想定目标的人来说，开始就定计划的要更糟糕一点。我很喜欢的一个比方，你走在这条线上，你的“速度”可以分解成“方向”和“速率”（速度是个矢量，复习一下中学物理），“方向”就是“正确的做事”，保证不做无用功，“速率”就是“把事做正确”（能力越大，如果方向不对，危害也就越大），保证效率。在然后就是不断的反馈你所在的位置，不断修正。考虑到边走边看的效率低，所以可以将路程简化成简单的几段直线，设置里程碑，在里程碑之间集中精力加速；或如鸭子船一样分离舵手和苦力的角色……最终达到终点，总结整个行程。 市场扫描 产品设计还有一个前置的步骤叫做市场扫描。需求采集已经决定要做一个产品了，而市场扫描是在决定“做不做”。 其实产品设计不是从需求采集开始的，至少还有一个前置的步骤叫做市场扫描。做过几个新项目的预研，就是在进行这个过程。这次就结合一些学习和自己的体会，说一下市场扫描这个话题，它也可分为几个步骤。 需求采集已经是决定要做一个产品了，而市场扫描是在决定“做不做”。 第一步是宏观扫描，针对整个行业。一个常用方法叫做PEST分析，分别分析P政治、E经济、S社会、T技术四个方面的机会和威胁。在这个层面上，根本不用管竞争对手，而是去看政治上，我们要做的市场是否是符合国家的规划，经济上对国民经济发展是否有利，社会意义、认同度如何，以及技术上是否已经从科幻变成现实。只有在这个层面上扫描的结果是乐观的，我们才有涉足这个行业的动力，才有继续做下去的必要。 在做接下来的微观扫描之前，我们还需要做市场定位的分析，将一个大市场细分为很多小市场，然后找到我们希望切入的小市场。毕竟任何产业发展了这么多年了，肯定形成了很多细分的小市场，如果一开始就想一口全部吞下，是注定要被噎死的。 竞争对手分析可以在这里做，创业型公司的套路就是不讲套路。 现在到了第二步的微观扫描，是针对细分市场的，非常常用的一个方法就是SWOT分析。它是将我们的内外部条件各个方面进行综合和概括，进而分析优劣势、机会与竞争的一种方法，相关的介绍资料很多，这里就不展开了。然后针对SWOT矩阵，很重要的一点是要给出每一块的对策（SO、ST、WO、WT）。 另外最近还了解到一个方法，不知道准确的名字，我把它称作“产品|市场”矩阵的分析方法（可以再延伸阅读一下BCG矩阵），它把市场分为新老两块，产品也分成新老两块，分别分析两两交叉形成的四个细分市场切入点。举例说明，网店版的进销存是新产品，那么它对于老市场（比如已经在用管家婆的用户）应该用什么策略，而对新市场（从来没有进销存概念的用户）又应该用什么策略。 小结一下，以上这些都是在做市场扫描，所以所有的分析都是以客户、市场的角度来思考的，并没有从产品出发，可以说到现在为止，产品还是不存在的。应该等扫描完了以后，大家才开始坐下来讨论我们的产品应该是一个什么东西。 竞争对手分析 产品设计要熟悉自己将要做的东西，在熟悉了整个市场的大势以后，就要研究一下竞争对手们了。最悲剧的是自鸣得意的作出一个东西来，却发现市场上早已经有了，更悲剧的是市场上没有是因为已经淘汰，或者没有需求了……，所以，竞品分析要做，经常做。 经典的$APPEALS分析法，是从如下八个方面入手的：$-产品价格（Price）；A-可获得性（Availability）；P-包装（Packaging）；P-性能（Performance）；E-易用性（Ease of use）；A-保证程度（Assurances）；L-生命周期成本（Life cycle of cost）；S-社会接受程度（Social acceptance），每一条里面又有若干细项，可以查阅相关资料。 实战的做法有如下几种。 上网搜，狂搜与要做的东西相关的产品，一般来说大概有哪些已有产品就可以了解了，然后就试用他们的产品，可惜我做的都是付费产品，所以竞品多也是付费的，大多数情况我们不会购买，也就是试试免费的，看看付费的功能列表，也会扮小白，打电话过去和对手的客服、销售套词（切记用手机，别用公司电话，大家都很敏感的……）。 此外，我们会看行业分析报告，但有一点要特别注意，一定要看出处，作者与机构的背景，这年头客观的报告已经不多了，多半都是第三方“应邀”写作的。这种报告一般都是市场占有率，简单的功能对比等，看看就好。 再偶尔我们也会请一下业界很有名的咨询公司来帮我们做调研，这倒是省不少事。在信息不完备的情况下，要保证结果有效真的太难了。 一切作为，都是为了收集尽可能多的、对的信息，进而作出尽可能正确的决策。阿里做的很多产品是没有可以模仿的原创，至少在国内，所以需要多看点国外的产品，这点做的很不够。 资源战争与BRD 为什么以前没有过这样的战争吧，因为公司原来是按照产品线划分的部门，这样对于某个产品来说，有自己的PD、开发与测试等，下个月要做哪些需求，完全可以在产品经理的层面上决定；而现在公司变成了按职能划分团队，有了统一的产品运营中心（PD和运营）、研发中心（所有开发工程师）、质控中心（所有测试工程师），这样的话，下个月各个产品就都想尽可能多的抢到开发与测试，然而资源总是严重不足的，所以最终做哪些，就必须要上升到几个中心的大老板层面来决定了，而大老板的决策依据就是各个产品经理的pk，对各自产品发展BRD（Business Requirement Document）的描述。 所以前段时间，大家一起在准备BRD，这就是我们的武器，我们需要尽力说明我们要做的东西的商业价值，才能抢到各种资源，因为在pk之前，全公司的资源需求已经是现有资源的好几倍了……（一般以“人日”来简单估算衡量，有同学说一群人pk简称群p，就是多争取点~人~~日~~~） 武器主要包含以下几个部分：项目概述、项目背景、商业价值分析（重点！大老板最感兴趣的，一定要说在点子上）、功能需求描述、其它需求、资源评估（重点2！大老板们要看成本）、风险和对策。大家可能也发现了，其实本质上还是那个词——性价比。 当然同学们也会搞点技巧性的东西，比如卖个破绽，故意加入一些让老板砍的东西，有点类似谈判技巧里的玩意。 最后谈一下两种组织架构的各自优缺点，按产品线划分的部门对产品本身是有利的，产品经理可以按照自己的想法做，资源有保证，产品规划不会被动改变，它的缺点也就是按职能分部门的优点；职能部门对全公司的资源共享有利，确保所有资源都用在对公司最有意义的产品上，另外它能把资源战争的鲶鱼效应从产品内部扩大到公司层面，使PD和产品经理们更抓狂的去为产品的发展而苦苦思索…… 1. 两种组织结构的变化，我的理解是公司自然发展的必然过程，随着产品的增多，全公司变成了越来越多个资源局部最优，他们之间可以互补的资源越来越多，此时全局最优的效益越来越明显，所以打通。 2. 产品线的优势，还有个是沟通的顺畅，单线领导，都向产品经理负责。 靠谱会议 首先，这篇说的只是正式会议，意味着不是站立会议，或者2、3个人在座位边、过道上的讨论，而是需要像模像样的找一间会议室的那种。 首先，明确目的，最最重要，其实做一个会议和做一个产品也是一样的。不要试图在一个会议中解决所有的问题，就算你要连着召集两个参与人大部分相同的会议，我也建议你把它们分开，甚至，更好的做法，合理安排一个会议中的议题，可以让部分人早点走，或者晚点到。依据目的，类似的日常会议一般在15min～2、3个小时不等。 会议前，做好准备工作，资源的确定是小：会议室、投影仪、白板、纸笔、网络等等（视情况而定）；人员的确定是大：确认好“必选”的和“可选”的，不要漏人，也不要叫闲人，把握“大会决定小事，小会决定大事”的原则（“大/小”指的是参会人数，比如全公司的会议，是没法讨论事情的，只能传达信息）。识别出会议的KP（Key Person，关键人物），通常是最大的一个或几个老板，提前当面或者电话知会一下，然后发出会议邀请，我们用outlook。而发送时间，我觉得日常会议提前24～72小时比较合适，看情况。邀请中需要注明会议的时间、地点、议程，每一项议程的估计时长，并且附上需要讨论的文档初稿，要求大家会前阅读（虽然很少有人能做到，很现实的问题），而对于KP，争取提前与他讨论关键议题，达成一致，叫做“串供”，这会让会上省很多时间和精力。正所谓，要想让会议不流于形式，就要把会议本身变成走走形式。 会议中，关键人物，在会前10min左右再次确认。关于迟到问题，其实没法避免，一般等个5min是极限，如果能想出合适的惩罚规则，会比较好。会议要有明确的主持人和记录人，当然可以是同一个人，主持人主要掌握整体时间进度，控制个人发言时间，均衡发言机会，保证议题不走偏；记录人要如实做好记录，特别是“会议决议”与“遗留问题”。所有事情，尽量在会上达成一致，给出“会议决议”，实在不行的可以作为“遗留问题”。最后，牢记很实用的“所有人提供意见，少数人讨论，一个人拍板”的民主集中原则。 会议后，会议记录最重要。尽量在24小时内邮件发出，收件人是所有参与者，抄送给所有参与者的老板，让老板们看到手下干的活，让大家知道老板们看得到他们干的活。然后给出“时间、地点、主持人、记录人、议程信息”，其实都不关键，关键是“会议决议”与“遗留问题”。会议决议就是传达，是会上大家确认过的，写明是谁最终拍板的，其实也是增加他反悔的成本，形成习惯以后，大家才能都清楚决议的严肃性，并且保证后续动作的连贯；遗留问题要描述清楚是什么问题，谁负责解决（一定只能是一个人），这个人承诺解决的时间点。相应讨论过的文档有更新，也应该补充发出（不一定是做邮件附件，我们通常给个wiki永久链接，自己去随时查看最新文档就好了）。 这一套跑下来还有个好处，因为难免会有人到不了会上，这样通过会议前和后的两个邮件，他也可以大概了解到主要情况。 仰望战略会议 战略会议，在印象中都是高层参与，一般会是去一个风景优美的地方，因为这种务虚会真的很费脑子，想象这些议题就明白了——5年后我们要做什么，不做什么……几个小时下来就头晕脑胀甚至脑残，更不用说几天。而具体谈些什么，我也只能想象一下，俗话说“高层定向，中层分解，基层执行”，我几年前会以为务虚的会议比较无聊，但是现在越来越觉得这是很实在的，是在掌握了极多的信息，有丰富经验等等的基础上做出的预测与判断，其实大家想深一步，只有这样的“找出问题、发现机会”的过程才真正体现出人的价值，从某种程度上讲，这才是最最不可替代的事情，或者说没办法自动化之后交给机器的做的事情，公司在这块上，从过去几年来看，做得还是很靠谱的。 自己只参加过一些“几个月后我们要做什么，不做什么”的讨论，更猛的还没机会参与，一直非常好奇。前几天，阿里的总参谋长曾鸣曾教授在内网里发了个帖子，叫《阿里历届战略会议回顾》。 很多几年来做的事情，当时没想通的，做了一些猜测的，现在都找到出处了，比如07年的某次战略会，让我时隔两年知道了当初有关物流的一些调研、还有“旺号”这个鬼东东的历史背景到底是怎么回事，很有意思。 比如下面这个，如何准备战略回顾会议上的演示，给出了一些自己的体会，总体来说我觉得曾教授给出的13个问题分为四部分。 1．上次会议讨论的重点问题是什么？ 2．关于这些问题我们达成了哪些一致意见？ 3．上次会议中哪些问题由于缺乏信息考证，不确定性因素等原因而未能解决？ 4．上次会议哪些执行计划被通过了？对于这些执行计划我们有哪些主要想法和设想？ 上面四条都是回顾截至到上次会议结束时的信息，把大家带入状态，细化的问题让演示的准备不会漏掉任何重要的方面。 5．自上次讨论会议后外部发生了哪些主要变化？ 6．自上次讨论会议后采取了哪些重要行动？以及这些执行对战略和财政上产生的影响？ 7．上次会议后我们搜集了一些供参考的信息，对于执行计划是否要对当初的设想作些调整？ 继续回顾，但是重点变成了上次会议结束到本次会议开始这段时间内。 8．我们今天讨论的重点是什么？ 9．你们提议的执行计划是什么？最初的设想和决定的理由？ 10．我们怎样实践这些设想和减少潜在的不确定因素？ 11．今天要讨论和做出的决定 面对这么多已经回顾出来的信息，今天要做的事情，重中之重，每个问题都很大，需要超多的工作来支撑。 12．从上一轮的战略回顾中我们学到什么？怎样在下一轮中学到更多？ 13．怎样改进战略回顾会议和会议进行方式？ 持续改进，针对“战略回顾”这件事情本身，如何做的更好。 因为演示的目的是“战略回顾”，所以曾教授列出的提纲也是紧密围绕这个话题。 ★ 一次产品整合预研 集团下我所在的子公司A组织结构变动，我在的事业部被划分到另外一家子公司B。于是，我做的产品就需要考虑这么一件事：新情况下，这个产品如何与B现有产品整合以发挥最大作用。 这么大的题目，也许让人一下子就想到书本中的各种战略分析工具，但我发现其实都很少有人用，真正在用的公司不会超过10%，而且就算用了，大多数还是请外面的咨询公司来做。倒是看过一家挺有名的咨询公司（TNS）给做的研究报告，将近200页的ppt，我想价格不会便宜，就算花得起那个钱，也耗不起那个时间，一般几个月的周期，要说结果的价值到底有多大，多少有点寻找心理安慰的感觉，这样就算方向走错也可以让自己心里好受点。 我并不是否认大公司做的那套，其实也很想参与一次，不过没机会，所以只好描述一下自己的山寨做法： 首先，我们觉得B公司的产品实在太多了，大大小小有几十个，必须先缩小范围，于是把所有的产品过一遍， 也就是以用户的身份把几个网站的相关页面都点了一下，基本确定了三个相关性比较大的产品，然后仔细研究。提一下我们如何快速了解一个产品——重点看产品的 介绍页面，一般这样的页面都是写给新访客看的，对于付费产品，目的是要让访客产生兴趣，从而变成销售机会，所以说这样的页面应该写产品的卖点，能解决什么问题，有什么好处，但我们发现太多的产品在这样的页面犯了错误，写上了产品的功能，有哪些模块，应该怎么用。对于用户来说，一开始给他看这些是赶人的行为，这样的内容无论如何应该写在用户看完卖点之后的页面，比如帮助里面，像新手上路，初始化这类地方。当然，作为PD，我们是很高兴看到这样的页面的，因为可以更快速的了解这个产品，所以我们内部也达成共识：这样的页面是写给竞争对手的PD看的，并且每次看到这样的页面，都在心里默默感谢对方。 接下来，找到这3个产品的产品经理要了几个文档： Ø 产品介绍的文档，通常是ppt，因为前期只是看表面，进一步了解就需要知道一些背后的信息了，比如这个产品的愿景、定位、路标规划等等。 Ø Personas文档，但很可惜，和我们一样，对方的产品也没有这个文档，所以只拿到一些调研报告，看个大概，了解一下典型用户是什么样子，和我们产品的用户差别有多大。这里我体会到，有形的Persona存在，更大的一个意义，可能并不是团队内部做产品的时候时刻想到用户，而是有新人进团队的时候，可以迅速了解用户，理解产品。 Ø 产品的试用帐号密码，把自己当作用户，进入产品试用，看帮助，每次拿到一个帐号的时候，乐观主义的我心里都想：对外卖几千、甚至几万块钱呢，福利真好。 Ø 产品最近的运营数据，了解对方产品近况，从数据中可以发现很多问题，比如最看重的数据指标（KPI）是什么，为什么看重这个；最近几个月哪个指标在恶化，背后的原因是什么。这类数据通常比较机密，先问问有没有现成的，可能需要通过抄送双方老板，甚至老板的老板等等方式拿到。没现成的，就需要向数据仓库的同学提需求了，而B公司这方面比较成熟，已经有了数据提取需求的平台，只不过代价是效率低了。对于定期需要了解的数据，最好能直接弄到数据仓库权限，有一点技术背景的同学应该都可以自己玩了。 上述的过程中，碰到疑惑的地方都先记下来，感觉了解到比较充分了，心里也一定充满各种疑问，这时候就可以联系对方的产品经理聊聊，解惑。 另外一些事情别忘了，当然也取决于产品的性质，比如对我们来说，中小企业的付费产品就存在销售和服务的问题：产品的整合也意味着销售渠道的整合，而现在的产品有通过第三方公司卖的，也有上门直销与电话直销；同样的服务渠道也要考虑整合，有通过第三方公司的也有自己做的。 到这里，收集、整理、理解各种信息暂时告一段落，当然，这个过程后面还需要继续补充，贯穿始终。接下来，我们开始考虑自己的产品与对方各个产品合作的好处和坏处，每一种整合方案都想，一定有好坏两面，如果只有一面，一定是考虑到不全面，没有想到某个利益相关方。可以从产品用户、公司本身（自己的产品，对方的 产品）、整个市场（竞争对手）等几个角度考虑。还有一点不好明说，但我隐隐感觉，站在多大的团队角度去考虑好坏，比如自己的产品团队、整个事业部、整个公 司，结论是不一样的。 最后，得出的结论，有可能是和B公 司的某个产品合作、多个产品合作，也可能是不合作独立发展，谁知道呢。我发现自己的批判性比较强，做类似预研的事情，总觉得怎么做都问题多多，但又没法对 老板说“我们啥也别做了”，是吧，所以只好“多害相权取其轻”，选定一个方向，考虑合作的方式，给出几个自己的方案让老板拍。 就这些么？寨到不能再寨，但是大多数公司都是这么做的，做完这个预研我对结果也没有任何把握，其实我们也很无奈，又能怎么办呢。到这里，一切都没有逃出“做不做”的范畴。 第6章 产品经理的自我修养 毕竟我们是年轻人，接下来几十年总的做些什么，与其漫无目的地走一步看一步，最后回顾医生发现没什么值得骄傲的，不如找到自己可以做一辈子的事——理想。 每个人都应该打一口属于自己的井，这样就不用再担心河水涨落。但打井并不只是为了自己，它在客观上会双向加速公司和个人的成长。 “只有个人在成长”是没逻辑的：公司不是学校，员工是拿钱的不是付钱的，所以心态上就不能只抱着学习的态度做事，况且，没有为公司的实战，光靠理论如何进步？另一方面，“只有公司在成长”也是没道理的：员工不是机器人，如果制作时不成长，那么公司就没法享受员工成长的附加值，长远看来也是一件很不划算的事。 就业保障会降低一个人的竞争力，职业保障可以提高竞争力。 悟>练>记 好的方法，并不能直接带来成功，只能提高成功的概率。 PD应该学什么？ （悟）修炼内功的方法 > （练）内功 > （记）招式 PD的第一年 # 《用户体验的要素》 《点石成金》 第一阶段，没什么能力，不负责产品的任何模块，只是打杂。这时要做的就是去熟悉PD需要的基本知识和技能和自己要做的产品的各个方面，包括功能、用户、业务、技术以及将来要合作的同事，打好基础，并且做点辅助性的工作。 第二阶段，感觉到无聊了，自认为可以做点PD的事情了，主动要求负责某些模块并可以做好指定的工作。这时会很看重自己负责的模块，特别表现在功能被砍的时候，会极力维护自己仅有的成果，缺乏产品层面的权衡。这时候的产品设计是从结构层开始的，主要工作是写UC，配合UI做demo，跟进开发、测试。 第三阶段，负责产品较多模块甚至所有功能，熟悉产品各个设计细节，感觉自己走了产品就难以运作下去，很有成就感。这时学会了权衡取舍，会做需求管理，砍功能也下得了手，日常工作中产品设计的范围层比重开始提高。 第四阶段，全面负责产品，知道了产品的工作不只是设计功能，还有比如运营、客服/技术支持的培训、发展规划、用户研究等许多事情，会主动找事做。工作范围会扩大到“大产品设计”，由于精力有限，这时候会开始无法掌握整个产品，非常苦恼，被迫学会充分发挥团队的力量来处理这么多事。 第五阶段，意识到自己不可能一直做这个产品做下去，不能让产品少了自己就不行，于是开始主动定规范、定流程，把自己手上的工作一点点分出去，使得自己可以去做其他事情。 第六阶段，离开自己做的已经比较成熟的产品，由其他同事继续，自己再去迎接新的挑战。由于有了之前对一个产品一整套设计的了解，所以新的轮回会上手快一点，也比原来清楚什么阶段应该做什么事，自己处于什么角色应该做什么事。 用户体验是有很高的商业价值的，作为高层能意识到这点是公司的幸福。 重温BME所学 Ø 定量与系统的思维。 当时所在的是“定量与系统生理实验室”。定量，意味着在定性的基础上更深入的研究，是以数据为基础的，体现了西方哲学，注重微观分析；系统，意味着总体的大局观，代表着东方哲学，注重宏观把控。对任何实物，如果真能做到定量与系统的分析，那绝对杠杠的了。产品设计中，两种思维也是相映成趣，时而定量，比如分析用户使用产品的数据、给功能点的重要程度从各个维度上打分；时而系统，比如综合考虑我们产品需要兼顾的各种利益人群、制定项目计划时照顾到方方面面……怎么这段写得很像小学生作为？=,=bbb Ø 数据挖掘步骤 VS 产品设计过程。 那会儿挖了2年的临床生理数据，今天看来，数据挖掘的步骤与产品设计的过程也都是同宗同源的，分为一下几步，对比一下。 数据准备 理解应用领域的目标：商业目标与用户目标确定。 产生目标数据集：确定细分市场、细分目标用户、市场调研、需求采集。 数据清理与预处理：需求整理、需求分析。 数据缩减与投影：确定优先级、用户需求转化为产品需求。 数据挖掘 将目标与特殊数据挖掘方法匹配：用什么技术平台、编程语言等等。 数据挖掘算法选择：技术方案的选择，系统设计。 数据挖掘：Coding的过程。 结果评价 解释和评估所挖掘到的模式：测试、用户试用，反馈修正上述过程。 使用所发现的知识：产品发布，投入应用。 学校里没教的东西 教知识不交思维。 交解题不交选题。现实生活中更多问题并不是已经摆在面前，而是需要你去发现的。要追求“性价比”，而不是“完美”。 教努力不教取巧。 当交互设计遇到敏捷开发 Ø Cooper大师认为子弹很贵，因此在每次开枪之前一定要精确地瞄准。负责瞄准的人应该是专业的交互设计师。 Ø Beck大师认为有了极限编程，子弹变得很便宜，我不需要瞄太准，打不准就再放一枪，没什么大不了，最终总能打中目标。 Ø Cooper大师很适合做一个狙击手，点射的命中率几乎能够达到100%。 Ø Beck大师很适合做一个机枪手，机枪是不可以点射的，一般都是扫一片，用密集的火力消灭敌人。 Ø 两者考虑问题的角度不大一致，其实并不存在非常大的冲突。相反，交互设计与敏捷开发方法能够结合起来，以更小的成本交付令用户满意的产品。Patton在这方面做了成功的尝试。 还是那个道理，方法只有是否合适，没有好坏之分，也许“交互设计”比较适合传统领域、成熟公司、时间资源充裕的时候，使用者在某领域中已经出于领先地位，目的是求稳，不犯错就是胜利；“敏捷开发”适合新兴行业、创业公司、时间紧迫，大家都在赶，谁先出头谁就能占得先机，或者作为挑战者进入某个行业，团队本身灵活，失败了损失也不大，重来的成本低。从这点上看，互联网行业、SAAS模式似乎更偏向于使用敏捷开发的方法，但敏捷绝不是在时间紧迫下的被迫放弃交互，而是主动为之的一种思想，并且要将交互融入其中（敏捷设计？）。 从另一个角度想，“交互设计”适合设计型公司，“敏捷开发”适合技术型公司，各个公司都有其强势的部门，这里就不展开了。 “交互设计”之于“敏捷开发”，有点像那个“大象与猴子”的寓言（一时找不到），最后结合在一起最好，又像楷书与草书，同样是写字，没法评价哪个好哪个差，也许结合一下又出现了很赞的行书。 再理解敏捷 # 《敏捷迭代开发——管理者指南》 有些需求在开始的时候是提不出来的，或者说没法细化的，强行的过渡需求分析是浪费时间的行为，到后来多半还是要改。 瀑布（其实Royce大大提出的瀑布模型初衷里也是有迭代思想的，不过被后人误读了）的问题是最后集中暴露矛盾，当然对需求固定的项目还是不错的。 敏捷迭代开发，如果断章取义是极其危险的，比如没有迭代的测试跟上，到最后发现问题的时候就已经晚了。 介绍了四种敏捷的模式：Scrum、XP（极限编程）、UP（统一过程）、Evo（Evolutionary Project Management），他们的共同点如下： Ø 拥抱变化，大问题分而治之，先解决最核心的，风险最大的部分。 Ø 会议室中集体工作，每日例会（<20min），站立会议，充分利用白板和墙壁。 （补：每日例会每个人说三句话：昨天做了什么，今天要做什么，碰到什么问题。） Ø 较短的迭代周期，通常一周到一个月，团队人数不要太多（小于十几人），太多了可分割为多个团队。 Ø 一个迭代周期内绝不再加任务，有多的需求放入以后的迭代，如果迭代周期内任务无法完成，可以为了时间点的要求，移出一部分任务到下一个迭代。 Ø 把迭代周期内的事情列出来，很小时间粒度（天为单位）的跟踪。 Ø 不停的发布/交付，让需求方看到结果，获取反馈。 Ø 需求方充分投入，包括需求人员一起办公，验收测试的迭代。 Ø 需求方代表要有话语权，不然半途杀出个老板说三道四是极其郁闷的。 Ø 轻文档，通过开发和测试来细化和纠正。 Ø 程序员自主选择任务点，安排时间点。 Ø 反对加班，这点其实很难做到，特别是在中国，呵呵。 Ø 极其多的口头沟通，其实这点对团队成员要求很高，特别是对中国的技术人员。 Ø 强调测试，更早的测试（TC编写早于coding），重度的测试，测试驱动项目。 敏捷估计与规划 Ø 敏捷的里程碑是功能驱动的，先完成可交付的最“重要”功能，重要取决于功能商业价值、生命周期、实现难度等综合的结果。而传统的瀑布模型的里程碑是任务阶段驱动的，到了项目50%的时间，可能进入“编码”，但对客户来说，等于0%。而且这样的模式会陷入“实现难度决定开发顺序”的不合理模式，因为这里有个不合理的假设前提：所有功能都能够完成、必须完成，中间过程对客户是透明的。 Ø 项目估计的不确定性是会累积的，80%×80%×……，所以开始订的项目计划，在一个月后已经面目全非，强行的遵守是没有意义的，而应该不断的修正计划，当然，更好的做法是一开始的计划中间留有一些柔性的内容。 Ø 随着时间变化，必然有新的信息出现，特别是瞬息万变的互联网业界，死守着开始的项目计划不调整是没有逻辑的做法，敏捷的迭代刚好权衡了变化的成本和不变的成本，就是：不变本次迭代，更新下次迭代，这是一个将项目计划细化粒度的做法。 Ø 需求唯一不变的特征就是“不断变化”（plus不断细化），敏捷的思想就是欢迎变化，拥抱变化。瀑布模型一次性完成的需求分析，会存在“过度需求”的问题，降低整体效率。 项目管理理论的发展，从开始混乱，每个项目自有一套，每个PM自有一套；到后来人们非常想订出一个统一的简单的流程，减少人为影响（瀑布模型等出现），；再后来进入灵活的敏捷，看似又变得混乱，实则有序。又是宛如那个哲学的三段论：见山是山—见山不是山—见山还是山；也如管理的三个境界：人治—法治—无为而治。 现实与浪漫 ＃ 《设计心理学》、《情感化设计》 《情感化设计》里面把设计的目标分为三个层次，即本能水平设计，行为水平设计，反思水平设计（有说是对应了心理学里人脑的三种不同的加工水平：本能的、行为的和反思的）。本能水平就是纯生理的视觉冲击，所谓第一眼美女，没什么好说的；行为水平其实就是《设计心理学》一书的内容了；而反思水平是大师的又一次升华，把纯心理需求也纳入了产品设计的考虑范围。 行为水平的设计，和我们现在的工作还是很接近的，能把产品做到用起来爽、贴心就已经很不错了，生活中还是有多让人不满的产品，而一般对现实不满的人都会是现实主义的。虽然大师举的都是传统产品的例子，但一些原则却是非常基础，让人印象深刻，比如： Ø 反馈：动作前的可预测、动作中的积极响应、动作后的可评估。 Ø 容错：一些貌似多余的强制性设计，不可逆操作可以后悔，“用户没有错，所有的错都是设计的错”。 Ø 简化：充分利用用户已有的知识，利用心智模型，利用标准化，利用一切。 当一个产品在行为水平上做好以后，就可算是一个优秀的产品了，但要做到伟大，大家都发现反思水平上的情感因素变得更重要了，所谓饱暖思淫欲啊，人总是那么不知足，当现实的问题解决了，就要开始浪漫了，当然也有对现实绝望而转向穷开心式的浪漫的，扯远了。只有更进一步的让人不但用起来爽，而且想想都或开心、或伤感、或恐惧……的设计，才会华丽丽的升级为ART（这里用纯大写来表达“艺术”的牛逼），也许iphone算（有人说，所有用iphone的人都有一个特点，就是不好意思说iphone不好用，呵呵），也许一些创意家居用品算（淘宝上很多）。 不过，对于要给大多数普通用户用的产品来说，这第二、第三层次的设计还是要挨个满足的，反思的设计现阶段最多只是面包上的果酱，真的做一个没有行为水平、只有反思水平的“卡洛曼茶壶”，那也只能给闲得蛋疼的用户们去“用”了。 现阶段，还是得默念一百遍：我们是现实的设计师，不是浪漫的艺术家…… P2P沟通方式 IM 原则上不超过2、3句就可以说清的事情； 不用讨论只是告知的事情； 不是很急的事情，担心打搅对方的时候； 在群体告知、讨论的时候； 有点上不了台面的事情。 电话<语气，语调等> 问题性质简单，最长2、3分钟可以完成沟通的事情； 对于区域跨度较大的沟通； 对即时性要求很高的沟通，电话往往好过面谈； 辅助email的手段。 面谈<肢体语言> 问题复杂，不见人担心产生误解的情况； 有求对方的时候； 通过电话或IM预约。 Email<书面> 延时沟通，可以好好研究如何最好的回复； 留下证据； 沟通有时差； 需要反复斟酌，仔细落笔不留把柄的内容； 适合出了问题需要有人背黑锅的场景； 一般重要的事情，有阶段性成果以后要发通知； 让老板批示； 请求资源。 短信 出差到某地、刚刚拜访客户有什么特别的情况。 群体沟通方式 IM群 适合时效性较强的信息传达； 不适合讨论问题； 调节工作； 最多30人左右不会丧失活力。 电话会议（视频会议） 适合参与人比较难凑到一起的情况 会议 明确会议目的、形式、议程，一定要有产出物和交付件； 参与人的预先准备，包括组织者的资源准备、材料分发，参与人的熟悉议程、预先思考； 会议上的民主集中制，收集大家的意见、少数几个人讨论、最后一个人拍板。 群邮 一般项目的日报、发布通知等； 不适合“布置任务”，一个任务一定要布置到一个人负责； 发给特定人，抄送群体 “好事情”的邮件，一定CC给收件人的老板； 最好的资源：老板 让老板做问答题是很累的，需要让老板作选择题； 更进一步，让老板作判断题（准备几种方案，做出自己的选择，说出见解，与老板进行讨论，深刻学习） 最后，依然要及时的问，不停地汇报，学会跟老板开条件，要资源（事情我做，黑锅你背，各司其职）。 可以自己背黑锅以后，必然碰到更大的黑锅，还是要让老板背。 如何与工程师合作 第一，流程。 理性的人会喜欢被规则管理而不是被人管理。 需求确认的时候相关人员一定要都参加，以免后期再发生测试、开发对需求理解的脱节；如果时间允许，开发应该尽早参与到需求评审中。 有一个流程化的规定来严格控制需求变更的事情。 第二，沟通。 站在PD的立场上，把自己作为产品的中心，要和各种各样的人交流，客户、老板、开发、运营、测试、客服、合作部门。 在交流过程中避免情绪化，要考虑产品怎么做更好，而不是去想如何说服对方。 每个人都有主动一点，才能形成互动的氛围，也可以减少信息不畅引起的问题。 避免吧对人的反感转移到对人的观点的反对上。 第三，自我修养 PD给出的文档在质量上更进一步，准确、全面、简洁，及时更新、保持最新。 考虑问题的全面性，随时多了解一点技术。 有的工程师你可以和他讲商业价值，而另外一些你与他讨论技术实现更有效。 获得认同的最好方法不是自己反复的解释某个观点，而死引导对方说出你想说的观点。 土老板破冰必杀技 # 在中国ebay为什么搞不下去？那帮拿着macbook坐在starbucks喝cappuccino的外企小资们怎么会比淘宝那帮土人更懂那些对着17寸CRT窝在脏乱差的家plus仓库里喝着西湖龙井的用户！” 目的是收集用户需求，时间有限，一般来说破冰只在开始的3、5分钟，而最重要的就是最初5到10秒。 尽快找出对方感兴趣的、熟悉的、擅长的，自己也懂一点的话题，同时要在去之前做一些功课，了解对方的行业、公司、老板。 如果用户土，我们就要跟着土，做出土的有水平的产品。 产品经理值得交的10个朋友 #延伸阅读——《赢在用户》 创业的朋友；投资界的朋友；产品经理前辈；技术牛人；用户体验高手（用户研究高手，视觉设计高手）；市场营销高手；聪明人。 学术界的前辈；媒体的朋友；人脉高手。 ☞你能帮你这些朋友带来什么？——先提高自己，才能相互帮助。只要你专注在一个领域，用心的去做3~5年，在业内就是top 10%。 ☞这么多高手，身边现在有么？——哪些人可以和你一起成长，最终变成这个梦幻团队的一员。 如何让团队/用户更开心 #延伸阅读《别做正常的傻瓜》 大中之小不如小中之大：送礼的时候后，在一个不太昂贵的礼物类别中选择一个比较贵的礼物，要比在一个比较昂贵的礼物类别里选一个比较便宜的礼物收到的效果更好。比如送一条400块的围巾效果好于送一件500块的衣服，我们应该尽量找一些高级的小玩意。 有用的不如无用的：最好的礼物应该是吃不掉、用不掉、送不掉也扔不掉的东西。比如有纪念意义的奖杯，刻上他的名字，千万不要是几瓶酒这种，能喝掉、能送掉。 需要的不如想要的：你应该把人们想买却舍不得买或者想买却不好意思买的东西送给别人做礼物或作为奖励。比如5星级酒店1000块一顿的高档餐券，更多的是心理满足感。 有选择不如无选择：奖励或送礼的时候最好不要让接受奖励或礼物的人自己选择。不然的话他会有“我放弃了另外一种选择的感觉，患得患失很不爽”，经典反例就是：奖励海南游或现金2000元。 小奖不如没奖：人们做事往往是出于自己的内在动力，而一旦与奖励挂钩，就变成了一个经济交易，做事的人会开始衡量投入产出的物质性价比，所以给小奖反而不如不给奖。惩罚也是如此，小的惩罚反而不如没有惩罚。 晚说不如早说：在期待的过程中，让员工的快乐最大化，从而增强激励的效果；让朋友在期待的过程中提前享受到礼物所带来的欢愉。如比尽早宣布奖励大家去海南玩，如果可能的话，在项目开始前就给出承诺。 一次送不如两次送：如果你打算给别人两件礼物的话，那么最好分两次给。因为快乐也是边际效用递减的。（同样的道理，很经典的结论：好消息要分开说；坏消息要一起说；大好小坏一起说；小好大坏分开说。） 公开不如不公开：工资体系最好还是不公开的好，以避免员工互相比较而心理不平衡，也就不必用涨工资的方式来进行协调了，因此避免了整体工资水平的提高。有个问题我好奇很久了，但是也不好问，对于能够知道别人工资的职位，是否是通过高工资来避免他们心理不平衡的呢？还有什么其他好办法么？ 涨工资不如发奖金：涨工资不如发奖金给员工带来的快乐大；同时，发奖金有比较大的回旋余地。对于这类物质激励，一般效用期比较短，发奖金是一次性的，涨工资是长期的，涨了就不好降回去，孰优孰劣一目了然。 最后记住，奖励或送礼的目的并不是真正给对方最大的效用，而是要让对方开心，并且感激和记住你。 有时候做一些项目，有一些经费，怎么花真有很大的学问，最后再强调一次吧，这篇说的是“道”，千万不要当成是“术”背下来了…… 沟通哲学 我们假设这个世界是真实存在的，接受假设的继续往下看……那么每个人认识中的世界都只是真实世界在其意识中的一个投影，由每个人的经历决定，彼此不同，或者说这个投影过程必然存在信息的扭曲。这也就意味着，路人甲输出的信息转变为路人乙的输入以后，因为处理机制的不同、知识背景的不同、主观意愿的不同等等，或多或少的会有改变，即—— 理论上严格的“充分沟通”是不存在的！换句话说，没有无失真的信息传输过程（真实世界是模拟的，就算是数字信号的传输过程无失真，但在源头上模拟转换为数字的时候，失真已经存在了，而且，最终为人所接受的时候，又转换为了模拟）。 基于上述前提，我觉得我们沟通的根本目的不是为了传输信息，而是把传输信息当作手段，通过沟通的过程，路人甲乙丙等等互相帮助，修正对这个世界的认识，使之尽量接近真实世界。简单说就是：沟通不是为了说服，而是为了更好地认识世界。 说服是为了输出你对这个世界的认识，把传输信息当作目的，但任何人的认识，基于我的理论，都是扭曲的，所以都应该持怀疑态度，只是程度不同而已。所以，不要一开始就试图与反对自己的观点对立，这样是没逻辑的，没人能保证自己的观点更好，举个例子，大家可能都有体会，自己也会反对自己过去的观点，那么有可能对方就是将来的自己。因为信息不对称，知识结构不同，所以观点不同很正常，关键是要充分表达，在表达的过程中，双方（或多方）会整合出更优的解决方案。也许你确实是对的，最终的方案很接近你提出的方案，但心态不同了，这个过程对大家的收益绝对超过你很强势的推销方案。 事情都有他的两面，那么上述的过程肯定有缺点，对了，就是效率。越充分的沟通花的时间越多，很多时候甚至是无法接受的。不少情况，我们会对自己很有信心，认为自己的认识更接近真实世界（但谁能肯定呢，现实一点吧，目的达到就好），所以为了提高效率不妨采用推销观点的方法。但这也是有技巧的，人们容易接受类似的观点，所以说服别人，应该渐渐扭转他的观点，而不是突然变太多。一个更好的办法是通过引导，让对方觉得好象是自己一点点想出了新东西，观点升级了。 所以，有效的沟通最终是“合”，而不是谁战胜谁，每次沟通都是一个大家互相帮助，共同提高（对世界的认识）的好机会。 个人品牌建设 每个人都应该打一口井，但并不只是为了自己，打井好比催化剂，在客观上会双向加速公司和个人的成长。 简单的打井方式——写，坚持写。 有了工作实战的体会与心得，才有东西可写；写出来，与大家讨论，才能提高，以便更好地作用于工作中。于是，工作于个人成长，相互促进了。 就业保障会降低一个人的竞争力，职业保障可以提高竞争力，假设有一天，公司突然不需要你了，这时候你不用去找工作，而是有一堆公司马上排着队请你去，这才是真正的保障。 打井的过程重于结果，最后的那口井，是自然而然的水到渠成。 可以把品牌建设的招数用到个人品牌建设上来：设计、市场、销售、运营、推广。 如何拨打工作电话 按照做产品的思路，先不谈“怎么做”，而谈“做不做”。 什么时候适合打电话—— 电话与email：电话适合紧急事情的沟通，可以获得最快速的响应，而email是典型的“非实时沟通”，适合重要不紧急的事情。 组合应用举例：发了一封重要email，过一会给收件人打个电话提醒他收信。 电话与IM：工作中尽量少用IM，效率太低，通常我们愿意用IM交流的事情，都不会要很久，尽量改打电话吧，一般不超过两分钟，电话很适合这类短暂的交流。 组合应用举例：一边电话，一边用IM把谈到的文件发送给对方。 电话与面谈：我比较反对在电话里长时间的讨论问题，通常是因为事情太复杂了，电话说不清楚，这时应该去面谈，少了肢体语言、纸笔白板，电话只适用于简单问题的讨论。 组合应用举例：面谈之前，先电话预约，直接跑过去不太礼貌。 小结一下，紧急、短暂、简单的沟通，适合打电话，并且和email、IM、面谈可以灵活组合应用。 如何缓解压力的讨论 工作中一定会有压力，关键是找对方向，多看看，多听听用户的想法，多和运营和市场沟通，在压力中找到方向，其实压力并不是因为忙，而是因为看不清方向，无力感。压力来源主要有：KPI的压力，事情推动不顺的压力，周围人给的压力。解压对策：寻求帮助和指导，做最坏的打算，生活规律，从心态上调整。 做PD不一定压力大，业绩压力、情感家庭压力，但说到底还是自己给的压力。工作，刚开始总是有个适应过程，一定要做成一些事情，各种因素的制约，随着时间的推移应该会好一些。舒缓压力，家庭上的压力，需要足够的承受力，不要去焦虑，其实家庭、工作、业绩的压力都好办，人际摩擦的压力最头疼。 个人生活要幸福，工作是生活的一部分。个人幸福满足了，要有自己的孩子，越多越好，哈哈。满足了个人需求，对社会的贡献，传承人类文明。没有压力就会工作懈怠，但要了解自己的压力能承受范围。 分享了三个压力很大的阶段，挺过去就海阔天空： 新人阶段的压力，没有自信，压力是很大的，老板的支持，旁边的人指点； 大项目的压力，很多要尽快做决定，把自己的压力转嫁给别人，看动漫解压； 今年上班了的XXX项目，老板非要做，业务方不配合，沟通上的压力。 压力来源，主要还是来自于自己，压力会使自己紧张，郁闷。压力的解决办法：事情解决了压力就会减轻或消失，找到解决的办法。每每我们会发现，开始觉得不可逾越的事情，处理完就觉得没有什么了。想开点，但不是混日子。感恩的心对待工作和生活。 分享了自己在阿里做的几个项目。我们的压力和一些老板比起来，其实小多了，暴了一个小段子，说马云对下属还是很严厉的，曾经将一个42岁的、见多识广的、有一定社会地位的男人几乎骂哭。 项目推进一点，压力就小点。没有明确落地方向的时候，就要基于商业价值考虑，自己多想想。 工作上的压力，来自对自己的要求，希望有成就感。运营从来都“没有逻辑”，经常“说话不算数”，压力大时要找人转嫁出去，缓解压力的方式：跑步，每周去三次，每次3000米，喜欢用比较暴力的运动解压。 业绩上的压力，多部门的配合产生的压力，印象深刻。 分享了一段完全没有压力的状态，感觉还不如有压力，所以才 来做PD，事情的推进，事情解决了就缓解了压力。 来做PD后比之前的压力大很多，由之前的生活压力转成了工作压力，压力主要来源于自己，对自身的要求，还有当前缺乏产品方面的知识储备，需求推进上很困难。缓解压力的方式：1、运动，让烦恼随汗水流出来；2、压力一定要说出来；3、同事的帮助及领导的肯定。 来淘宝之前，1年左右的时间，一直动荡，项目多次中间叫停，大家的状态都是没有动力做下去了，等着再次“被变化”，心里发慌的感觉。来了之后，工作范围、产品特点、团队都有很大变化，做的很累，感觉不是很适应。和业务上沟通起来吃力，和技术沟通比较顺畅，和大家的思维方式有关吧。自己不认可的一些东西，但为了推进事情必须要做，会比较痛苦，比如下班时间给同事打电话。解压方式：默念“尽人事，听天命”。 女性缓解压力比男性好一些。分享自己来taobao的原因及做的几个工作，很有趣的一点是，她原来不理解在阿里的男朋友为什么总是加班，男友表示压力很大，于是把她也介绍进了阿里，之后两个人关系就更融洽了。工作刚开始压力也大，完全不懂，渐入佳境。解压方式：周末看电影，逛街，大吃等，呵呵。 驻足思考 清晰的表达就是清晰的思考；未开口先动脑，想到为再说话。 被提问后，不要马上回答问题，衔接的好处有三点： 1.表示尊重以赢得尊重，营造对话的氛围而不是对抗的氛围。 2.确认回答的是“正确”的问题，搞清楚提问者到底想知道什么。 3.给自己赢得整理思路的时间。 衔接的三种方式： 认可 认可个人：称赞并感谢提问者。但是，不要过度使用“这是个好问题”之类的话。其他可能的回应：“我想许多其他人或许也有同样的疑问……”，“感谢你对我们的产品如此关注……” 认可事实：再次提及事实或信息，并评论“您说的很有道理，正如您提到……” 认可感受：在处理完“情感”问题之前谈“逻辑”是没有意义的。可以说“看得出来，这事儿让您很受伤……”之后可以紧接着让对方分享更多的信息，宣泄情绪。 询问 通过询问弄清问题：有时候对方甚至不清楚自己不明白什么，我们应该帮助其搞清楚，对方到底想知道什么。例如“我不能确定是否明白了你的问题……”，“你是否能重复一遍你的问题，具体一点……” 询问例子：了解问题本质的最好办法是请提问者给出例子。这样做也能让抽象的问题具体化，缩小范围以后，会好回答许多。例如“你能否举个例子，新版的页面在哪个地方体验不好？” 通过封闭式问题询问事实：询问事实会使情绪化的空气理性起来。例如“我理解你为何如此恼火，我想帮助你，但首先，我必须了解一些情况……你上一次软件崩溃之前，使用了哪个功能？”…… 调整 关键词：回答复杂的问题，可以通过关键词让自己的回答变得清晰有力。例如“首先，让我们回顾一下……，其次，……，如果资源允许，我们也会……” 改变层次： 小问题无法说，就说大原则：有员工问起自己的加薪幅度为何低于同事，你可以说“你知道，我不能跟你谈论另一名员工的工资，但是我们可以回顾一下用来评审加薪幅度的流程和标准。” 大事说不了，就说具体事：有人问起互联网行业很虚幻的问题，你可以说“我无法替别家公司代言，但我可以告诉你本公司都在做些什么。” 话分两头讲，重点偏一边：领导问如何减少需求变更现象，你可以说“需求变更的原因分两类，一类是我们可以控制的，一类是我们无法控制的，我来说说可以控制的那部分……” 负面问题，正面回答：有人问项目为何总是延期？你可以说“现在确实存在这样的现象，我们打算采取如下几种措施，来改进……” 言归正传：发问者常常跑题，较好的做法是认可他们的观点，但把讨论拉回原先的话题。例如“你说的这个问题确实很重要，但今天会议的讨论重点是项目质量，我们能否在会后讨论你的预算问题？” 最后需要强调2点：第一，这不是在教你耍技巧，沟通的目的仍然不能忘；第二，是个比喻，很多时候我们了解骗术，不是为了去骗人，而是为了防骗。 妥协不妥协？ 一个产品经理可能想要增加非常多的功能和特征以满足获取到的用户需求（更准确的说不是多少，而是产品品质），但是项目经理却想要尽可能小的控制工作范围，以保证项目在规定时间与预算内完成。好的产品经理和好的项目经理能在冲突中找到平衡。好的项目经理明白，一个项目真正的成功并不是看它是否在规定的时间和预算内完成，而是它是否达到了拟定的目标。好的产品经理则明白，如果项目被不断延期并且从未投入市场，又或者因为大大超过预算而被结束，那么所有的产品功能特征都会变得毫无意义。 讲故事的能力 产品做出来，还要卖出去。前者是“需求到功能”，可以对应到“产品设计”的只能，后者是“功能到卖点”，对应产品运营。 将这个东西对用户有什么用，能给用户带来多少利益，用户不用有什么损失。 一个是真正的用户为中心，还有个总是在说自己。 目标用户：人物； 场景：时间、地点； 碰到的问题：事情的起因，需求产生； 产品/功能：事情的经过，我们如何解决了问题； 用户收益：事情的结果，用了我们的产品以后，如何美好。 给用户讲故事很重要，打动同事也很重要，不然，如何说服老板，对于创业者来说就是投资人，给你钱给你人给你时间？如何说服一票人跟着你累死累活？如何说服合作伙伴与你拴在一条绳上？大家都说产品经理的重要技能之一是无授权领导，想让别人配合你一起做事，不能力压，只能让别人认同你了。某种程度上讲，这其实是比有授权的领导更好，第一，能说服很多人认同的事情，靠谱的概率总会高些；第二，用权力压人，是让别人“要做”，而无授权是让别人“想做”，任何事，真想做就好办了。 和运营的一次闲聊 运营：你们最喜欢和什么样的运营合作？ 产品：最喜欢什么说不清，但知道最害怕和什么运营合作。本质上是，产品经理和运营要互相理解，我会把运营也当做一种用户，然后会听运营说，但不会照着做，我们想知道的是，运营要做的事情背后的原因，真正想解决的问题，然后给出更好的产品方案。举个例子，你说要吃海鲜餐，我问你是馋了还是饿了，如果是饿为主，我可能会扔给你两个馒头。那种一上来就要吃海鲜餐，我不管，我就要吃海鲜餐的那种，是最怕的。你们这群人里面就有，呵呵，比如就要页面上一定要有个什么按钮，一定要把某个区域放大的……问你为什么，又说不出个所以然，只是说你先照我说的改。 运营：但是我们背着KPI，活生生的数字啊，要么我们一起背？ 产品：我们也知道运营压力大，背着KPI，但总是很着急的做事，是更不靠谱的，忙中容易出错。我说不好同一个产品的运营和产品共同背KPI是否是好事。一起背的话，虽然能让团队目标更容易一致，但对用户也许不是好事。呵呵，说不定公司就是这样设计规则，让产品和运营互相制衡。 运营：你是指大家会一起变成KPI动物，然后伤害用户？ 产品：这种情况很常见啊，举例子，很多年前，我就知道某个产品为了实现活跃用户数，用一些手段。当时，活跃用户数的定义是访问某个页面就算，所以就做成用户做其他很多操作的时候，都弹出一个页面，然后这个页面是产品里的页面。所以说，就算一起背KPI，也有个前提，就是KPI的制定要合理&大老板心理清楚KPI最关键的不是数字，而是数字背后的目的。 运营：但是，你给我吃两个馒头，其实只满足了我部分的需求？ 产品：用户的需求，我们也不是全满足的，因为根本满足不完，总会源源不断的出现。我觉得就应该让各种用户“欲求不满”，需求是需要控制的，控制不是目的，而是为了找出最刚性的需求，优先满足，都重要等于都不重要。且不说需求是否靠谱，只说能力上，就不允许，我们也会受制于资源。PD也有不同的压力，比如做了一个需求，结果没什么效果，对你们来说没什么，但PD就会遭受到其他PD、技术团队的压力。毕竟，做了这个需求就意味着不做另外一个需求，占了资源不说，没效果就没成就感，技术团队那边也很不情愿继续与你合作，长此以往，PD就很难再为你申请到资源做事了。我们会更注重长期，不管是用户，还是对团队内部，很反感“杀鸡取卵，涸泽而渔”，对在做不做任何事情的判断上，会更谨慎。 运营：我喜欢有运营背景的PD，你是不是也喜欢有PD背景的运营？ 产品：没错，就像技术喜欢有技术背景的PD一样，无非是能互相理解，不要搞得像敌人一样，呵呵。我们的目标其实是一致的，只是做事方法上有差异，资源永远无法满足所有的需求，不是坏事，而是好事，这样才能促使大家设计出规则，尽量避免做错误的事情。 校招产品经理的记录 加分点 激情。这会导致对这个行业、职位的了解，加之从言行中的流露，这是装不出来的。如果对互联网没概念，也没事，总得表现出对某件事情的激情，以及深入理解。 特点。这点很多时候是激情触发的，有特点，很重要，面试官一天聊十几个人，能记住的人一定是有特点的，比如有典型的Geek，各种墙外的主流网站他都有账号，天天玩；比如有坚持做个人知识管理的，好几年了，形成了一套自己的方法习惯。 聪明。这可以从成绩里看出来，但没成绩的人，如果有其他做的很出彩的事情，会更有加分。没办法，怪才潜力巨大。 沟通。顺畅，同时不显得咄咄逼人，从自我介绍里就能听出来，有些同学确实是磕磕巴巴，摘简历上的句子说，而有的人就能很自然，表达出自己的几个亮点，引起面试官的兴趣。另外，发现当过“学生会主席”的同学，在这里都会有点霸气外露了，可能更适合销售类岗位。 实干。应届生刚进公司，实干比战略、规划神马的更重要。简历上的某件事情，要体现出你扎实做事的一面。 潜力。我还是不知道怎么考察，只能凭感觉。 我常问的问题，挑几个有特点的吧。 你为什么来应聘产品经理？你对这个职位的了解和理解？一般都会说很感兴趣云云，然后我更关键的问题是“为此做过什么？比如，试着分析过什么产品么？为这次面试做了什么准备？”对比你是怎么想的，我们更想知道你有哪些行动。 你简历上提到的实习、项目等，你觉得哪一件事情，会比较像将来做产品经理要做的事情？谈谈这件事。 经常用互联网产品么？举几个例子，一个最常用的？假设你是它的产品经理，你觉得它主要有哪几类用户？这些用户的优先级，为什么？你自己是哪一类？通常都用哪些功能？说几个场景呢，有什么不爽的地方？怎么改进？你觉得他们为什么没这么改？……可以根据具体对话展开细节问答。 对于来霸王面的候选者，我会问，如果你是面试官，怎么处理霸王面的人？ 对于简历有多页的人，会问，你的简历如果简化为一页，你打算删掉哪些模块，为什么？ 也会问一些临时想到的奇怪问题，反正就是要问到面试者不知道答案的问题，然后看他探索答案的思路。 最后，邀请学生提问，你还有什么想说的闪光点在刚才的交流中没有体现出来？你有什么缺点，你觉得不适合做产品经理？ 最后，透露一些内情。 如果你的面试时间比较短，那被拒的可能性确实比较大，因为校招的批量面试，一天十几个人，面试官只能把时间留给更靠谱的人。除非你特别牛，面试官认为没啥可聊的了，直接让你过，这种情况，你会知道的。 有一些让你回去等消息的情况，并不是拒了你，而是真的拿不准，想多面几个人，然后在这几个人中再比较一下。所以，你也不要觉得这是一种委婉的拒绝，接受现实就好。 有关霸王面，简历肯定要筛，而且会更严格一些，毕竟没有笔试的筛选。然后会让他排队到最后，不能侵害按正常流程走的同学的利益，这是原则。如果最后真的没时间了，那也只好匆匆聊一下，肯定吃亏，但也没办法。
度眠 (修自行车的)
2012-08-12 16:22 3人喜欢
nate知其然
2012-04-19 13:09 3人喜欢
1. 提高人际交往能力的《高效沟通》，提高个人素质的《高效能人士的七个习 惯》。 但问题是，软技巧怎么能“学“会呢？？所以这些书适合那些已经在这方面积累了很多、做得不错，只要高手点拨以下就能功力大增的同学。
思维方法相关：比如《问题分析与解决》、《金字塔原理》，它是一套更通用、更抽 象 的做事方法论，如果一不小心学会了，可以指导我们去做产品、做需求、做项目、做 流程等。类似的还有《六顶思考帽》、《结构化思维》
aneasystone (疯了，都疯了！)
2013-07-22 15:04 2人喜欢
2012-05-17 23:54 2人喜欢
风过逝往
2012-05-09 10:57 2人喜欢
改变现状
降低理想
转移需求
笔记是你写在书页留白边上的内容；是你阅读中的批注、摘抄及随感。
笔记必须是自己所写，不欢迎转载。摘抄原文的部分应该进行特殊标明。
>人人都是产品经理
LEON
2012-02-22 17:56 44人喜欢
Susielovely (A little bit stronger)
2012-06-10 10:04 28人喜欢
蘑菇 (you never know)
2011-04-11 19:31 31人喜欢
[已注销]
2012-03-04 19:21 12人喜欢
melon (祝这世界继续热闹，祝我仍是我。)
2012-12-18 17:34 12人喜欢
度眠 (修自行车的)
2012-08-12 16:22 3人喜欢
nate知其然
2012-04-19 13:09 3人喜欢
aneasystone (疯了，都疯了！)
2013-07-22 15:04 2人喜欢
Susielovely (A little bit stronger)
2012-05-17 23:54 2人喜欢
风过逝往
2012-05-09 10:57 2人喜欢