我不是非常牛逼的产品经理，我努力争取成为那样的人
在这一年的工作中，我犯过很多错误，从团队管理，从项目规划，从自身的专业能力等等。
我看过很多的产品，运营经理的blog,有时候觉得全tmd太理论，有时候觉得我和他们的差距怎么那么大。
我给自己找过很多理由，一个只会动嘴的boss,经常会提出变来变去的需求！一个不稳定的团队，其他部门的诸多扯皮的事情！
我跟老吴说我真的很疲惫，真的很郁闷，我只想静静的研究我的产品，分析数据，写我的小程序，这才是我觉得产品的样子。而不是像我这个样子，无数的责任推给我，每个人用无辜表情看着我，装作很依赖我的样子，在我看来只是想逃避责任罢了，我也很想依赖别人，很想偷懒很想撒娇，可是我的上面直接就是boss大人，面对他我直接选择无语！
哎！貌似就这样吧，下次再说
-打动用户的需求，这个话题好像很废话，但是最质朴.有很多产品他们并不是在真正打动用户需求，他们是在发明用户需求甚至幻想用户需求，甚至逆着用户需求在做，在一小群高端用户里获得一种认可，就以为获得成功。
-在开心网之前，所有人都在抄袭FaceBook，但是一个比一个抄得像，颜色、界面大家都在抄，但是都不太成功。就是因为大家没有摸对用户的脉，最后开心可能自觉不自觉地，碰对了用户的脉，中国互联网用户到社交网站，跟朋友打交道，实际上是以开心、娱乐为主旨，所以这种简单、容易上手、好玩的小游戏，而且门槛非常低，这种小游戏就成了触动用户的点。
- 互联网产品是一个需要不断运营、不断持续打磨的一个产品。人家说好的产品是运营出来的，不是开发出来的。
- 好的互联网产品有两个特性： 首先它要能在一个点上打动用户。第二，它一定是一个靠持续改进、持续运营出来的东西。
- 今天微软如果还拿做软件这种几年磨一剑的思路做互联网，而不是用运营的思路，这叫缘木求鱼，等于你没有按照互联网产品的规则里做，你的产品自然不成功。所以最后微软也明白不能再用原来自己的文化来做，来找雅虎的人做，一定要用互联网的规则来做。
- 今天在互联网上大部分的产品都是免费的，用户把你抛弃的成本就是用户点一下，而且搜索引擎提供了很多便利性，让你找到很多同类的东西。所以在这种情况下，用户对产品变得更加挑剔。反过来这个产品激发了用户的很多需求。
- 无论你的想法高明或者不高明，都不如用户的选择高明，所以任何美妙的想法，不如先把它简单地做出一点点，就拿到市场上做实验，因为一旦对了，你马上能看到增长，你能迅速跟进。一旦不对，你调整的成本也很低。这样的话，你用用户来作为你的试金石，集小胜为大胜，通过点点滴滴的进展最后来获得成功。
- 虽然我们每个人都会说以用户为中心，以市场为中心，这话太俗了。但是正是因为这话太俗了，很多人做不到，只是停留在嘴面上。比如很多人做着做着就会又以公司为中心。
- 都说要做到专注和极致，但是怎么进一步理解？我的感觉是伤其十指，不如断其一指。在产品方向上一定要先学会做减法，而不是做加法。很多产品经理第一个阶段是学会加法，希望在自己的产品里做很多功能，其实这往往违背了互联网的规则。
- 反正产品是持续改进的，所以不要期望某一个版本做到革命，是靠很多个小版本来做到革命。
- 我要求自己首先是个大产品经理。事实证明，丁磊也好，马化腾也好，他们到现在都不脱离产品岗位，你搞所谓抽象的管理，你就容易失去所谓的方向感。所以我们还是要靠一个产品团队在做。
- 特别强大的推广，有时反而成为了一个把自己眼睛蒙蔽住的东西，让你没有意识到当时面临的危机。
1、Innovation, not instant perfection/创新不会马上就完美
Start rough, learn and iterate./开始粗糙，学习和迭代
2、Ideas come from everywhere/点子来自任何地方
Ideas can come from the engineers, managers, users even the financial team.Share everything you can/分享一切
3、Everything is put on the intranet, so employees know what is happening./任何事情都可以在内网分享
You’re brilliant, we’re hiring/你有才，我雇你
4、Founders Larry Page and Sergey Brin approve hires. They favor intelligence over experience. /Larry Page和Sergey Brin的雇人之道是，喜欢聪明人胜过有经验的人
A license to pursue dreams/允许追求梦想
5、Letting employees use 20% of their time on what ever they want./让员工用20%的时间做爱做的事
Data is apolitical/数据中没有政治
6、There is no “I like”, it is all about the basing decisions on data./不要说“我喜欢”，所有决定都靠数据立足
Creativity loves constraints / 创造力爱制约
7、Engineers thrive on constraints. /工程师靠限制发展
It’s users, not money / 是用户而不是钱
8、If you can successfully engage users, you can monetize them/如果你能成功吸引用户，你就能赚钱
Don’t kill projects, morph them/不要毙掉项目，改造它
9、Products that doesn’t seem to respond well in the market should be morphed into something the market needs, not cancelled /产品市场反响不好应该改造它以适应市场的需求，而不要轻易取消它
需求不等于功能，或者说你最终设计出来的跟用户告诉你的他需要的“功能”一模一样的功能并不等于他真正想要的功能。
用户告诉福特，他需要一匹更快的马，最终福特给用户的是汽车。
用户告诉你，他需要一个公告板，他要用来展示自己的新产品、自己的新资质荣誉、自己的特价供应、…，你就给他一个公告板，允许展示图片、超链接、产品、视频的“公告板”？
用户告诉你，他需要一个可以收藏自己喜欢的商品、可以合并在一起付款的功能，你是给他一个购物车还是给他一个收藏夹还是同时给2个？（Via）
产品设计人员在产品规划的初期直奔功能和表象而去，把自己的思维限定在一个很狭小的范围之内，用户想要什么就给什么，最后只能被用户带到沟里。何 况，很多时候其实用户是不知道自己到底需要一个什么样的功能的。如果我们能试图去挖掘一下用户提出需要“XX功能”背后的需求来设计一下，把他提到的这个功 能进行延伸与扩展，给他一个全新的不一样的功能，反而会获得更好的效果。
我们可以把得到的需求可以分为三个主要类别：
1）最显而易见的是人们讲述的、他们想要的东西。这中间有一部分是非常清晰的好想法，会寻找各种途径进入最终产品。
2）有时人们口中说出来的、所期望的功能并不是一个很好的主意，但是它们代表了一条通向下一个版本的路径：用户实际想要的东西。用户的需求有时是行不通的或者治标不治本的，通过与用户探讨这些建议，有时可以得出真正解决问题的、完全不同的需求。
3）人们不知道他们是否需要的特性。
因为用户群体之间存在着很大的差异性，所以确认用户需求是复杂的。我们可以把大量的用户需求划分成几个可以管理的部分，这样通过用户细分来完成。把用户分成更小的群组，每一群用户都由具有某些共同关键性特征的用户所组成，可以通过人口统计学的标准来划分，也可以通过心理方面的数据来描述。
细分用户不仅仅因为不同的用户群有不同的需求，还是因为有时这些需求也是相互矛盾的。对新手用户而言他可能需要把一个系统分成若干简单的步骤，而相对于专家级用户而言这样的分解可能会妨碍他的快速操作。很明显的是，我们无法提供一种方案来同时满足这两种需求，此时，我们需要要么选择针对单一用户群设计，要么为执行相同任务的不同用户群提供不同的方案。
撰写需求的几个原则：
1）乐观。描述这个系统将要做什么事情去“防止”不好的情况发生，而不是“不应该”做什么不好的事情。比如，“这个系统不允许用户购买没有风筝线的风筝”替换成“如果用户想买一个没有线的风筝的话，系统应该引导用户到风筝线页面”效果会更好。
2）具体。尽可能详细第解释清楚情况，这是决定一个需求是否被实现的最佳途径。
3）避免主观语气。需求必须可验证，就是说，它必须要能证明这个需求可以被满足。比如，“这个网站的风格应该是时尚、闪耀的”这样的需求是无法被验证的，我对于史上的定义也许并不符合你的，而Boss对时尚可能有完全不同的看法。
4）用量化的术语来定义需求。比如，“具备高级别的执行能力”可以用“要求这个系统的设计至少要支持1000个用户同时使用”来代替。
搞清楚了“用户具体需要的是什么”、“企业需要得到什么”这样2个问题之后，我们才能配合着网站的运营开始把用户需求和网站目标转变成网站应该提供给用户什么样的内容与功能，进入到具体的功能设计层面。作者：kent.zhu
pm一直很忙，最近boss大人让大家写工作流程和遇到的问题，pm的下属们提了很多问题，全部强调明确功能和项目需求。pm知道这些不是针对自己，但是还是觉得心里很不舒服，因为boss总是把责任推到接点pm这里。而下属推卸责任的目标也是pm。
美工在推卸自己为什么没有设计好这个功能，技术在强调需求讨论和评估为什么不详细，pm觉得很无辜，因为每次产品的会议都是一起参与讨论的，每个实现的功能和逻辑都是经过推敲的，pm总是会写文档，总是会画框架图，总是会把所有的字段都列举上，总是在满足boss的需求，也是在现有的程序逻辑上进行规划，可是每每boss不满意的时候，要承担责任的时候，pm总是会站出来，接受所有人的指责。
pm真的一直都很努力，每期功能单上的需求总是会越来越多，pm总是想一个一个把他们都解决掉，可是没有优先级，boss总是提的就是最重要的，要马上就执行，不管上个项目和功能做到什么程度，不得不停下来去做新的需求。pm总是幻想能不能在招聘个pm,因为pm觉得自己不是神仙，但很多东西是自己真的不知道怎么做！
pm是产品经理，pm不是万能的产品经理，pm不了解网络安全，pm只知道seo的皮毛，pm更不是美工对色彩设计达到很高的水平，pm也不是客服经常要解决商户的问题。pm做出的产品一定不是十分完美的要经过一些扩展和修正。pm也不是技术要帮忙设计数据库的搭建和去找适合的脚本。
pm有时候在处理自己的问题地时候，别的员工会跑过来问你，“我的防火墙怎么到期了，我怎么办”“某某的首页图片能不能链接到自己的网站上”尽管这个问题pm已经都回复很多次了，还有“广告图片能帮忙帮我上一下吗”“我的网站怎么打不开了，他们怎么就能打开”。
pm很想向别的pm一样，做一些用户需求，做一些数据统计，收集相关的反馈来提升产品，pm想一门心思的做细致产品，但觉得好难，因为pm太忙了，喘不过气的忙
2006年，傅盛从雅虎出来，重新加入了老东家周鸿祎的奇虎公司。此时的奇虎公司创立时间还不长，却已经有了一张未来的蓝图。在当时3721担任了三年产品经理的傅盛，带着三个人开始了360安全卫士的产品之路。现在，360安全卫士已经成为了家喻户晓、耳熟能详的安全软件了，而傅盛却改变了自己的人生轨迹，加盟经纬中国成为了一名投资人。
今天的傅盛已经是一名投资人了，所做的工作虽然有很大变化，但他仍然非常关注产品，以及产品团队。在他看来，一个值得投资的项目，一定有一个值得投资的产品经理。而被投资的产品，必须有自己独特的亮点和明确的思路。这是运营一个软件产品所必须具备的原则。
产品经理要把自己看成总经理
许多公司都面临着同样的一个问题，为什么产品经理这么难招？傅盛说：“产品经理既要有能够把握产品和市场方向的能力，又能够静下心来做很多耐心细致的工作，甚至于包括设计产品的细节。这种要求对于一般的技术人员来说确实是太高了。”这也是为什么在很多公司里，总经理就是产品经理。
但是，在很多的公司，产品经理其实是一个定义很模糊的角色：作为一个产品的负责人，这个角色通常承担着大量压力和责任，却几乎没有权力可言。由于产品经理本身并不是一个管理职位，这就对产品经理提出了非常高的要求：能够想方设法协调各种公司部门的资源，为之己用；如果产品在市场上出了问题，必须能自己肩负责任，承担风险；所有工作中最琐碎的部分，基本上都是产品经理一手完成，事无巨细。用傅盛的话说，这是一个生存环境很艰苦的职业。
如果用电影导演这样的角色来做对比的话，就可以发现与产品经理的工作很类似。在面对灯光、摄像、场景、剧务、场记、后勤、演员、音乐、后期等一大堆细琐的工作面前，导演必须坚定不移的努力完成自己的作品。因为电影拍砸了，人们只会认为导演无能，没有人会去责怪其他任何一个角色。由于权力并非绝对存在，即使是大导演，在面临那些不能开罪的人面前（比如制片人、投资人以及大牌演员等），也只有耐着性子慢慢打磨。
产品经理关键词：积极心态，关注细节，善于沟通
最开始的傅盛也和今天很多产品经理一样，一心只想做大事，对于很多细节的工作显得三心二意。加上他以前曾经开发过不少MIS系统，其中还有些是直接给国家各大部委开发的项目，面对一个产品页面上的小按钮，傅盛怎么也提不起兴趣来耐心揣摩。尤其是在最开始担任3721产品经理的时候，“上网助手”产品的界面几乎简单到了没什么事情可做的程度。
在初任产品经理的那段日子，什么事情几乎都得自己做。团队里一共没有几条枪，产品设计出来，连测试都觉得很难看，索性干脆罢工了。这种时候，积极主动的心态在做产品的过程中起了非常重要的作用。按照通常的情况，多半产品经理都会认为测试不给自己面子，但傅盛觉得，这是作为产品经理不必可少的思维方式。
从心态上来说，傅盛认为有两种人绝对不适合做产品经理。第一类是那些自以为是，刚愎自用的人。这类人通常独断独行，很难与人沟通。要么完全听不进任何意见和建议，要么阳奉阴违。另外一类则是那些耳根子太软的人，在面对关键问题上优柔寡断，甚至在某些争执发生的时候采用骑墙策略，无法对产品本身有实质性地推进。有意识地培养心态，是产品经理的入门课程。在遇到批评和意见的时候，第一要诀就是放弃反驳，即使别人说得不对，也应该至少静下心来听听，放下面子，才能真正做好产品经理。
关注细节是一个产品经理必备的能力。现在回想起来，当初觉得3721上网助手界面无事可作其实也是自己对细节不够关注的一个表现，傅盛回忆道。现在再看看浏览器的地址栏，里面有太多的产品设计可作，Firefox 3也正是在这里找到了突破点，一鸣惊人的。现在，面对产品界面、网站、宣传稿等，傅盛一眼就能看出里面非常细微的差别和不足，下属常常惊叹他的“眼尖”，也很头疼和他一起设计产品的界面或是琢磨如何宣传给用户，因为总会被他尖锐的指出诸多不足。
“其实我生活上是一个很马虎的人，平时都不怎么修边幅，以前也从来没觉得自己能在细节上这么关注。之所以现在能够到达这个程度，没别的秘诀，就是熟能生巧”傅盛介绍到，为了能让自己对产品界面等细节有更好的感觉，他不断的使用各类互联网产品，尤其是客户端产品。每个产品发布新版的时候，自己也是第一时间下载、试用。日积月累，细节能力就出来了。有句话叫“读书破万卷，下笔如有神”“熟读唐诗三百首，不会做诗也会吟”，讲的就是这个道理。
由于产品经理的沟通工作横跨开发、测试、运营、市场等多个环节，因此有效沟通是产品经理的核心能力。“产品设计工作中，80%的问题都是沟通问题”，傅盛这么定义。很多时候，产品从最初的设想到最后的发布，差别巨大，很重要的原因就是没有沟通清楚，一点一点的差异的累计，导致了最后的巨大变形。“我们看很多大片，最后被观众骂的一塌糊涂，我就总在想，难道这些导演们不知道自己拍的片子烂吗？很明显，他们自己也知道。但可以肯定的是，最初，在他们脑海里的片子一定是一部美轮美奂的样子。但是，就是由于和各方面资源的协调、沟通的误差，导致最后快成型的时候，完全不是自己想象的样子了”一直喜欢用电影做类比的傅盛得出这样的结论。为了能够沟通清楚，傅盛逐渐养成了“逼问”的习惯：即在表达完一个观点之后，要对方再表述一遍，还要把观点拆散从其它角度追问对方的理解程度，才算把一个事情沟通完毕。
具备猎狗一样的嗅觉，准确找到用户的甜点
当然，要具备产品观并不是一件容易事。“每一个产品都应该有一个明确的突破点，今天看，几乎没有任何产品，一上线就开始搭建平台而取得成功的。尤其是面向互联网的客户端应用产品，如果做成大杂烩，几乎不可能成功。这方面我们曾经见过中搜出品的网络猪，把浏览器、搜索、下载、聊天、邮件等所有的功能都集成在一起，摆在用户面前的必然是一个毫无特色的产品。”傅盛提道。
把握用户的需求来规划产品，尽管是一个目标，但绝不是被用户牵着鼻子走。更何况，踊跃提出“宝贵意见”的用户，往往都是一个小众，而产品规划的核心要点，是需要通过机制将大多数用户放在最重要的位置上。这一点几乎是很多互联网上曾经流行一时的小产品的通病，这些产品往往在进行产品功能规划上遇到了瓶颈，正是因为他们自以为是地认为把握了用户的心态，却忽略了产品本身的内涵。
尤其是那些小有口碑的产品，其产品团队很难自我否定，最终满足于单纯的产品功能，忽略了产品背后提供服务的那部分真正价值。甚至有些团队醉心于自身的技术，一味扩大产品线，无法在一个产品上做透，做扎实。“技术永远不是最重要的，只有和商业有效结合，才能把技术用好。”傅盛如是说。“比如iPhone，从技术本身而言，没有一个技术是独创的，但是，把很多实用技术捏和好，找到一个突破点、奇迹便会发生。”
做了投资人后，傅盛对此有更深刻的感受。“如果你把一个很领先的技术放在风险投资人面前，他们的眼里不会像我们一样闪烁着兴奋的光芒，反而，他会非常冷静甚至挑剔的追问，这个技术怎么应用给大众，能够找到怎样的商业模式，还有，这个技术的领头人是不是有足够的商业头脑，有没有足够的团队管理能力，有没有百折不挠的心态。所有这些，才是风险投资人们考虑的重点”。
产品经理的成就感
当然，产品经理是一项很有成就感的事业。产品经理是公司的“无冕之王”。行业内真正成功的产品经理，能成就一个企业。百度的俞军，从一个普通产品经理做起，创造了百度贴吧这个产品，最终成为了百度公司的副总裁。而傅盛，也从一个普通的产品经理，通过拼搏打造了一个全国闻名的360安全卫士，最终变为该业务的总经理，现在又转为知名风险投资公司的副总裁。提道这些，傅盛总是露出自豪的微笑：“有一段时间，我为了弄清楚网络游戏的机制，玩起了魔兽，我的老板当时怕我沉迷于此经常提醒我。我对他说，你放心吧，网游给我带来的成就感，哪有做产品得到的成就感大啊。魔兽在封闭的世界里最多升级到70级，我的产品呢，在开放的世界中边界无限，改变千万人的生活，我因此倍感幸福。”
如果你希望成为一个失败的产品经理，在遇到bug时，请立即动手修复它。如果bug可以立即被修复，为何要一拖再拖？PM应该是一位“执行者”，而非总是纸上谈兵的“思考者”。当问题出现后，必须在第一时间搞定它。当然，这样做可能浪费大量的时间，也可能分散精力，不过这是一位PM的最佳时间分配方式，不是吗？
If you want to be a bad product manager, solve a problem as soon as it becomes apparent. Why let something linger when you can take care of it? A product manager needs to be seen as someone who will “do” things, not just “think” about them. When a problem comes along, you must fix it as soon as possible. Sure, you may spend a lot of your time in this way, and it may distract you from other things, though this is really the best use of your time, isn’t it?
如果你希望成为一个成功的产品经理，在遇到bug时，请不要总是立即着急的修复它。不可否认，我们在遇到问题时，总是迫不及待的想改正。然而事实上，其实根本不用那么的十万火急，理由如下：
If you want to be a good product manager, do not immediately solve every problem which presents itself. It is often tempting to fix an issue as soon as it appears, though there are many good reasons to not rush to address problems:
1.如果迅速解决了问题，你可能会忽略问题的根本原因。在大多数时候，每个问题都有其根本诱因。在问题刚暴露的时候，诱因一般深藏不露，有很多的可能性。笔者认为，根本诱因最可能来自于需求确认阶段。多篇文章都探讨了这方面的问题，比如： Stop Gathering Requirements, Follow up on requests to learn more, Find solutions that address multiple problems.
If you fix the problem right away, you may not be addressing the underlying issue that caused the problem in the first place. In fact, in most cases, there is a root cause which is likely not visible on first glance. This applies to many areas in product management, most notably in addressing requests from customers. This has been discussed here in several different posts, including Stop Gathering Requirements, Follow up on requests to learn more, Find solutions that address multiple problems.
同样，在产品管理的其他阶段，这个理论也适用。有些问题可以很容易就找到根本诱因，但产品开发的真正挑战来自各种不稳定的因素。例如，有时候一款漏洞百出的产品在上线之初，只暴露了冰山一角：一个很小的Bug，似乎十分容易解决。另一个例子，开发过程中，团队成员对各项功能的优先级有争议时，靠“民主投票”来做决策，而忘了引发争议的源头：对产品远景、战略及计划缺乏共识。
However, this concept applies to other areas of product management as well. There are many times when “points of pain” which are readily apparent can be traced back to root causes. Challenges within the product development process may be attributable to several factors. For example, releasing a product with many defects may initially appear to be a problem easily solved by adding additional Quality Assurance resources, though the real problem may be lack of appropriate details in product specifications. As another example, disagreements about prioritization for development work may cause many to push for a voting system, though the disagreements may be caused by an inconsistent view of the vision, strategy, and roadmap.
医生治疗的是疾病，而不是治疗症状（译注：治疗感冒或支气管炎，而非咳嗽）。医生的任务不是治标，而是治本。对于PM而言，道理一模一样。
In medicine, there is a saying that doctors should seek to treat the disease, not the symptoms, and product managers would be well served to follow this advice as well.
2.让问题暴露一段时间，或许是让大家认识到其严重性的唯一方法。很多父母都会说，他们的小孩吃一堑才长一智——例如，不去摸滚烫的炭炉——若小孩自己被炭炉烫伤一次后，他们自然会明白那东西是摸不得的。在产品开发过程中，存在着同样的道理。当你试图请同事修改或改进某功能时，你需要解释这是为了什么。如果大家不明白改进的意义，自然会无动于衷。
Letting the problem subsist for a period of time may be the only way to get others to realize its severity. Parents often tell tales of how their children learned what not to do — not to touch a stove, for example — by letting the children try it once and learn for themselves that it is a bad idea. A similar approach can be taken in product development. Whenever you try to convince people to change or implement new ideas, you need to show them why the changes you are proposing are needed. Without understanding the need for change, people will cling to the status quo.
举个例子，假设你发现团队使用的需求管理软件存在着很大的问题，假如你希望马上修改它，或许得花大量精力去告诉大家修改的意义，还得制作demo进行说明。但如果让这个需求管理软件继续运转一段时间，让它自己暴露出弱点，可能是一种更好的办法。因为需求管理软件的问题，在新产品上线前，你会发现有些最初制定的需求并没有实现。此时，你可以告知大家这些遗漏的需求，但是不需要为之耽误了上线时间。如果你是正确的，要不了多久，大家就会意识到，因为使用了那个糟糕的需求管理软件，才导致产品出现一些无法挽救的Bug。
For example, you may want to implement a requirements management tool because of the problems you see with how requirements are managed. Rather than spending all of your energy telling people why it is needed and doing demos of the various products, you may be better off letting the current requirements process show its weaknesses. Perhaps you have a new version of your product which is close to release, yet you know that there are requirements which were likely lost along the way. Instead of insisting that the release be held up, you can foreshadow the issues before the launch and let the product be released. If you are correct, it will soon be apparent to all that requirements were mistakenly never implemented because of the faulty requirements management system.
提醒，本方法需十分小心的使用。作为PM，就算你本意是为了让同事们更透彻的看清问题，也不能忘了你是该产品最终成败的负责人。所以多数情况下，使用本方法时，最好选择小项目来作为案例。
This tactic needs to be used carefully. As product manager, you are still responsible for the product in the end, even if you are trying to teach your team a lesson or tell them “I told you so.” However, in many cases, it is possible to use smaller projects or specific aspects of the product as examples which can prove your point and make the case for change.
3.问题可能没有你想象中那么严重。每次问题出现的时候——产品暴露了Bug，用户发出抱怨，会议上的争论——看上去总是迫切得非解决不可。于是，PM不得不暂时暂停正在进行的真正关键工作——战略、计划、用户调研——而把精力用在四处“灭火”上。
Problems may not be as severe as you originally thought. Often, when an issue presents itself — defect in the product, complaint from a customer, argument in a meeting — there is a rush to resolve it immediately. A product manager will often break focus from the really important things — strategy, roadmap, getting out of the office to talk with customers — and instead spend energy on “fire fighting.”
然而，必须立即解决的Bug其实很少。同时，与PM应该着重思考的产品方向等问题比起来，这些Bug的重要性实在很低。每个Bug都有看上去万分关键的时刻，但过段时间后，它们似乎都变得无关紧要了。事实上，真正严重的Bug会迅速暴露出来。牢记这一点，会让PM把时间用在刀刃上，而不是每天都在处理危机。
However, issues are rarely so important that they must be resolved immediately, and seldom are they more important than the larger strategic activities on which a product manager should be spending his or her energy. In the heat of the moment, every problem appears to be major, though with time, the importance of most usually diminish. The truly severe problems will become apparent quickly, and this will allow you to focus more attention on the major issues rather than the crisis of the day.
4.花更多的时间可以找到更完美的解决方案。若在全面了解Bug之前，就急着去为Bug寻找答案，我们通常会选择脑海中冒出来的第一个解决方案。这可能也算是一个过得去的方案，不过若我们花更多时间来分析此Bug，找到其根本诱因，甚至来一场头脑风暴，或许我们能发现更完美的解决方案。当然了，花更多时间也不一定就找得到更棒的方案，但至少，花了时间之后，得到的不会是更少的备选方案或更差的解决方案。
More time gives you more opportunity to find the right solution. In a rush to find answers before we even understand the full extent of the problem, we often choose the first idea which comes to mind. While this may be an acceptable solution, with more time to understand the issue, look for underlying problems, and brainstorm solutions, it is likely that a better solution can be determined. While more time does not guarantee more or better solutions, it is at least certain that you will not have fewer ideas or worse solutions if you provide more time to consider your options.
下一次遭遇Bug时，请别十万火急。PM需要有战略眼光（不是战术），请先分析Bug，找到根本诱因，并衡量全局重要性，再对Bug进行解决。若不是每一次都着急解决每一个Bug，PM可以花更少的时间四处“灭火”，从而拥有更多的时间去思考产品战略——如何给用户带去更多的价值。
The next time a problem comes along, resist the urge to take immediate action. Take a strategic — not tactical — approach to problem-solving by evaluating the issue and considering possible underlying causes along with the overall severity. By not responding immediately to every issue, you will spend less time putting out fires and more time on the true value-adding strategic aspects of product management.
本文译自
作为设计主管，Peter Stern 已经领导 microsoft.com 重新设计了主页并且开发了五个不同的交互工具，这些工具被用于下载中心、产品目录、配置文件中心、 搜索 和注册等联机功能。 他为几个内部工具设计了用户界面，并且正致力于创建将于今年晚些时候发布的下一代主页。
从头衔上，您可能认为我主要关心的是 microsoft.com Web 站点几千个网页的版面设计。的确，这些确实是我所关注的。视觉上的吸引力是重要的，但是这仅仅是工作的一小部分。而最终的目的是确保整个站点运转正常。
我的意思是，人们通常在访问 microsoft.com 时，并未将它当作艺术作品来赞赏。而是为了获得有关产品的信息，或者有一些技术问题需要咨询，或是阅读有关开发商的期刊。所以网站的设计应该尽量清楚和有条理，以便他们能够容易地找到所需信息。
设计站点
在进行 Web 设计时–在设计过程中–形式应该服从功能。这种方法应用于我们站点的整个设计过程中。当然，我们有最新的 Web 工具，并且能够将各种可视的小配件上载到网页上。但是我们认为这样做将不利于为访问者提供有效的服务。
事实上，我经常发现一些站点未将重点放在功能上。常见的错误包括：
用户界面元素不一致.例如，同一个控件在不同的页面上功能不同，或者同一个功能对应几个用户界面控件。
导航栏位置不一致。决定站点的哪些页和功能需要在站点的任何页上都可被访问到。这就是应该保持一致性的”全局导航栏”。
不太注意或根本不注意基本的图形设计原则，例如排版式样、色彩和版面的设计。
相关元素和功能的随意分组。注意将元素放置在网页上的位置和目的。这可帮助访问者从其它相邻的选择和位置来推断某个链接的功能。
使网页过于庞大,以至使访问者需要通过典型的调制解调器速度的 Internet 连接进行长时间的下载。这并不是说不应该使用图形，但是您需要对它们进行精挑细选，然后用适当的压缩和颜色索引优化它们。
现在的 Web 站点仍然存在很多问题，这并不奇怪。毕竟，Web 设计”艺术”相对来说还是个新生事物。在四、五年以前，Web 页甚至是普通的。那时，人们好像认为他们的 Web 站点将会吸引访问者只是因为它们存在–并且，可能在某些情况下这种方法确实有效。但是这些站点一般很难看，并且更重要的是，它们真的难以使用。接下来便进入”看看我们能做些什么”阶段，在网页中加入了大量的动画、声音文件以及其它附加件，导致访问者需要长时间地进行下载，但是并未获得多少实实在在的内容。 如今的 Web 设计师们已经吸取了前人的经验和教训。好的站点倾向于简化和快速，同时在功能上有所提高。这是 Microsoft 的目标，而且我们最先承认自己所犯的错误（参阅”Microsoft 的 Web 简史”看一看以前的主页设计）。
设计错误并不总是显而易见的。有时在设计上对一个小元素的移动或更改将有很少或根本没有影响。但是，在其它情况下，它可能确实会对页面功能有所影响。而且如果说我们从过去几年学到了一些东西，那就是小的改动会使 Web 页的运行方式有很大的不同。
明确的流程
若要避免类似问题，我们为新服务（例如”搜索”）的创建或关键的 Web 页（如主页）设计了一个明确的流程。 每个项目都是在一定的基础上开始的，即我们有一个受益于我们站点上的页面、部分或用户界面元素的产品或服务。在早期的产品计划阶段（第 1 阶段），我被要求设计一些初级模型：大致描述页面、部分或功能的草图。然后产品项目组检查产品计划建议，看看此项服务是否可以为 microsoft.com 的访问者真正带来一些实惠。
Figure 1. Microsoft.com’s design process has three stages, beginning with a planner and ending with the customer.
如果答案是”可以”，那么此项目会获得批准，我们开始写项目说明书（第 2 阶段）。我们在第 1 阶段的草图和概念基础上创建并提出一个更为完整的计划。这时，我们一般还会开始可用性测试（一般会有书面的模型）以了解潜在用户将对计划中的设计做出何种反应。 在最后开发阶段（第 3 阶段），我们创建运行计划服务的 Web 原型，并且进行全面的可用性测试以及内部复查。然后完成站点的代码，修改程序错误，最后站点通过实际运转的 Web 站点向客户发布。
正如您所见到的，可用性在整个流程中扮演着重要的角色（参阅”创建有效的 Web 界面需要认真计划”）。我们可以为用户运行某项任务计时，这样我们就可以在产品以后的版本中对比相同的测试。我们可以使用这种方法进行度量，以确定一个功能的重新设计是否为客户带来任何真正的价值。 还有，我们将仔细地观察以了解可用性对象是否可以计算出如何正确使用新功能–我们称为”可发现性”的方法。有时这为我们提供了一些挑战。例如：在我们的站点上，在 搜索引擎 中键入一个词组或字会产生一列结果。然后我们请用户选择在这些结果中进行搜索，以便进行更细的搜索并且导向某一页或资源。但是即使”在结果范围内搜索”被明显地标记在深色标签上，很少有人熟悉它。一些用户认为他们正开始新的搜索，并且可能毫无结果。我们正在解决这个问题以确保客户可以利用 microsoft.com 上所有丰富的功能来提高他们对此站点的认识。
选项”在结果范围内搜索”看上去很直观，但不是非常易发现的。此问题一直是困扰我们的设计的问题之一。
最后阶段
大体来讲，站点设计是在发生冲突的需要之间求得平衡的艺术。一方面，我要将站点设计得尽量简单易用。另一方面，我要确保站点中所有强大的工具可为经验丰富的用户所用。与此同时，我还要为内部客户服务–Microsoft 产品项目组–他们对服务有特殊的需要。所以每天我都要解决一些非常困难的问题，经常处于很紧迫的情形中。我发现这种工作是鼓舞人心和有趣的。
这个职业非常需要更熟练的专业人员。我是经过一系列非常不一般的过程–在大学学习图形艺术，然后在多媒体公司设计 CD-ROM，最后加入 Microsoft 并开发应用程序–才获得这个职位的。非常奇怪的是，当我申请（并获得）这份工作时，我以前从来没有设计过 Web 页。但是我广泛的设计经历已经证明是非常有用的，并且我自认为已经验证了格言”成功的设计就是成功的设计”（不论是什么媒体）。许多设计问题对 Web 来说是独一无二的，解决这些问题的方法对于任何媒体都是一样的。
对于那些准 Web 设计师我的建议是，他们也应该尽可能地扩大设计背景。今天应该确保将一些 Web 工作作为互动设计培训的一部分–大多数好的设计学校已将其加入课程中。但是在排版、色彩理论、版面设计以及生产等方面的扎实的技术将仍然特别有价值。 在未来，Web 设计师们仍将会继续被要求给页面增加更丰富的多媒体内容，从而为 Web 站点的可视性和可操作性增加了新一级的复杂性和技术要求。作为 CD-ROM/多媒体设计师，要求我必须具有图形设计、视频、音频制作、动画等方面的知识和创作能力。我的预言是，Web 设计师也将向这些领域发展。
对于属于 microsoft.com 的我们–以及在 Internet 上的其它地方–那应该是一个非常有趣的未来。
了解您的观众。 调查一下究竟哪些人在访问您的站点，以及他们为什么要访问。新手或不定期上网的 Web 用户与软件开发商相比有非常不同的兴趣和站点需要。 使您的站点对访问者来说有所帮助。
为您的观众提供所需的信息。使导航元素保持一致，并且确保对访问率最高的区域进行明显的标记，是它们易于被找到。
使用清楚的消息
确保用户了解此页面的上下文，并且知道需要他们做些什么。如果在注册过程中您要用户输入姓名，那么就直截了当地说。不要让访问者自己计算什么，他们会感到沮丧，于是转到其它更简单的站点（例如您的竞争对手的站点！）。
保持一致性
虽然更改不同 Web 页的外观并不难，但这并不意味着您应该这么做。将主要功能–例如返回”主页”的链接或者执行一个搜索–放在每页的相同位置。在 microsoft.com 上，黑色全局导航工具栏的位置在四十多万页上都是一样的。
使站点可用
牢记设计和测试站点的可用性。确保用户可容易地执行任务以获得所需信息。估算任务时间和任务完成率，然后努力进行改善。如果新的设计没有在这些方面获得改善，那么就不要实施它。重新从草图（或最初的计划）开始并尝试其它方法。
保持简洁
说起来容易做起来难。尝试征求反馈意见。 有时新人可以很容易找到解决方案。
尝试新的东西
不要害怕打破常规，尝试一些完全不同的东西。如果您不试试，永远不会找到真正的答
很久没有写过对产品的一些想法，因为没想法，没有什么新鲜的感觉，如果做产品经理这样累，我当初会选择做个编辑。今天还问七同学是不是我在新闻组的时候，有编辑的天分。归入整体吧，今天谈谈工作吧
这些日子的工作很琐碎，但是我遇到的最大的问题是我丧失了思考的能力，因为疲惫，因为心和身体拧巴着， 因为我想着逃避拒绝着痛苦的蜕变，我动摇我开始质疑自己是否适合做产品这个方面，哎 胖子说我不思进取，我也这么觉得，蜜闺们劝我放弃了吧，至于吗这么为难自己。大叔则一如既往的让我改变自己，兄弟们的建议一半一半。
近期构架了一个项目，聚合大部分的相关网站，搞垄断的垂直性的领域。然后呢从前台的展现，到后台的商家操作，以及各个操作页面描述语言都要很细致。每个字段。数据流程的考虑。商家的易用性，头脑里很多东西都混乱散乱，所以我就想到什么记下什么，然后在把他们联成线，理清楚逻辑关系，当然Mindjet MindManager 8是个好东东
发现真是自作孽不可活，以前有个功能获取用户信息，然后自动推送到商家后台，结果竟然发现忽略了线上和线下的区别，竟然闹出笑话。
还有前段时间的seo研究，有了一些小小的成果，基本的关键词的自然排名都排到了第一页。没什么心得瞎猫碰上死耗子了，乱改的，不过研究关键词很重要。研究竞争对手的网站也很重要。呵呵当然谢谢土豆兄的相关指导。
今天一直都很郁闷，因为美工的小孩又走了，能不能有些职业道德，说走就走，boss今天对我没有爆发，但是很无奈，说我妇人之仁。我郁闷死了还是爆发来的痛快一些吧
还有一些小小感动，七同学说他想试试某很牛逼的某互联网公司总监一职，说要去的话第一个带我过去，我当时真啪啪的感动呀。谢谢兄弟们
其实降薪不降薪不是什么重要的事情，主要是我觉最近为什么会这样，每天都干什么，越是怕出错就越出错！一点方向都没有，是不是成长了所以都不想跟别人提起公司的事情，一切都要靠自己，原来有很好的前辈，有问题就及时的告诉我，有很好的技术在一起讨论，有很好的老大虽然对我要求很严格，老骂我，但是却教我很多东西！可是现在都只有靠我自己了，以前一切都是在他们的呵护中成长。有了过错也有他们给我补救，现在没有了！错就是错，没有人会承担，你勇敢就你承担，别人都躲都来不及！
从中应该学到很多了，从降薪中，boss是我很佩服的一个人，虽然有时候不知他说什么，那是因为自己根本就没跟上他的节奏，公司做到这个地步绝对是他自己的能力出众，虽然简单粗暴吧！自负的有些让人讨厌了！
1.应该很细心，我一直都马马虎虎的，一直都不以为然，果然有因就会有恶果
展板有错别字，展板上没有公告栏，展板是2m不是1.8m,什么事情都不过脑子，我整天在干嘛
2.理解能力有问题，为什么就不能多问一句呢，问到很细致
3.自己的规划能力有问题，可是我一点方向都没有
4.总是找借口
5.不想个管理者，性格有缺陷，能力不够
离开老大离开奇虎的时候总以为别人看好自己，总以为学了很多东西，总以为自己很有理想，可是发现现实自己什么都不是，自己在荒废什么，自己在承担什么，自己在忍受什么，决定改变自己，不能总是这样下去！
Recent Comments