我在锤子科技做的是产品经理，在嘟嘟美甲做的是产品负责人，似乎恰好能回答这个问题。&br&&br&我的理解，以下一些点是产品经理或者产品负责人会经常忽略的。&br&&br&&b&1. 任何事情要考虑全面，逻辑链条清晰。&/b&&br&&br&对产品经理来说，想出牛逼的点子只是副业，怎么把产品流程的设计顺利圆满没有遗漏地完成才是天职。&br&&br&比如，作为电商产品经理，除了正常购买流程，每个环节的错误页面有补全吗？每种问题的处理情况想到了吗？遇到网络信号不好时界面会是如何的？用户没登录、没绑定支付、没支付成功的时候交互如何？用户登录失败、绑定失败、支付失败的交互又是如何？&br&&br&所以，这可能是你初步想象到的正常页面逻辑：&br&&figure&&img src=&/4c14d41cef_b.jpg& data-rawwidth=&1024& data-rawheight=&768& class=&origin_image zh-lightbox-thumb& width=&1024& data-original=&/4c14d41cef_r.jpg&&&/figure&&br&这可能是实际的页面逻辑：&br&&br&&figure&&img src=&/c2e707eafd7b198b0a5ea_b.jpg& data-rawwidth=&1024& data-rawheight=&768& class=&origin_image zh-lightbox-thumb& width=&1024& data-original=&/c2e707eafd7b198b0a5ea_r.jpg&&&/figure&&br&&br&这其实是做产品时最常忽略的事。&br&&br&&b&2. 满足需求的功能 && 优质用户体验&/b&&br&&br&产品经理如果看到一些很炫的 APP，尤其一些很炫又相对比较成功的 APP，会误认为它们的成功完全归功于用户体验。&br&&br&我可以负责任地告诉你，包含交互、视觉在内的用户体验，在用户需求尚未满足前，都是废物。满足用户需求是 1，而用户体验是可以在 1 后面添加的 0.&br&&br&我见过 3D 效果做得简直像科幻片里的特效的 APP，同事用手机给大家演示，所有人都赶过来围观。这个 APP 有用吗？有用，但只有一个用途，就是拿出来让大家围观...&br&&br&再举个例子，你看看淘宝的页面：&br&&br&&figure&&img src=&/c48e01d49c43e99f6a8ac_b.jpg& data-rawwidth=&720& data-rawheight=&1280& class=&origin_image zh-lightbox-thumb& width=&720& data-original=&/c48e01d49c43e99f6a8ac_r.jpg&&&/figure&&br&你如果是信奉极简主义，恨不能把主页改成这样：&br&&figure&&img src=&/3e76be5decceee_b.jpg& data-rawwidth=&750& data-rawheight=&1334& class=&origin_image zh-lightbox-thumb& width=&750& data-original=&/3e76be5decceee_r.jpg&&&/figure&&br&当然，逼格高了，感觉用户视觉上舒服了。但你作为用户来用的时候，会发现特别难用，无从下手。作为大而全的电商网站，更多信息展示显然是比界面简洁更重要的。&br&&br&所以永远记得，先满足需求，再考虑加特效，duang duang 什么的。&br&&br&&b&3. 理解需求背后的原理和原因&/b&&br&&br&产品经理很多时候是需求承接方，有时需求来自老板，有时需求来自同事，有时需求来自用户。这时候，一定要分清一件事情，这件事情是非常非常容易被搞混的，就是：他们给你的是明确无误的需求还是只有实际的方案！&br&&br&比如，老板的需求可能是这样的：&br&&blockquote&给我做个客户端实时记录美甲师 GPS 的功能来。&br&&/blockquote&&br&作为忠贞不二的员工你可能就落实去了。但实际上，你需要搞明白老板为什么这么做。在再三的追问下，老板可能就告诉你他的原因是：&br&&blockquote&因为美甲师经常会为了奖励刷单，也就是不出门让朋友来下单。GPS 用来帮助判断这个。&br&&/blockquote&&br&所以你理解了老板的需求，那么下一步做的时候就清楚了：要查美甲师是不是刷单，没有必要实时做记录，这样增加美甲师端的流量消耗，也增加了服务器的负担。正常的接单时间都会大于半小时，因此完全可以将功能改成：&br&&blockquote&每半小时记录一次美甲师的 GPS。&br&&/blockquote&&br&任何人（包括用户，严格说尤其是用户）给你提需求时，有时候只是根据自己的需求拍脑袋想了一个方案建议你做，但作为产品经理，要做的是理解其背后真正的原因或者原理，转化为更合适的产品方案。&br&&br&&b&4. 有写文档或者做记录的好习惯。&br&&/b&&br&大公司会有详尽的文档撰写要求，但初创团队和小公司考虑到效率问题都很少有写文档的习惯。&br&&br&许多人会觉得口头表述和口头确认是初创时期自然而然的工作方式，实则不然。即使最粗糙的产品功能说明文档、交互文档和需求文档，都要比任何事情全靠口头解决要好。文档和记录是规范产品研发的重要参考，是当大家有了争执可供确认的凭证，以及最后产品版本验收的查验标准。&br&&br&半个月后，没人记得现在做的这个功能当初为什么决定要做，像这样尴尬的问题就不会出现。&br&&br&我平时用的记录工具都很常见，供参考：&br&&a href=&///?target=https%3A///%3Ffrom%3Devernote& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Evernote | 你的工作空间&i class=&icon-external&&&/i&&/a&
：会议/讨论的记录；零散想法/点子；脑图&br&Keynote (PowerPoint)
：交互；用户体验的想法&br&Sketch ：交互&br&Numbers (Excel)
：数据/信息的结构&br&&br&&b&5. 考虑将来可能的变化。&/b&&br&&br&除了空间维度上要考虑更多情况，在产品方面，还要考虑时间维度上的状况。&br&&br&包括但不限于：&br&&ul&&li&版本的命名和意义（不要让用户困惑）&/li&&li&版本的更新周期（不要让用户觉得烦）&/li&&li&强制改版的情况（旧的功能无法使用。强制改版显然不宜太频繁）&/li&&li&将开发功能的预备（与技术沟通未来将开发的功能，提早在代码层面有所准备，以防经常做太多改版）&/li&&li&提前考虑埋点的情况（用来做用户行为分析）&/li&&li&要上 App Store 的应用，在做以上这些考虑时，一定要把审核时间算上&/li&&/ul&&br&&b&6. 正确地完成事情，是衡量产品经理称职与否的标准。&/b&&br&&br&很多人问我怎么才算合格的产品经理或者产品负责人，我都会说关键词在于“完成”和“解决问题”，而不是“创造”、“创新”、“更美”和“更牛逼”。后者当然也重要，但应当只能算是锦上添花。&br&&br&如前面所说，产品经理不是那种闷头想牛逼点子的人，而是把老板对产品的定位落实到方案上、把同事们的需求落实到功能的配合上，把用户对产品的反馈落实到迭代改版上的人。&br&&br&举例来说，作为淘宝的产品负责人，你最重要的工作就是让用户很方便、很顺畅地买到想要的商品，其次是让商家很方便、很顺畅地售卖自己的商品，再次是让平台的营销活动很方便、很顺畅地进行。其它的都不重要。&br&&br&而作为百度的产品负责人，你最重要的就是让用户很方便、很顺畅地搜到自己想要的东西。&br&&br&我简单粗暴地总结了这样一个对比表格，你可以感受一下：&br&&figure&&img src=&/ee5c1bc141f51f0406549eeb2e16c1ab_b.jpg& data-rawwidth=&750& data-rawheight=&1334& class=&origin_image zh-lightbox-thumb& width=&750& data-original=&/ee5c1bc141f51f0406549eeb2e16c1ab_r.jpg&&&/figure&&br&&br&&br&因此，对于产品经理或者产品负责人来说，“整体使用流畅、没有硬伤”比“这个功能真酷真炫真牛逼”是更令人值得骄傲的褒奖。&br&&br&&b&7. 让大家喜欢也是很重要的小事。&/b&&br&&br&其实写着写着，感觉上面说的有的不算是小事了，但社交能力，或者说单纯地让别人喜欢你的能力，是我觉得最重要的小事。（...为什么不知不觉哼起五月天的歌来）&br&&br&既然产品经理的工作有相当一部分是在协调、推进、跟踪和核对上，那沟通和交流就是产品经理日常工作最基本的元素。能让大家都喜欢你不是件易事，比如面对工程师，有的产品经理会跪舔（“哥，给你买了新鲜的荔枝尝一下。顺便看看这个问题呗。”），有的产品经理会利诱（“最近这么辛苦，今天版本上线后，晚上请你大保健吧。”），有的产品经理巧言令色（“你看这个功能我已经跟老板大吵三天三夜，帮你争取成这样了，你要知足常乐的。”），总之要&b&&u&会说话&/u&&/b&，都是为了让沟通更快捷，毕竟产品经理不是真正的“经理”。&br&&br&这是两位产品经理在练习如何跪求工程师做需求的一幕（只是示意图，大家不要紧张。&b&没有产品经理在本次拍摄中受到伤害&/b&）：&br&&figure&&img src=&/fa260d4dd3_b.jpg& data-rawwidth=&4128& data-rawheight=&3096& class=&origin_image zh-lightbox-thumb& width=&4128& data-original=&/fa260d4dd3_r.jpg&&&/figure&&br&这是我最崇拜的老同事&b&大帝&/b&坐在工位上面不改色舌战群狮的壮丽一幕（冒着生命危险拍下宝贵镜头，还被恶狠狠地瞪视了）：&br&&figure&&img src=&/9dcdb65f7bfca5d31af629_b.jpg& data-rawwidth=&3264& data-rawheight=&2448& class=&origin_image zh-lightbox-thumb& width=&3264& data-original=&/9dcdb65f7bfca5d31af629_r.jpg&&&/figure&&br&他们都是我的榜样。&br&&br&&br&说完了。希望能帮到你。
我在锤子科技做的是产品经理，在嘟嘟美甲做的是产品负责人，似乎恰好能回答这个问题。 我的理解，以下一些点是产品经理或者产品负责人会经常忽略的。 1. 任何事情要考虑全面，逻辑链条清晰。 对产品经理来说，想出牛逼的点子只是副业，怎么把产品流程的设计…
&p&最近七年，我都在做互联网产品，其中前五年分别在创业公司和上市公司里，做别人的产品；近两年在创业，做自己的产品。&/p&&p&我的体会是：产品经理需要懂技术，创业者尤其需要。但前提是你总觉得有股憋不住的想要做点儿什么的冲动，如果打算混安稳日子，特别是在大公司，你什么都不需要懂，反而要小心别“知道的太多了”，傻人一生平安。&/p&&p&做产品这几年，和开发工程师打交道最多，和他们交流通常有两大忌：&/p&&p&&b&一.
忌不懂技术&/b&&/p&&p&更准确的说，是不能缺乏设计、开发一个互联网产品基本的技术常识，比如至少要清楚一个网站从不存在到能被用户访问，需要哪些必须的环节；也要明白一个App从你的脑海走到用户的手机里，需要经历怎样的过程。&/p&&p&有常识，当然不一定就能做出好产品，但没常识，就很象在村里呆了半辈子的人乍到城市，一举一动即使小心翼翼，也没法儿不透着突兀和不和谐。&/p&&p&很多公司都有完全不懂技术的产品人，大多年龄较长，也许是互联网出现的时候，他们已经过了充满好奇和渴望未知的年龄，不愿意放低身段去学习新东西，喜欢只凭着想象和自己的生活经验就开喷，间或以若干近期热门关键词作为点缀，以示自己尚蹲在潮流尖端。&/p&&p&这样的人也许能忽悠某些领导，但一定不招工程师待见，他们可能什么都不说，但心里已经开始等着看笑话，交给他们的开发需求，自然也是能拖则拖、能蒙则蒙。&/p&&p&&b&二. 忌懂技术&/b&&/p&&p&我遇到不少工程师喜欢说：“只要产品需求明确，技术上一切都能实现。”&/p&&p&这句话听起来相当豪迈，也让产品经理大为放心，觉得技术真是产品的坚强后盾。但其实传递了一个特别糟糕的信号。&/p&&p&当工程师这么说的时候，潜台词是：“你弄好你自己的事儿就行了，别来管我！”而且这种说法隐含着一个乐观但显然并不现实的假设：技术是无所不能的，他（掌握技术的人）也象灯神一样，可以实现你的任何愿望，只要你能明确的描述它。&/p&&p&我不知道阿拉丁说完愿望之后，假如胆敢继续追问灯神将具体采用何种技术方案来实现的话，会不会被塞到灯里，但我知道很多工程师在发现你关注技术层面过深的时候，都会有种领地被侵犯的感觉。&/p&&p&这就是工程师维护自己专业槽的本能，与行业中其它角色相比，工程师地位不是最高，待遇也不是最好，还经常加班加的要死要活的，唯一得天独厚的优势，就是专业槽比任何角色都深。关于产品、关于UI、甚至关于商业模式每个从业人员都能喷上几句，要是说到用户体验，那更是连业外人士都敢大喷特喷而没有任何心理负担：反正我就是用户嘛，越傻越光荣。而一旦涉及到代码，大多数人就直接晕菜了。想想那些UI设计师的苦逼段子，工作时没有喷子们指手划脚的干扰，真是上帝赋予工程师独有的恩赐。&/p&&p&所以当他们认为有外人正试图跨越这条槽时，自然会有所警惕，甚至体现出抵制和敌意。当一个产品经理发现工程师开始比较密集的使用术语或拼命把简单问题往复杂了说，你应该知道，他们在槽边开始向你射箭了。&/p&&p&从整个产品乃至公司的角度来说，各个专业角色之间的专业槽都是应该被填平的，产品经理不该对工程师玩挟天子以令诸侯，不要总假装自己是用户的三个代表，动不动就拿想象中的“用户需求”当“奉天承运”来用；工程师也不必总装灯神，假装无所不能很累的，工程师之间必有能力高下之分，其实有时候功能做不了或做不好，纯粹只是因为工程师能力所限。如果彼此坦诚一些，大可以提前有效沟通，尽可能避开那些投入产出比过低的部分，有不少工程师不愿意拿出来讨论的技术实现上的细节，都是值得产品经理参与进来的，在这些细节上如何取舍与抉择，会对产品的开发进度、性能甚至功能带来极大的影响，如果沟通到位，往往可以让开发工程师少做大量无用功。在我开始自己动手写代码之后，对这一点有了越来越深的体会。&/p&&p&下面就说说我为什么开始学写代码，算是回答问题的后半部分吧。&/p&&p&在我做互联网产品的前五年里，我对技术的了解仅维持在常识范畴，能够手写的代码只有html和css，连js都不会，更别提任何适用于Web开发的编程语言了。我一直认为自己无法完全亲手写一个哪怕是最简单的动态网站，是作为互联网产品人员，很大的缺陷和耻辱。&/p&&p&工程师们一般倒不这么觉得，和他们聊天的时候，有时顺嘴喷一些对技术架构或某些技术问题的看法，立刻遭到赞扬：“你很懂技术嘛！”这时马上打着哈哈说：“懂个p啊，我连hello world都不会写，完全是纸上谈兵。”于是嬉笑声中，一群人把手里的箭收起来了。&/p&&p&但我压根儿就TM不想只能纸上谈兵，2009年，我不顾当时三十二岁的高龄，悍然决定要学Ruby，买了书、装好环境开始看书，敲代码，坚持了几天，然后失败了，考虑到也许Ruby对我来说太难，又尝试了Python，结果还是失败了。消沉几天后不死心，又买了一本iPhone开发的书，还趁机决定买了台27寸的iMac，但悲剧是只翻了翻书，连Xcode都没敢下就直接放弃了，这书上什么都不讲的啊！上来就是大段大段的代码啊！而且obj-c的代码都巨长，完全看不懂。&/p&&p&后来我想，这件事有两个收获：一. 发现了自己智商的边界。二. 我有了一台iMac。&/p&&p&转眼又过了一年多，想要自己动手做一个iPhone上的App的感觉越来越强烈，快压抑不住了。于是在某一天，我好了伤疤忘了疼似的把那本几乎没有折痕的iPhone开发基础教程又翻出来，等待Xcode下载的过程中，暗下决心：看不懂我也把它背下来。&/p&&p&后来发现笨办法至少对我来说，还挺管用的：照着书敲代码，能正常运行的话，就合上书，再敲一遍。一般重复四五次就能记得很牢了。合着书，劈里啪啦熟练的敲着自己还不知道是什么意思的代码，加上Xcode的自动补全很给力，几分钟就可以折腾出一大屏花花绿绿的代码，而且还能在iPhone上运行，这时会产生一种已经会写iPhone App的错觉，很奇妙。&/p&&p&人的大脑也很奇妙，你如果已经背下来了，本来不理解的就会慢慢自动理解，就这样背了一段又一段代码之后，突然发现：我明白是怎么回事儿了。之后就开始给自己提出各种小的不能再小的功能需求，尝试用这些代码去实现，每实现一个，都欣喜若狂：我能显示按钮了！我能弹出对话框了！我能写滚动列表了！我能发一条推送信息了！??&/p&&p&这些事儿在熟练之后，也许就像喝口水一样平淡，但却能给初学者带来巨大的快乐，我一直觉得，能否始终保持如初学者般的热情、专注，决定了在做某件事时能走多远，能做多好。&/p&&p&由于书上所用的Xcode版本问题和我用的不同以及一些印刷错误，书上的代码不会总是百分之百能运行，有时会报错，只能上网用尽一切办法搜，搜索的过程中，就会慢慢看到一些专门的技术论坛、Blog，最终不可避免的会发现Stack Overflow这个神奇的网站，你遇到的大部分问题，都能在上面找到答案。&/p&&p&当实现书上的功能已经不能带来狂喜的时候，就会忍不住想把自己束缚了很久的各种idea放出来了，终于可以亲手去做它，而不是局限在画画原型图、写写需求说明最后还要虔诚的擦拭神灯，呼唤灯神们显灵这样隔靴搔痒的做产品。&/p&&p&开发的过程对我来说充满了乐趣，因为写代码的时候，世界变的简单而美好，某个做法对还是错，你不需要自己反复猜测，也不需要和任何人没完没了争辩，编译器就是神圣的裁判。你的每个操作都能得到及时、明确的反馈，而且拥有近乎奢侈的试错机会，从这个角度来看，编程的乐趣倒是有点儿象玩游戏。&/p&&p&当然也会遇到无数的问题，Stack Overflow、Github、Bitbucket、mailing list会慢慢成为你的朋友。&/p&&p&在能够独自写出一个iPhone App并把它放到App Store上之后，我又发现还需要再学一门语言，用来开发网站以及需要在App中调用的RESTful Web Service，于是不顾三十五岁的高龄，再一次悍然打起了Python的主意，有了学obj-c的经验，知道关键是要能狠得下心和静得下心来，看什么书，其实区别不是特别大，所以我就用了免费的Learn Python The Hard Way，用前面提到的方法，跟着做了一遍（前半部分比较简单，可以每天做上十几个exercise，后面速度可能会慢一点儿），了解了Python怎么写之后，马上开始看Django Book 2.0，只看到第九章，就等不及用同样的方法把Django Tutorial做了两遍，接着惊喜的发现已经可以写一个简单但完整的网站了。然后很快试着用Django写了一个特别小的针对某垂直领域的工具类网站，上线跑了一段时间，昨天晚上结束免费试用，开始收费，现在看到已有几个付费用户，我很欣慰。&/p&&p&至于技术需要懂到什么程度，我觉得要是花几个月学的东西就够用一辈子，这买卖也太划算了，尤其是在技术领域，一定会需要持续学习，但对于我来说，已经没有资格象十几二十岁的年轻人那样仅凭兴趣广泛的学，我目前对这件事的原则非常功利：马上要用到的，能显著提高效率或者公认是最佳实践的就学，否则就先不学，尽量不折腾、严格控制投入的时间和精力。&/p&&p&比如写好的代码放到Server上，虽然只要能跑就算是部署成功了，但公认的最佳实践是使用virtualenv隔离Python环境，这样可以减少以后很多的麻烦，那就值得多花时间去了解，去应用；使用Fabric配合Git进行自动化部署可以大大提高效率，那就也值得花时间去学怎么用。&/p&&p&我也知道可以用Memcached或Redis来做缓存，提高应用性能；或是用Rabbit Mq和Celery来做异步队列，可以改善同步执行耗时较久的任务给用户带来的不爽感；还有Node.js似乎比传统的Web开发语言更适合做RESTful API ?? 不过这些都不是目前最紧迫的问题，所以虽然我还不会而且确定会有用，但先不去学。&/p&&p&一没留神，喷了几千字，还是打住吧，看来中年男人的啰嗦算是没救了。&/p&&p&最后还是总结一下，就一句啊：&/p&&p&&b&产品经理懂技术 ＝ 流氓会武术&/b&。你要是觉得帮派够大，自己脑子又好用到可以当师爷，那不会武术也凑合；要不巧是个和我一样没什么团队精神，又老喜欢独来独往的流氓，还想只凭着脑子就能连点儿防身术都不练，恐怕很容易被人打成爬行动物。&/p&&p&比较严肃的总结是：产品经理懂技术，在没资源的时候可以用最低成本把事儿办了，有资源的时候可以把资源用的更有效率。&/p&&p&----------
&b&广告&/b&：&/p&&p&冷启动是我和几个朋友发起的产品经理培训项目，可能是你能找到的类似课程中，最务实的。&/p&&p&&a href=&///?target=http%3A//mp./s%3F__biz%3DMzIzODAyMDQxNA%3D%3D%26mid%3Didx%3D1%26sn%3D642ffe92adf%23rd& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&mp./s?&/span&&span class=&invisible&&__biz=MzIzODAyMDQxNA==&mid=&idx=1&sn=642ffe92adf#rd&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a& (二维码自动识别)&/p&
最近七年，我都在做互联网产品，其中前五年分别在创业公司和上市公司里，做别人的产品；近两年在创业，做自己的产品。我的体会是：产品经理需要懂技术，创业者尤其需要。但前提是你总觉得有股憋不住的想要做点儿什么的冲动，如果打算混安稳日子，特别是在大…
谢邀。&br&没有不可靠的数字，只有不可靠的看数字的人。纯银说的东西，其实都是常识，我觉得本来没讨论的必要，但遗憾的是，在产品经理这个行当，很多人连常识都搞不明白。大公司唯kpi至上的原因，追求规模而不是体验或质量，一方面原因是大公司病造成的专业性缺失，一方面是之前的网民增长人口福利太好了，抢地盘都来不及谁还能太顾得上质量所以都是规模至上，这两方面是根本原因，但还有一个不可忽视的原因是，不少站在高位的产品经理或中高层管理人员，缺乏基本的产品素养，只凭着自己老旧的经验做判断。&br&&br&下面具体说下我对数据的理解。&br&一，对于数据在产品决策中扮演的角色，我的看法是，数据有价值的，但不是所有决策都可以找到合适的数据来验证或评估的，即使可以，还要考虑获取这些数据并分析这些数据的成本。而互联网产品迭代极快，等你跑出这些复杂的数据模型来验证决策时，黄花菜都凉了。所以，很多时候，你根本指望不上数据，只能通过基于经验或直觉来决策产品方向或功能设计，直接上线后通过市场验证效果，根据效果快速迭代。即使要跑数据，也只是辅助决策，整体上产品经理本身的产品感觉至关重要，也许做真正的产品经理（非执行而是有重要决策权），是非常需要靠长期全方位的积累（也就是所谓的天赋），不是随便找个智力正常的人简单训练就能胜任。&br&&br&二，对于数据在评估产品效果中扮演的角色，这个就得说互联网产品的本质，其本质是体验。大多数互联网产品提供的是服务，拼的是体验，体验这东西，可能通过规模数据来评估吗？（android手机出货量这么高，就代表比iphone产品好吗？）可能通过一两个指标就能量化体验吗？（android机经常标榜xx参数比iphone好，就代表比iphone产品好吗？）所以还是一样的道理，要量化评估产品效果，往往需要一个复杂的数据模型，而互联网公司，可没这个功夫慢慢构建这样的数据模型，成本太高了，而且老板也看不懂。&br&&br&以上。
谢邀。 没有不可靠的数字，只有不可靠的看数字的人。纯银说的东西，其实都是常识，我觉得本来没讨论的必要，但遗憾的是，在产品经理这个行当，很多人连常识都搞不明白。大公司唯kpi至上的原因，追求规模而不是体验或质量，一方面原因是大公司病造成的专业性…
是时候在知乎上找个问题，来记录一下这段时间，做产品的感悟。&br&&br&&b&1、不要改变用户的既有的体验和操作方式，除非你在满足用户原来需求的基础上，做的更好。&/b&&br&&ul&&li&4.5版本的扫一扫，还只有扫二维码功能。而5.0增加了另外四种新的功能，这时候就需要一种新的交互方式。比如，进入一个新的桌面，像百度一样罗列出所有的功能，然后让用户选择。这样的交互对于微信是不合适的，因为很多重度用户，原来点击扫一扫就能扫二维码的体验被破坏了，尤其在登陆网页版，关注公众号，加好友，线下微信支付都要依赖扫二维码功能时。或者想path一样，点击一下，弹出所有的功能。但这样的交互，会让一些普通的用户，切换功能的成本变高。改了很多版本之后，最后发现，我们用的是摄像头，那为何不考虑一下选择滤镜的交互方式呢？用户选择一种扫一扫的功能时，就相当于选择了某一种神奇的镜头，能够帮用户进行识别。&br&&/li&&li&5.0的新版本，我们去掉了一些表情。在内部体验时，其实已经出现了很多不满的声音。但没有想到发布后，用户觉得这简直不能接受。所以改变用户原来的体验，除非你能给他更好的一套表情，不然不要轻易的拿走他手里已经有的东西。&/li&&/ul&&b&2、用户不是专家，不会考虑产品背后，技术实现的机制。&/b&&br&&ul&&li&扫街景做出来后，只有老大一人坚持要放在扫一扫里面。而我跟很多“专业的评论家”想法一样，认为扫街景，技术上并没有使用用户的摄像头进行识别的动作。而仅仅是上传了用户的地理位置。跟其他的四种扫，是不一样的。应该放在附近的人里。叫做附近的街景。但是发布后，从微博上，普通用户的反馈来看，扫街景成了打飞机的第二大热点和讨论话题，甚至出现了用户的编造的段子。（场景：老公：“亲爱的，我今晚加班，不回去吃饭了。”老婆：“好啊，亲爱的，扫一扫街景给我看看好吗？”老公。。。）所以，普通用户不会逻辑性的考虑背后的技术实现，只要好玩，好用，就满足了用户。&/li&&/ul&&b&3、做产品，不要看虎嗅、36kr这两些网站，简直就是写科幻小说。&/b&&br&&ul&&li&如果真正开始做产品，不要去看那些评论家如何评价你的产品，that's Bullshit.你会由于跟着那些评论家一起陷入深深的意淫而不能自拔。但是发布新品后，可以去看一下科幻小说，就当是放松吧。&/li&&/ul&&b&4、真的可以把产品的欢迎页，做成发布会。&/b&&br&&ul&&li&从4.5开始，一首《一无所有》加上那个跳跃的火苗，其实就是在每个用户的手机上，开了一场崔健的个人演唱会，虽然只唱了一首歌。但是让所有的用户知道微信推出了一个全新的跟“声音”有关的版本。&/li&&li&5.0的打飞机，同样也是一个游戏的发布会。最开始，有想过用坦克大战的图片和声音，做一个动画。但是没有拿到版权。于是便想到另外一款飞机游戏，本来只是要做一个动画。但是发现如果能让用户操作一下，体验一把，效果会更好。变做了一个打飞机的小游戏，而且一定是默认把声音打开。后来，既然我们自己做了游戏中心，为何不把这个游戏整套接入游戏中心的排名和送心机制呢。于是，我们便看到了万人空巷打飞机的场景。几乎所有的用户都知道微信推出新的版本，而且都迫不及待的去更新。比开一场产品发布会的影响力更大。&/li&&/ul&&b&5、做到贴心。&/b&&br&&ul&&li&5.0发布的时候，扫一扫的扫条码和扫二维码仍然是两个入口。但是我们发现用户在扫条码的时候（他以为自己在扫条码）功能常常停留在扫二维码上，用户忘记了切换功能。所以我们做了扫二维码可以扫条码的逻辑。数据证明，这是非常贴心的设计。每天扫条码的量中，相当一部分来自二维码的入口。&/li&&/ul&
是时候在知乎上找个问题，来记录一下这段时间，做产品的感悟。 1、不要改变用户的既有的体验和操作方式，除非你在满足用户原来需求的基础上，做的更好。 4.5版本的扫一扫，还只有扫二维码功能。而5.0增加了另外四种新的功能，这时候就需要一种新的交互方式…
更正下马力的说法，产品经理和产品爱好者不同的地方，就在于一个一直在做事，一个一直在研究&br&&br&--------------------更新----------------------------------------&br&&br&&br&以下负能量过多，玻璃心患者请绕道&br&-------------------------------------------------------------&br&说说我昨天的工作吧。&br&9:15
到公司&br&9:30
看昨日的产品数据&br&9:40
收发邮件，这时会有开发或者测试说遇到的小问题，需要解决&br&9:50
发昨日的日报&br&10:00
项目晨会，大约持续半小时&br&10:30
商务合作部分出了问题，找了公司商务对接的人员对方正忙，于是我只能自己去联系对方解决问题。其间接老板电话，被骂，昨日数据为何有问题，答正在查找问题原因，今日解决或至少拿出解决方案。&br&11:20
过效果图的修改稿，其中几个小的改动让产品界面显得有些山寨，跟设计交涉5分钟未果，设计坚持自己认为很有创意的修改。遂放弃。&br&11:25
因为3天前新版本上线时公司做了服务器调整，导致出了大bug，在前天服务端紧急修复后昨天数据还是有问题，所以让服务端拉日志查找原因。&br&11:35
根据服务端给的原始日志抽离数据建表&br&11:40
和开发一起点的外卖到了，所以一起下楼去吃饭，建表工作完成（20%）&br&12:00
吃饭完毕，和开发讨论项目的问题，以及公司利用kpi制度克扣员工工资的问题。&br&12:30
回工位看知乎和大西贝&br&12:50
午睡&br&13:10
处理邮件，以及开发测试提的问题&br&13:30
继续根据数据建表&br&14:00
iOS版本测试完毕，邮件给给市场推广人员确认，并让开发打渠道包给他们&br&14:10
被市场人员指出更新说明写的不规范（每次都会说），并让我参照下市场上其它App，要求重新写。&br&其实市场上App的更新说明风格大多都是这样的&figure&&img src=&/af5f4d837b761ac8ee2f048_b.jpg& data-rawwidth=&640& data-rawheight=&960& class=&origin_image zh-lightbox-thumb& width=&640& data-original=&/af5f4d837b761ac8ee2f048_r.jpg&&&/figure&&br&和这样的&br&&figure&&img src=&/6c60a9ca3e_b.jpg& data-rawwidth=&640& data-rawheight=&960& class=&origin_image zh-lightbox-thumb& width=&640& data-original=&/6c60a9ca3e_r.jpg&&&/figure&以及这样的.....&figure&&img src=&/aabeaf7c7e3c08_b.jpg& data-rawwidth=&640& data-rawheight=&960& class=&origin_image zh-lightbox-thumb& width=&640& data-original=&/aabeaf7c7e3c08_r.jpg&&&/figure&&br&这尼玛妥妥的中二范啊，怎么可能学这种！&br&&br&其实我喜欢的是这样的&br&&figure&&img src=&/852aed481f10efe7d7ca8_b.jpg& data-rawwidth=&617& data-rawheight=&248& class=&origin_image zh-lightbox-thumb& width=&617& data-original=&/852aed481f10efe7d7ca8_r.jpg&&&/figure&和这样的&br&&figure&&img src=&/edf4cc0d5_b.jpg& data-rawwidth=&622& data-rawheight=&220& class=&origin_image zh-lightbox-thumb& width=&622& data-original=&/edf4cc0d5_r.jpg&&&/figure&&br&但是这没有一二三条是妥妥要被市场和老板骂死的节奏，于是我写出来的风格大概是这样的（借用陌陌的一下，我不是陌陌PM）&br&&figure&&img src=&/914f68d6b9a441b55602abf9d88b586a_b.jpg& data-rawwidth=&629& data-rawheight=&407& class=&origin_image zh-lightbox-thumb& width=&629& data-original=&/914f68d6b9a441b55602abf9d88b586a_r.jpg&&&/figure&&br&&br&结果这样还果断被市场打脸。然后沟通了半小时，终于搞清楚市场要的是这样的.....&br&&figure&&img src=&/85cc5fcd0bb9b494bca92b2c169e5997_b.jpg& data-rawwidth=&619& data-rawheight=&337& class=&origin_image zh-lightbox-thumb& width=&619& data-original=&/85cc5fcd0bb9b494bca92b2c169e5997_r.jpg&&&/figure&&br&尼玛我一周更新一个版本，开发时间不到3天，哪来这么多功能更新。于是果断把这个活交给市场人员，以后不再写更新说明。&br&&br&14:40
带薪大便手机知乎&br&15:00
与技术leader讨论周一老板提的新的功能模块，初步估计技术实现就要一个月，若是加上改版的工作量大概要一个半月往上走。&br&15:30
根据上个版本的数据和情况，与iOS开发敲定iOS本周版本的todolist以及P0和P1的事务，定好时间点，邮件。&br&16:00
测试发现Android bug，与测试一起复现bug，并做bug分析，反馈给Android开发。这时我发现今天是deadline，本来应该只能做bug修改，可是开发在做上个版本因时间不够没做完的事情，被我制止。（说明：每个版本都有P0和P1事务是必须完成的，一般都是重要bug修复或关键功能调整或上线，P1以上的事务是根据时间来做的。如果上个版本的p2或p3因为时间不够没做完，并不会因此成为下个版本的p0和p1）&br&16:30
表梳理完毕，与Android、服务端和技术leader开会，寻找分析数据问题的原因。期间因为疲劳有点瞌睡&br&18:00
原因尚未找到，大家先点外卖吃饭。&br&18:30
与项目团队的人聊天&br&19:15
看鲜果&br&19:30
Android修复bug完毕，和测试一起测试。&br&20:00
测试完毕Android打包。测试发确认邮件，我回复邮件并抄送市场人员，确认提交市场。&br&20:20
技术leader面试去了，所以会议开不了，我自己开始看表。&br&20:50
做数据表分析的时候，发现有个数据逻辑bug无法解释，于是猜测服务端给的日志有问题，找服务端重新给日志。原来日志给少了，新包大小大了1/3。重新做表。&br&21:00
表做完，开始分析&br&22:00
分析完毕，找到bug原因1、2点，开发早就回家了，这时技术leader面试完出来与他确认这两个原因，并定好更改完成日期。&br&22:40
邮件给老板汇报数据分析以及bug原因剖析，和时间点。&br&22:50
回家&br&&br&当然上面时间没有这么精确，但是大概就是这个样子。&br&我找找我分给用户体验的时间，应该是这条：&br&&blockquote&11:20
过效果图的修改稿，其中几个小的改动让产品界面显得有些山寨，跟设计交涉5分钟未果，设计坚持自己认为很有创意的修改。遂放弃。&/blockquote&好像是蛮多的，居然有5分钟
更正下马力的说法，产品经理和产品爱好者不同的地方，就在于一个一直在做事，一个一直在研究 --------------------更新---------------------------------------- 以下负能量过多，玻璃心患者请绕道 --------------------------------------------…
附上阿里的产品经理层级区别（我在2011理解，非官方文档），供参考：&br&&br&产品经理-0，本科毕业的应届生，或类似能力的其他人员。能&b&完成明确的功能点&/b&，编写PRD，跟踪实施直至上线，这时候，产品经理还是一个典型的“需求分析师”，也常叫“产品助理”。此时的技能要求还偏重于“产品设计”，对于互联网产品，做的很多事情，会与UED团队交叉，特别是交互设计、视觉设计层面。&br&&br&产品经理-1，约2年工作经验的本科生，可以独立负责一个小型产品，或者大型产品中的一个&b&完整功能模块&/b&。与上一级别的关键差异，在于不只是被动的接需求，这里的主动性，要求产品经理开始具有用户研究的能力，需求管理的能力。并且，对产品涉及的技术，需要有一定的了解，至少，能和技术团队一起讨论方案吧。&br&&br&产品经理-2，工作3~5年的本科生，或者工作约2年的硕士研究生（特别注明，学历不是关键，这里的表述只是为了便于理解，也可以是有相似能力的人员）。关键技能是能够&b&独立负责一个完整的产品&/b&，有项目管理能力，衍生出来的，就是无授权领导的团队管理能力，特别是跨部门的团队，所以对沟通方面的软技能要求，开始显现。&br&&br&前3级可以归为一类，其特点是——可以培训出来。所需要的都是一些很明确、很通用的技能，&b&我发现，目前（2015年初）大家在前面阶段的成长速度已经明显加快了，不知道是好事还是坏事&/b&。而下面3级，个人成长的关键开始从显性知识转变为隐性知识，要靠不断的实战，与各种前辈交流，加上自己领悟来提高，看书、看资料神马的作用渐少。&br&&br&产品经理-3，从这一层级开始，已经无法用工作年限来衡量。关键技能是需要有规划能力。能够&b&独立负责一条产品线&/b&，比如淘宝网的交易线（此处指2011年前后的复杂度，旗下包括较完整的产品如购物车、各种垂直市场的特定交易流程……）。此时规划能力的背后，要求产品经理需要对产品除了功能外的知识也有掌握，比如市场运营层面。&br&&br&产品经理-4。关键差异是要&b&有一个业内知名的成功案例&/b&来证明自己，可以独立负责一条复杂的完整产品线，比如整个淘宝商城（此处指2011年前后的复杂度）。很显然，这个成功案例，只能靠一次至少半年以上的完整战役获得，并不是每个人都有这样的机会和运气。此时，产品经理开始呈现出“业务Leader”的气质。&br&&br&产品经理-5。关键差异在于有&b&跨职能部门的管理&/b&经验，也就意味着到了这一层级，出去就可以做小公司的CEO，或者大公司的事业部负责人，或者直接创业。这个层级的产品经理，影响力已经不局限于产品团队，对运营策略、公司高层的方向都有着很强的话语权。
附上阿里的产品经理层级区别（我在2011理解，非官方文档），供参考： 产品经理-0，本科毕业的应届生，或类似能力的其他人员。能完成明确的功能点，编写PRD，跟踪实施直至上线，这时候，产品经理还是一个典型的“需求分析师”，也常叫“产品助理”。此时的技…
很好的问题。&br&&br&我做产品经理的时候，平时总在想一个问题：“如果给我年薪50w，我可以胜任这样的职位吗？如果不可以，那我还差在哪里？”&br&&br&首先无论是哪个级别的产品经理，交互——需求文档——需求评估——跟进开发进度——数据反馈——产品迭代优化，这样的过程都是必须的。但把这些做好就是好的产品经理了吗？其实即使是10w的产品经理，如果他足够有悟性，那他一样会把这个过程做得很好很完美。&br&&br&但为什么他还只是10w呢？因为这还只是执行层面的工作，leader教你做什么功能，你照着做，在这个过程中，你少了思考，更多的是执行。这是命题作文，让你写什么，你就写什么。&br&&br&&b&思考，就是10w与30w的差距。&/b&为什么做这个功能，这个功能是用户真正想要的吗，我是否可以用其他更好的方式代替？用户还有哪些其他的需求？我还可以做哪些其他的功能？&br&&br&一个30w的产品经理，他一定是可以单独负责一个产品，对整个产品的需求、功能、研发跟进、效果呈现、数据负责；他可以对产品做整体的时间规划，3个月后是什么样，半年后是什么样；他甚至可以带一个产品的小团队。此时，他要花更多的时间在思考，而不仅仅是执行。&br&&br&但为什么他还不是50w呢？因为更高级的产品经理，他需要站在更高的层面上来审视产品，他需要站在业务的角度去衡量产品的发展方向，他要有极宽阔的视野，了解行业，有着战略性的大局观。因为他的一个判断失误，很可能导致一整条产品线流产。&br&&br&&b&视野，就是30w与50w的差距。&/b&我们大多数的人很容易做到可以单独规划一个产品，而且也可以做的不错，但如果谈产品背后的战略布局，相信很多人都并不了解，因为他没有把自己放在更高的高度上来理解产品，他对行业的理解也并不深。&br&&br&以上就是我想说的。回答我篇首的那个问题：我对行业的理解还不够深，这的确是我需要加强的地方。&br&&br&最后对于刚入行的新手，想提几个建议：&br&1、多思考——执行是必须的，但思考才会成长&br&2、跳出来——站在总监的角度看问题，你会看到不一样的世界。
很好的问题。 我做产品经理的时候，平时总在想一个问题：“如果给我年薪50w，我可以胜任这样的职位吗？如果不可以，那我还差在哪里？” 首先无论是哪个级别的产品经理，交互——需求文档——需求评估——跟进开发进度——数据反馈——产品迭代优化，这样的…
&b&问题1：你真以为王利芬归纳的佳宾的观点吗？你真以为&/b&&b&王利芬是在场上做的归纳吗？&/b&&br&&b&
&/b&作为CCTV的大牌节目的主持人，都是千锤百炼，即使是完全不做准备，也是离不开几十数百场主持的功夫。或许之前的节目不是这个话题，但是她已经积累了，可以作为通式的表达结构，以及对场面的分析结构，形成了条件反射在分析问题，形成了条件反射在总结问题。&br&
我以前看过对王利芬的采访，其实，一个活动，主持人要准备的话题，可能比主讲人更多，而且要提前制作提词，形成接口。对主讲的人的话题，有着充分的知识积累，以及语言准备，才能在主持节目的时候，游刃有余。&br&
所谓的归纳，有的时候，只是王利芬对场上演讲，以及自己准备内容的梳理，当然更有可能是和主讲人思想上交流的对自己原有见解结合主讲人思路的提升。&br&&b&问题2：怎么提高自己的归纳能力？&/b&&br&&b&
&/b& 就是要多写，而且要形成扁平式的表达结构。&br&
这里逻辑不能乱， 扁平式的表达结构并不是一种演讲上的八股。&br&
而是最适合人类思维接收的模式。&br&
人类并不是各个都是过耳不忘。&br&
使用铁塔一样的逐步提升的表达结构，除非是演讲高手，否则听众很难组织你的演讲。&br&
使用金子塔结构，第1点，第1。1点。第1。2点，听众早就乱套了。&br&
只有遍平式的表达结构，适合普通听众分析。&br&
平时要多练习。&br&
总-分-总的表达结构。&br&
说真的，真的没有比多写小品文更好的练习归纳功力的方法了。&br&&b&问题3：怎么提高自己归纳的言论的优美程度？&/b&&br&&b&
还是小品文开始&br&
每天逼自己写一个关于时政的小品文式的演讲稿&br&
开头必须吸引人。&br&
吸引人有多种模式，每天使用一种就够了， 总之一定要吸引人，对于演讲稿来说，好的开头是成功的一半，笔者有着迷信一样的看法。就是好打开头是，对于演讲者是一个磁铁，会逼着演讲者爱护自己的这篇稿子，把优美的词汇和才思吸引出来。&br&
开头有很多种&br&
举例：复杂句式。&br&
或许，或许，或许，我真的不得不这样说，巴黎也不外如此。。。。。。&br&
举例：深临其境，利用图象刺激打动观众心理&br&
我真的觉得，今天来听讲的人，没有人注意，门口55步远之外的那棵榕树的故事，没有人留意一眼那班驳树影下的沧桑。。。。&br&
总之，你开头写多了。就会积累很多优美开头的结构了 。。。对，我其实是在培养您的即兴演讲能力。。。掌握的结构越多。。你那种藏了很多珍宝的表达欲望就越强。。就越能战胜你的恐惧感，形成了以表达欲望为主体的自信以及对观众的的侵略欲望。。&br&作为演讲者，你绝对不能有欺骗观众的想法，但是绝对不能不有对观众大脑的侵略欲望。。。&br&
然后是中间的并列的表达样式了。&br&
和开头的锻炼方法一样，我提倡每个意义段落，都要主打的句子，当然方法和开头一样，我也不说了。 &br&
结尾当然也和开头一样。。。&br&
不过，我还是有心举几个例子。&br&&br&
我不知道今天能给大家带来多少,但是我们曾经在一起，不是吗？&br&&b&问题4：怎么提高自己归纳的画龙点睛的几率？&/b&&br&&b&
&/b&我真的有办法！&br&
每天改写10个名人名言，慢慢的，你就学会提升，借用别人的肩膀了。&br&
比如“黑夜给了我黑色的眼睛，我要拿它寻找光明”&br&
你可以改写成帮助弱式群体的“黑夜挖掉了他们黑色的眼睛，他们拿什么寻找光明”&br&
你改写100个的时候，你自然会有感觉的。。。&br&================补充===============================&br&&b&问题5：有人问，有什么书可以推荐？&/b&&br&我认为，凭一本书，或者一个视频学会这些是不可能的。&br&只要有心，你把小学到大学所有的古文背诵下来。背的滚瓜烂熟&br&你的归纳能力也会增强，因为你的语言结构感增强了。虽然不能从思想上高屋建瓴的把握场面，&br&至少可以在技术上，把仅有的一点料发挥到极致。&br&读书的方法比书更重要,非要推荐的话是卡内基的《演讲的艺术》认真读10遍，可以夯实你的基本功，但是还是需要按照我说的方法不断的练习&br&此外，你可以将你读过的书，以总、分、总的结构，以1页的规模归纳起来，多归纳几本书，就可以了。&br&===============补充===============================&br&恩，要不，你就是用微博练习吧，把你读过的书，在微博上给别人介绍。。看你140个字内的归纳能力，或者是用短信跟朋友聊读书心得，短信是要钱的，而且只能70字。会逼着你下功夫的。&br&=================================================&br&18岁读大学，问你理想是什么，你说环游世界；22岁读完大学，你说找了工作以后再去；26岁工作稳定，你说买了房以后再说；30岁有车有房，你说等结婚了再带老婆一起去；35岁有了小孩，你说小孩大一点再去；40岁孩子大了，你说养好了老人再去，最后，你哪也没有去&br&&br&总之，各位达人介绍的方法都有很多了，要提高自己的演讲和归纳能力，最好的办法是从现在这一秒开始就努力。即使是笨办法，坚持下去，也不会是死路。
问题1：你真以为王利芬归纳的佳宾的观点吗？你真以为王利芬是在场上做的归纳吗？
作为CCTV的大牌节目的主持人，都是千锤百炼，即使是完全不做准备，也是离不开几十数百场主持的功夫。或许之前的节目不是这个话题，但是她已经积累了，可以作为通式的表达结…
1、首先理清思维的逻辑。&br&
世界上的逻辑我觉得简单的分：&br&
因果、&br&
并列（同类的各条，一个事情的各个方面）、&br&
递进（按事件发生先后顺序的、空间顺序的、由浅到深的、由深到浅的）&br&
对比（相反相对）。&br&
很多事情比这个复杂多了，但是木有简化就木有清晰。&br&
先给你要说的话找一个逻辑分割的依据，比如我回答这题的逻辑依据是按照“整理思维”这件事情的发生顺序组织。&br&&br&
还有一个很好的工具叫做：思维导图。&br&&br&2、按照意群组织句子，重视句子之间的逻辑。&br&
句式简单的短句很重要。&br&
重复使用同以个句型，可以强化别人的记忆点，也能让听众意识到，当这个句型出现的时候，就开启了一个新的项目。&br&
将每一个意群，先用一句提纲挈领的话表达出来，最好是准确有力度。然后再围绕这个中心句展开说，不论是举例还是阐释。&br&&br&
有一个简单的办法就是：在讲之前写下来。&br&&br&3、利用语言本身的轻重缓急。&br&
用停顿分割意群。&br&
用提高声调和重复强调重点。&br&
用提问调动听众的思维。&br&
用讲故事感染听众的情绪。&br&&br&
有一个科学的设备叫做：录音机&br&&br&最后，作为一个还在进阶中的提案人员，多听多看别人的演讲，才是王道。
1、首先理清思维的逻辑。 世界上的逻辑我觉得简单的分： 因果、 并列（同类的各条，一个事情的各个方面）、 递进（按事件发生先后顺序的、空间顺序的、由浅到深的、由深到浅的） 对比（相反相对）。 很多事情比这个复杂多了，但是木有简化就木有清晰。 先给…
忍不住了，知乎上有很多不错的“糟糕答案”，说起来头头是道，看起来很有条理，其实没有什么营养。就针对题主的问题，特别是大标题而言，现在排名第一那么长的，不说这个答案看起来很累，花很多时间读完那些书单就可以有市场敏感和洞察力了？&br&&br&&br&产品经理做产品不是应该懂得取舍，想清楚核心功能吗？&br&为什么答题的时候就搞大而全？&br&还有这么多人顶，难道顶的都是不做产品的门外汉？&br&&br&题主的问题很好，敏感度和洞察力。之前我恰好在同事日报中有讨论，再用一下表达我对这个题目的态度：&br&&br&&blockquote&“观察并思考，似乎成功的产品经理都特别善于洞察。举例说几年前听说老板（丁磊）在机场，就会不停的观察身边的人在看什么用什么，这对我影响很大，我现在出去也常常观察四周的情况，人们穿什么、吃什么、说什么、用什么等，这个点我可以搞个什么满足他。&br&不贪大求全，不只是做产品，日常项目管理、处理需求，做不好总是跟人的贪心关联的，大多数人都不能做减法，也就无法抓住核心精要，不过这个确实很难。”&/blockquote&&br&&b&不停的拷问细节，为什么人们用A而不是B或者C，是否当真如此？我想类似的思维训练比起学院式的死读书更能培养敏感度和洞察力。&/b&&br&&br&最后还是忍不住，现在第一那么长而难以吸收的答案，不应该在产品话题中顶的那么高，根本就没有抓住要点啊。
忍不住了，知乎上有很多不错的“糟糕答案”，说起来头头是道，看起来很有条理，其实没有什么营养。就针对题主的问题，特别是大标题而言，现在排名第一那么长的，不说这个答案看起来很累，花很多时间读完那些书单就可以有市场敏感和洞察力了？ 产品经理做产…
已有帐号？
无法登录？
社交帐号登录
6254 人关注
897 条内容
106 条内容
187 条内容
7101 人关注
2052 条内容
558 人关注
380 条内容}