产品经理进修第五天 管理你的产品团队
25 | 三分靠策略 七分靠执行
在产品增长系列文章里，我给你分享了很多制定产品策略、制定增长指标的经验，但仅是制定了这些策略和指标还远远不够， 最重要、最关键的是执行。
在硅谷，很多著名的风险投资人，衡量一个公司是否值得下一轮投资的标准，更多的是看团队执行的能力，即在有限的时间内到底能取得多大的进展，而不只是看创始人如何口若悬河，或者团队背景多么高大上。
可以说，一个团队的成功，三分靠策略，七分靠执行。所以，对于一个成功的产品团队，高效的执行力是关键。那么， 作为产品经理，怎么才能打造一个高执行能力的产品团队呢？
要在团队中培养结果导向、责任分明的团队文化
很多团队的策略听上去非常靠谱，但到具体执行时却杂乱无章：群龙无首、内部斗争不断，需要花费很多时间在内部事务上，团队效率低下，从而导致产品开发停滞不前。
其实，出现这种问题最根本的原因是，衡量团队成员工作表现的标准出了问题，给了不做事只吹牛的人太多“偷奸耍滑”的机会。
我之前合作的一个团队，有一个工程师非常擅长在大组开会时口若悬河，但是实际操作时却极其不负责任、能推就推，到头来却抢别人的功劳。
但是，他们的团队领导和产品经理并不怎么关注工程师的开发工作，这样的情况一直没有被注意到，所以这个工程师可以为所欲为。这样不仅让其他工程师非常不爽，还大大拖延了整个团队的效率。
那到底怎么才能避免这种情况呢？
作为产品经理，应该和工程经理一道，确保每个工程师、设计师的工作表现有明确的量化标准。这就要求：
- 每个人有自己负责的部分，并且其他人都知道是这个人负责这部分，对这部分的成绩负责；
- 工作效果有一个具体的衡量方式，是可量化的，有时间限制的；
- 这个人遇到困难，可以向他人求助，他人应该帮助这个人，如果困难解决不了，这个人有责任及时汇报给产品经理。
说白了就是，要让每个工程师和设计师觉得自己是这个部分的负责人，引导他们的主人翁意识，这样才能真正推动他们的能动性，并让他们真正在乎自己所做工作的结果。
当你发现有抢别人功劳的事情发生时，绝不能手软，要明确说明这样的行为不被允许，从而保证不会因此影响团队士气。
有了明确的量化标准和责任范围，抢功劳和碌碌而为混日子这样的行为就没有了滋生的土壤，这对提高团队的执行力非常重要。
要把控团队做决定的速度
很多科技公司的文化是希望每个人都有主人翁意识，所以做决定的时候也希望能得到大家的一致同意。 这么做的好处是，团队的每个人都觉得自己受到了尊重，激发大家的积极性，增加团队的士气；而潜在风险就是，要花太多的时间做决定， 增加了执行成本，延长了产品开发时间。
但是，并不是每个决定都需要每个人一起做出。所以，什么样的决定要快很准地做出，而什么样的决定要积极听取大家的意见，就需要产品经理来把控了。
每一个决定都有一个对应的可争论时间，时间长短由这个决定的重要程度决定。最重要的决定可以多花一点时间，积极听取团队成员的意见，让他们每个人都参与讨论，三思而后行。而不太重要的决定，可争论的时间要尽量短，目的是快速得出结论，马上开始执行。
给你举一个简单的例子，我们之前做了一个帮助网红赚钱的产品，需要对这个产品的具体问题进行讨论，然后做出产品决定。你可以先思考一下，在这个产品中，什么决定是最重要的，而什么样的决定是可以快速做出的。
对于什么样的网红有资格使用这个产品的决定，会关系到产品的发展模式、网红的运营模式等，所以非常重要。对此，负责网红关系运营的同事们、法律和支付部门的同事都参加了讨论， 我们花了几周的时间才制定出了策略。虽然这个决定花了很多时间，但让每个部门的同事都有参与讨论的机会非常重要。
但是，涉及到这个产品的某一个小细节，比如新用户体验的第一步和第二步的顺序应该是什么，如果大家喋喋不休，无法取得统一意见，而工程师在等着这个决定进行下一步的开发时，就需要产品经理出面解决了。
当时，我对大家说：“这个决定并不是最重要的，不应该花这么多时间讨论，我们可以先按照原来的顺序，后期根据用户反馈，我们还有修改的余地”。
我这么一说，既让大家意识到时间不多了，我们得赶快开始，又给持不同意见的人留了面子，这样大家就可以很愉快地推进产品进度了。
这个道理非常简单，但是我见过很多被无关紧要的决定浪费大量时间的情况。某个领导突然对某个小细节有意见了，或者两个设计师对某个按钮的样式不能统一意见、开始针锋相对了，在不值得的决定上浪费了太多时间，是我见过的执行能力差的团队的通病。
作为产品经理， 确保产品的执行效率是首要责任，而把控团队做决定的速度是最重要的一环。敢于对团队成员说“这个决定我们讨论的可以了”，并且能够说服他们赶快行动，是衡量一个产品经理能力水平的一根准绳。
明确产品功能的优先级
每个设计师和工程师都有做不完的任务， 写不完的文档和代码，以及加不完的班。所以，指望大家能把所有的工作都做完，不切实际。
我刚入行时，发现一些工程师总是慢吞吞的，他们总加班但产品开发工作就是做不完。后来我发现，他们的时间全花在改一些无关紧要的 Bug 上了，而重要的产品开发工作却被扔在了一遍，拖慢了产品开发进度。
首先，你必须意识到，不能假设工程师和你对优先级的把控是一样的， 在优先级的问题上一定要重复重复再重复， 明确明确再明确。
在这里，我跟你分享一个好方法：明确告诉你的团队成员，哪部分工作是优先级较低的。 你可以向团队成员说明产品优先级时，顺道说说哪些工作确定不是优先级高的；你还可以在路线图（roadmap）上说明哪部分是明确不做的。这样做，可以让工程师排除不重要的工作，减少浪费时间的情况。
优先级高的内容毕竟有限，但很多时候工程师有非常非常多的任务需要处理，经常一投入到代码中就忘记了产品优先级、指标，或者别的组的人一催，就忘记了什么工作是最重要的。
所以，如果你能清楚的告诉工程师什么内容是不重要的， 这些内容出现的时候可以忽略， 别的组的人催的时候可以拒绝，就可以帮工程师减少很多分散精力的工作。
其次，你需要注意的另外一个问题是，产品的优先级要每周至少沟通一次，这可以强化团队成员的优先级意识，让他们更好地规划自己的时间。
我的团队每周都有一个工程师优先级会议， 会把所有的产品功能一个一个地捋一遍，明确优先级，如果有突发情况需要修改优先级也会在这个时候告诉大家。这样的优先级会议，我一般选在周一召开，以方便工程师和设计师合理分配他们一周的时间。
最后，只有团队成员都了解了其他人的优先级，才能更顺利、有效率地合作。
比如，工程师 A 和 B 都需要我做代码评审，如果我们都知道工程师 A 这部分的内容优先级更高，对产品更重要，我就可以先帮工程师 A 评审，而工程师 B 对此也不会有怨言。
因此，清晰沟通了产品优先级，团队的合作和执行就成功了一半。
总结
今天，我跟你分享了高效执行对产品团队的重要性，并跟你分享了三个提高团队执行力的方法，希望你可以把这些方法用到日常工作中。
第一，作为产品经理要在团队中培养结果导向、责任分明的团队文化，杜绝抢功劳的情况，让每个工程师明确自己的任务是什么、责任是什么，以及对团队的贡献是什么。
第二，要把控每个产品决定值得花费的时间，对于在不重要的决定时花太多时间的情况，要适时果断地给出方向， 让大家先执行，避免浪费太多的时间。
第三，要定期召开优先级会议，让每个成员明确自己的优先级，了解他人的优先级，不只是告诉大家什么工作重要、值得做，更要明确什么内容不重要、不值得做。
思考题
你的团队在执行上遇到的最大问题是什么？
欢迎你给我留言。
26 | 为什么加班很久但是没成果？产品开发流程有问题
在刚入行做产品经理时，我工作过的一个团队每天都在加班，工程师叫苦不迭、设计师焦头烂额、产品经理也忙得像“热锅上的蚂蚁”，但就是做不出产品，最后的考评成绩也明显配不上整个团队三天两头加班的付出。
后来，我在几个高效率团队工作过以后，终于总结出了团队加班很久但是没有成果的几个共同特点，我也是在踩“坑”无数之后，掌握了团队执行的黄金宝典。
接下来，我就跟你分享一下低效团队三个常见的“大坑”。
第一个“坑”：需求变变变，但新需求并不是来自于用户反馈。
工程师最讨厌的就是产品经理改需求，但是产品经理会理直气壮地说，我的工作是要做对的产品，改需求的目的就是为了更好的产品体验。公说公有理，婆说婆有理，最终就剩吵架了，啥也没做成。
在这里，我并不是说产品经理不应该改需求。相反，我认为产品经理一定要根据用户反馈不断优化产品体验，这也正是迭代化产品开发的核心，即从最小化可行产品（MVP）开始，逐步优化产品体验，作出越来越完善的产品。
而我见过包括工作过的很多团队改需求的原因，往往是因为某个领导觉得不够好，其他组的某个人觉得有问题，或者产品经理改主意了。又或者，产品开发时，产品经理和工程师间缺乏交流，结果开发了一大半才发现已经脱离了原来的产品计划，所以工程师要按照原来的需求重新开发。
但是，在理想情况下，只有有来自用户的最新反馈时，才会改变需求。
比如，我们通过用户调查发现用户对现在的设计缺乏信任，或者认为现在产品的体验很差。这个时候修改需求或者产品决定，我认为是非常必要的。
而如果没有用户反馈，修改产品需求就会比较盲目。某个没有经过市场验证的假设，很有可能就会推后整个产品接受市场反馈的时间，而这并不一定值得。
这个时候，产品经理需要勇敢的站出来，告诉他：“我们可以先选定一部分用户进行产品测试，看看他们的反馈如何，然后再决定是否要修改需求，这样的效果会比推迟整个产品的发布时间更好”。因为一般情况下， 产品发布前都会有一个测试期，根据用户反馈做出下一步的产品决定。
当然，这种情况并不适用于所有产品。有些产品的前期投资会比较大，等到产品发布前再测试的风险会很高，所以需要在产品开发阶段就经过层层审批、不断调整产品需求，以确保产品一炮而红。
第二个坑： 做决定的人太多，做决定的速度太慢，工程师上班在等产品决定
在前面的文章中，我给你分享了一些产品决定的内容，今天我就跟你分享一下做决定的流程：我认为，每个决定，都应该弄清楚到底需要什么人、几个人来做，以及为什么需要这些人。
- 产品方向策略的决定，我一般会和工程经理、设计主管一起制定方案，然后向上层领导汇报，达成一致。而对于基层的工程师，我会给他们提意见的机会，也会考虑根据他们的意见修改方案，但并不会等到他们同意之后再做决定。
- 产品优先级的决定（先做什么功能），我一般会和工程经理、技术主管一起做，然后制定整个产品团队的开发时间表。对于每个工程师，我会和他一起商量他负责的几个项目中哪个更重要。
- 产品功能实现方法的决定，我会和具体负责这个功能的同事一起做。如果这个决定有法律或者政策方面的问题，我会再拉上法律、政策部门的同事一起决定。敏感的功能我会向上层汇报， 涉及和其他团队合作的功能，我会和对方的产品经理沟通。
明确每个决定需要什么人来做，如果这个人无法改变决定，那就可以不叫他来，这样可以减少做决定的时间，以最快的速度达成统一意见，提高开发效率。
这里的难点是，产品经理很多时候根基不够硬，或者经验不够多，不敢告诉对方这个决定不需要他做，即使为了礼貌也要把他找来，严重拖慢了做决定的速度。
我的建议是，你可以和团队成员一起商量讨论制定一个做决定的流程，做什么样的决定需要什么人来做，提前把规矩定好，就可以避免这种尴尬情况了。
综上所述，把每个决定结果记录下来，及时和团队成员汇报，并给他提建议的机会，而不是让所有人都参与到做决定这个过程中，可以在兼顾团队成员的主人翁意识的同时，对团队的执行效率产品积极影响。
第三个坑： 产品开发计划没做好。
有些团队比较理想主义， 每一步都拖来拖去， 但是却认为到截止日期那一天产品就会像变魔术一样变出来。这是非常幼稚的想法，最后产品往往不能按预期发布。
产品的开发计划一定要非常精准， 我的建议是至少以星期为单位，每周都要明确每一个工程师和设计师要达到什么样的结果。
在刚刚决定做一个产品时，产品经理都会先写产品需求文档， 分别给工程师和设计师制定工程计划和设计计划，这个时候你可以把要达到的目的精确到每个星期。
这里需要注意的是，在制定产品开发计划时，你需要和团队的工程师和设计师商量，看这样的计划是否可以顺利执行，有没有哪些不合理的地方，然后根据他们的意见适当调整。
如果工程师觉得这一部分需要先拿到设计图才能做，你可以适当调整设计师的设计计划，以确保设计师和工程师之间的合作最优。 如果工程师认为， 设计师得在第三周时告诉他是用行表还是用纵栏，因为两者的数据结构不同，那你就要确保设计师的计划能符合这样的要求。
这些都是在产品开发之前就已经提前计划的， 而不是让设计师和工程师各做各的， 遇到问题以后才修改。好的产品计划可以减少加班，这句话一点都不假。因为产品开发计划精细准确，确保每一步都是最优的，可以大幅提高产品开发的效率。
我给你分享的产品开发流程中的三个“坑”，都是我自己亲身踩过的。把这些内容分享给你的目的，就是希望达到“我试错，你绕坑”的效果，提高你的产品开发流程。
最后，针对现在的“加班文化”，我想告诉你的是，不要让团队成员把加班时间长作为一种光荣，这是一种很危险的文化。这样的文化会助长庸人，让团队不再是结果导向。
比如，工程师开发做得一塌糊涂，但每天在办公室加班上演“苦肉计”，考评时直接说：“我工作这么辛苦，难道不应该给我好评吗？ ”
但我并不是说不能加班， 而是永远不要以加班时间作为衡量团队成员工作质量的标准，否则团队一定无法在规定时间内交付高质量的产品。
总结
加班很久但是没成果，是一件非常悲哀的事情，也是产品经理的失误。我给你介绍了三种提高工作效率的方式，来减少无谓的加班时间，确保产品有结果：
第一，要杜绝根据假设以及个人的意见改需求，用户反馈才是修改产品需求的依据。在确保产品的代码质量有保证的前提下，提前发布让更多的用户看到，远远好于因为某个人的临时起意而耽误产品接受市场反馈的时间。
第二，要把每个产品决定需要几个人、什么人参与弄清楚，确保不让不直接相关的人耽误做决定的时间，不要出现工程师干等产品决定而无法开始写代码的情况。
第三， 在产品开始开发前制定出精准的产品计划，工程师、设计师等各部门同事提前计划、提前预估风险、提前调整工作计划。
最后，我要和你说的是， 要倡导结果导向而不是以加班时间为导向的团队文化，这样才能让团队成员把精力花在做事情上， 而不花在“苦肉计”上。
思考题
请你思考一下，你团队的效率低下是踩了哪个“坑”？你打算如何解决？你是否还经历过因为其他原因造成的团队低效？
欢迎你给我留言。
27 | 如何激励和管理比你资深的工程师、设计师？
我开始做产品经理时， 还是一个二十出头的黄毛小丫头，大学刚毕业踌躇满志，顶着“经理”的头衔和高级工程师开会，他们直接给了我一个“下马威”。原因很简单，高级工程师做过很多产品，有很好的产品感觉，根基也非常扎实，这个时候你想领导他们谈何容易。
其实，很多产品经理都会遇到比自己资深的工程师、设计师， 他们聪明绝顶、深受尊敬、连领导都会问他们的意见。就算是经验丰富的产品达人，进入新的团队，也应该马上和这个团队的灵魂人物搞好关系。如果他们如果带头对你的方案提出质疑，其他的团队成员肯定会跟风不再信服你，那么你这个产品经理可就难当了。
接下来，我就根据自己在产品经理道路上“摸爬滚打”的经验，跟你分享几招同资深的工程师、设计师友好相处的“必杀技”，希望能够帮你更好地激励和管理他们，最大限度地将他们的聪明才智用到你的产品中。
第一招，建立信任从帮忙打杂开始。
进入一个新的产品团队， 一定不要一开始就指手画脚， 这个时候大家对你的能力还不清楚，团队的利益关系你也还没看清，甚至你对产品所处的环境和策略都还不熟悉，这个时候，帮团队做一些简单的小事， 比一开始就直抒胸臆、指点迷津强得多。
当你觉得跟工程师还不熟，或者他们对你爱答不理时，我最常用的方式就是跟工程师约个咖啡， 告诉他们我是新来的，对咱们团队的事情还不懂， 你有没有什么“脏活累活”，我先帮你干吧。
还有一个小技巧，开会的时候，你不要想着一上来就发言，主动做会议记录的效果来得更好，然后通过邮件把会议记录发给大家。
这样，一方面团队成员会觉得你来是帮助大家的，另一方面通过会议记录，你可以更好的了解产品现在所处的环境和策略，并和大家讨论会议的细节。
恭喜你，这种自然地过渡，可以帮助刚来的你取得团队成员的信任。
另外，如果你的产品经验并不是很丰富， 一定不要装出一副经验很丰富的样子，因为你的“表演”并不能骗到大家。
这个时候，你应该放低姿态、踏踏实实地做工作，表现出你的努力和进取心，让大家觉得你是一个年轻有为的、充满朝气的、有潜力的领袖，而不是夸夸其谈，会更容易得到其他成员的认可。
当你肯放低姿态不把自己当回事，不摆经理架子，并愿意帮助大家完成会议记录等琐事时，你就已经比大部分产品经理更受团队欢迎了。
第二招，建立和资深成员的信任关系。
每个团队总有那么几个资深的、深受大家尊敬和爱戴的人，这样的人产品经理切记不能得罪，否则整个团队都会不待见你，推进工作会遇到重重阻碍。但是如果你能和他们建立良好的关系，团队其他成员也自然不敢给你难堪。
可见，和团队资深成员搞好关系，可以让你的工作事半功倍。那怎么才能和“高高在上”的他们，建立良好的信任关系呢？
我的建议是，你可以是虚心请教的态度，问问他们对团队有什么期许，和之前的产品经理合作有什么样的问题，自己如何做才能避免出现这些问题、更好地帮助他们。
你也可以和他们讲讲自己的故事、以前的经历， 像交朋友一样和他们沟通，让他们信赖你，真正成为你的左膀右臂。
这里，你需要明白的是，只有让这些资深成员信任你，他们才会帮助你，其他的团队成员才能更信服你。
第三招，弄清楚资深成员想要什么。
资深成员已经取得了大家的信任和支持，领导也非常重视他们，他们已经不在乎你是不是经常表扬他们，或者老板怎么看他们。所以，你平时的表扬和鼓励对他们不一定管用，但他们一定有想要的东西，这个时候你就需要仔细观察，了解他们下一步想要达到的目标。
弄清楚资深成员的需求，才能和他们建立信任之上的更深层次的关系。
比如，有些资深成员想要独立发起项目，和团队推销自己的新想法，如果这个时候你能够帮他们更好地推销，给他们“站台”，支持他们的新想法，就会比较容易得到他们的心。
还有些资深成员希望能做最有挑战性的工作，并且让其他成员都知道这些工作是多么有挑战。这个时候，你给他们一个展示自己工作的机会，并强调他们做的东西难度多么高，能做出来多么不容易，这对他们来讲意义非凡。
资深成员到了这样的职场阶段，在乎的是自己的口碑，自己的工作是不是对公司有价值、符合自己的价值观和野心，而不是今年的考评是不是够好、是不是能升职。所以，激励他们要有针对性，了解他们想要什么，并最大程度地满足他们，才可以让他们更信服你。
第四招，你的“必杀技”就是把事情干成。
一个产品经理， 就算你有厉害的学历或者丰富的经验，但你就是没法把产品干成，没法把执行做好，那么你再精彩的简历都是白搭。
这个道理很简单，作为团队成员，你在乎的是每天加班加点的工作，能够做出一个满足用户需求的产品，而不是瞎忙活，做了半天啥也没有发布。
所以，如果你是一个产品新人，没有产品成功的案例，那么你现在最需要的是尽快发布一个产品，并取得好的成绩，用成绩证明你的能力，让大家信服你。
一个真正能够推动产品进展的产品经理，在工程师和设计师，尤其是见惯了只耍嘴皮子、不做实事的高级工程师、设计师眼中，比什么都强。
只有以身作则拿出成绩，大家才会真心的服你，愿意跟从你、响应你， 这一点对产品新人和资深的产品经理同样重要。虽然资深产品经理，可能不会亲力亲为了，但是遇到事情能顶上，同样非常重要。
综上，激励和管理比你资深的工程师设计师的方法，可以概括为四个词：放低姿态、建立信任、成人之美，和踏实做事。
总结
今天我跟你分享的主题是，很多产品经理，尤其是产品经验不丰富的产品经理最头痛的问题，怎么才能让比你更资深的工程师、设计师信服你，激励他们把自己的才华最大限度地应用到你的产品中。我通过个人“摸爬滚打”的经验，和你分享了四招：
第一招，建立信任从帮忙打杂开始，从一开始就帮助大家做实事，宁可踏实做“脏活累活”，也不夸夸其谈、装模作样。
第二招，和资深成员建立信任关系，虚心请教，让他们帮助你成长。
第三招，弄清楚资深成员的需求，无论是引领创新还是做最有挑战的事情，成人之美，尽可能地满足他们的需求。
第四，靠产品成绩说话，尽快做出结果，高效执行，只有真正能够推动产品进展 ，你才会得到大家的支持。
思考题
你和团队中的资深成员相处时，遇到了哪些挑战？你是如何做的？ 效果如何？
欢迎你给我留言。
28 | 产品经理的晋升秘密
在硅谷的顶级公司，产品经理一般分为很多不同的级别,，是一个可以通到公司最高层的职位。比如，在谷歌或者 Facebook 这样的公司，产品经理可以做到副总裁的级别。
有些公司喜欢把产品经理的等级分得很清楚，比如微软，但是像 Facebook 这样的公司都叫“产品经理”，从职称来看根本分不清楚谁是高级的、谁是新人，但事实上通过产品经理所管理的产品的工作范围，你就可以非常清楚地知道他是什么级别的。
那么，首先我来跟你分享一下不同级别的产品经理都在思考什么、做什么。
一个刚刚入行的初级产品经理，他们管理的产品范围会比较小，一般是一个具体的产品功能。比如，负责 Facebook 的头像功能。 初级产品经理的另一个特征是，他们管理的产品在策略上一般比较明朗，公司已经基本上明确了要做什么，只是一些具体的小细节需要他们自己研究。
所以，对于一个初级的产品经理来说，最重要的是有很强的执行力、权衡取舍分清主次的能力，以及能够快速引导产品下一步迭代的能力。
说白了就是，这个产品经理是不是具备制定一个短期成功指标的能力，能不能进行项目管理，能不能很快地帮助工程师、设计师等团队成员快速解决疑难问题，从而推进产品功能的发布以及迭代。
一个比较成熟的骨干产品经理，管理的就是一整个产品了。 比如说，Facebook 的主页。这个时候他们就需要制定一些稍微长期的未来一到两年的策略了，他们的工程团队也在逐渐扩大。
对这样的产品经理来说，他们需要能够制定一个长期的成功指标，并且能够把这样的长期指标和近期数据对接，知道怎样通过眼前的数据来估测产品的发展是不是在所希望的方向上。
比较成熟的骨干产品经理，还有可能会管理一个从 0 到 1 的产品。这样的产品需要他们从头开始了解用户需求，并且快速证实用户假设。
比如，我们要做一个给年轻人听音乐的 APP，这个 APP 能够自动给年轻人推荐最近刚刚火起来的小众歌手。这时产品经理就需要通过一系列的调研以及数据，快速了解年轻人是不是有这样的需求，从而得出这个产品该不该做的结论。
到职业生涯中期的产品经理，一般就开始管理一个产品领域了。 比如，帮助 Facebook 用户更好地表达自己的一系列产品，可以是主页，可以是自拍 GIF，也可以是自制表情包。
这个时候他们可能就需要从头制定这个领域的产品策略。和之前两种产品经理不同的是，老板一般不会告诉他们要做什么，而是会问他们我们应该做什么。
说白了就是，这样的产品经理已经能够独挑大梁，帮助公司制定未来中长期的产品策略，并且知道如何组织团队的架构。
这种级别的产品经理，会思考类似“帮助用户更好表达自己”的产品领域，有没有什么方式能够把涉及的产品归类，每个类别都可以找一个产品经理分别管辖。
比如说，第 1 类是用视频方式来帮助用户表达自我的产品，第 2 类是用文字和语音来帮助用户表达自我的产品，第 3 类是用 GIF 来帮助用户表达自我的产品。
可能还有别的分类方式，比如帮助高中生表达自我的产品、帮助年轻人表达自我的产品、帮助 40 岁以上的中年大叔大妈们表达自己的产品、帮助老年人表达自我的产品。
那么，这两种分类方式哪种更好呢？其实，这是要取决于这个产品或者公司面向的用户群体。
比如，如果是阿里巴巴的话，可能最重要的是按照年龄划分，因为相同年龄段的人可能买的东西也很相似，所以最重要的是帮助用户更好地表达自我。你可以通过他们的同龄人的表达方式，去激发他们的购买欲。
如果是美图秀秀的话，可能第一种方式更加妥当，因为用户使用美图秀秀， 需要的是能够快速做出最好看的视频、最酷的表情包， 因为用户对于视频、图片、表情包等表现形式有不同的要求，所以按照不同的表现形式来划分更妥当。
到职业生涯中期的产品经理，能够把公司的整体发展策略和自己的产品领域相对应， 他们思考的是怎么用自己的产品来帮助公司实现整体的产品策略。
当然到了职业发展的顶层，产品经理负责的可能是整个公司的产品策略，这个时候探索创新的能力就非常重要了。 比如，Google 是不是应该进军区块链， 阿里巴巴是不是应该做一个自己的 Uber，这种关系到公司策略的大问题，就需要这些产品高管来把关了。
在大公司，其实很多的产品高管，还会思考要不要收购某些小公司，以及收购后怎么发挥这些小公司的价值。
顶尖科技公司的产品高管，衡量他们成功与否的标准，不是某一个产品的使用量怎么样，而是这个公司是不是在行业内到了更领先的地位，是不是对公司股价产生了积极影响等等。
这时，产品高层的大部分时间就不是和工程师在一起了，他们更多地是给其他产品经理的产品策略以及产品功能提建议和意见。
产品高层还要解决的问题是，管理一个几百人的产品团队，如何更好地培训、招聘、管理产品经理，如何促进部门之间的合作与沟通，什么时候需要把团队成员重新分组、重建组织结构、也就是硅谷说的 reorg，这些工作内容占用了产品高层更多的时间。
说了这么多产品高层和产品菜鸟之间的区别，那么怎样才能加快升职的速度呢？
第一，如果你是个产品菜鸟，你可以思考一下自己负责的产品对公司整体有什么影响。
比如，虽然你现在只负责头像这一个功能，那有没有什么方式能够让用户多关注其他人的头像装扮，从而激发购买欲呢？让用户可以互相圈各自头像上的美妆产品，做一个社交美妆软件？或者用户每次购买新东西的时候都可以更换一次头像呢？
你也可以多看看公司高管每天都在讨论些什么，然后思考自己的产品能够怎样帮助高管们解决这些问题，那么你的产品会更容易引起高层的注意，他们也会觉得你有整体观念和全局观念，从而实现晋升。
第二，你可以思考一下怎样才能扩大你的产品版图。
有什么方式能让你不只做头像？你可以从思考头像的目的是什么，我们为什么需要头像开始。我们需要头像，是因为我们需要更好地表达自己是谁、来自哪儿、喜欢什么，那么你可以继续思考有没有什么其他的产品功能或者一个单独的产品，能够帮助用户更好地表达自己？
比如说，除了自己的头像，你可不可以选择一个卡通人物来代表自己此时此刻的心情，能不能用 5 个弹幕来表达最真实的自己，等等。当你这么做的时候，你也就从只负责一个产品功能，延伸到了一个产品领域。
第三，你可以思考一下你的产品如何帮助公司的长期策略，让产品在未来三到五年一直保持领先。
年轻的产品经理一般比较关注当下，更在乎此时此刻、产品刚发布的时候什么数据比较好看，很容易忽略长期的目标和任务。但是，一个比较有经验的产品经理会思考，产品刚刚发布时采取的一些推广策略，会不会破坏产品的长期规划。
比如，给用户发的推送信息太多，他们会不会直接屏蔽所有推送。这些产品经理在一开始就会思考怎么才能保证这个产品在未来三年还是成功的，有没有什么方式能够一步一步接近于长期的成功。
第四，不要局限在思考产品，你还可以思考一下公司的产品管理流程是怎样的。 比如，产品经理的培训和选拔机制有没有什么可以改进的地方，对新的产品经理的培训是不是有效。如果你是一个产品菜鸟，那不妨给高管们提提建议，哪些方式能够帮助新人更好地适应公司的环境，自己可以为此做些什么。
记得我刚入行时犯了一个错误，觉得我是新人就应该听老板的，让我干嘛我就干嘛，所以每天都在等老板给我安排工作。结果，虽然我感觉自己工作很努力、很认真，但一直都不是明星员工。
然后，我就开始观察明星员工的做法。我发现，他们每天不仅仅等着老板发号施令，而是能够主动地、积极地去探索，有没有什么东西是大家都没有注意到的。可能会涉及到一些不属于自己本职工作的事儿，但只要能够对公司的发展和产品的开发有帮助，他们都会去做。
试想一下，如果你是老板，你是喜欢一个只会等你发号施令的人，还是喜欢一个凡事儿都想在你前面，能够帮助你解决你自己可能都还没发现的问题的人呢？所以，一个新人一定要主动主动再主动，不要被自己刚刚进入职场的条条框框限制住，这一点适合于所有的职业。
第五，在硅谷还有另外一个升职的捷径，就是能够发扬自己独特的优势，快速在行业内建立领域专家的地位，当你在行业内有影响力的时候在公司自然就有了影响力。
比如，你是一个产品增长专家，公司其他产品需要解决增长问题的时候也要来问你的意见，你就逐渐建立了在整个公司内的专业影响力。
或者，你自己写了一本从零到一做产品的书，获得了非常高的评价，在业界有了一定的知名度，即使之前你并不一定是老板的宠儿，业界影响力也会让老板不敢小瞧你。
尤其是在大公司，人山人海，怎样能快速显露自己的优势、让自己被注意到，其实是一门学问。
总结
今天这篇文章， 我给你揭秘了不同级别的产品经理的工作内容，以及需要具备的能力。你可以据此思考一下自己怎么才能成长为更高级别的产品经理。
我也跟你分享了五条可以帮助你在产品经理岗位上步步高升的小建议，帮你实现晋升：
第一，你可以思考自己的产品对公司发展的影响；
第二，你可以考虑如何扩大自己的产品版图；
第三，进行长线思考，而不是局限在短期目标上；
第四，你可以思考如何提升产品开发流程；
第五，你要弄清楚自己的独特优势是什么，以及如何发挥。
思考题
- 如果你是一个产品经理，你现在每天的工作内容，属于上面提到的什么级别呢？
- 如果你现在是一个负责的让用户能够搜索当日主要新闻，并点击进入到对应的网站阅读全文功能的产品经理，你该如何从这个功能出发，扩大产品版图呢？
欢迎你给我留言。
29 | 你需要一个产品路线图
产品路线图，又称 Roadmap，是很多人说起产品经理时最先想到的内容，而这也确实是产品经理工作中非常重要的一部分。
市面上关于产品路线图的文章有很多，制作路线图的软件也是应接不暇，但是我发现很多人讨论得更多的是产品路线图是什么格式、要用什么软件画，却忽略了产品路线图本来的目的，至有些人把产品路线图和需求文档的概念混淆了。
那么，今天我就跟你分享一下，为什么要做产品路线图，以及我平时怎么做产品路线图。
产品路线图的目的
首先，产品路线图的目的是让团队成员清楚知道产品要往哪个方向走，怎么走，以及在什么时间要做什么事情。
路线图的英文叫作 Roadmap，由 road 和 map 两个单词组成。说到底，路线图首先要告诉团队成员我们要去哪，路在何方，也就是 road；然后告诉他们我们应该怎么去，如何达到目的，这就是 map。
所以，产品路线图一定要立足于产品的愿景（vision），告诉团队成员我们如何一步步实现产品的愿景。
给你举一个 Facebook 大老板扎克伯格制定产品路线图的例子。
这是 Facebook 未来十年的产品路线图，由扎克伯格在 2016 年提出，愿景是连接整个世界，让人与人之间的距离更近。那么如何实现呢？
在未来三年（2016~2019 年），我们立足于 Facebook 生态系统，让 Facebook 继续帮助人们更好地与他人连接。
在未来五年（2016~2021 年）， 我们将从视频、搜索、小组、Messenger、WhatsApp、Instagram 着手，让世界各地的人通过 Facebook 旗下的这些产品，分享各种各样的内容（图片、视频、文字等）。
在未来十年（2016~2026 年），Facebook 将会大力发展核心技术，在网络硬件、人工智能、虚拟现实等方向，为人与人之间的连接作出质的贡献。
从 Facebook 十年的产品路线图中，你可以看出，扎克伯格首先是从整个公司的愿景出发，然后层层深入；从近期的三年计划着手，然后步步深入，最后十年计划一出来，整个公司仿佛看到了一个让整个世界连接更紧密的蓝图。
当然，大部分产品经理管的是一个具体的产品，也不会做一个十年规划的路线图，但是产品路线图的目的都是一样的：先立足于产品要达到的最终效果，以长期愿景为目的，然后一步一步告诉团队成员如何实现。
但是，有些产品经理的路线图，说白了就是一个任务清单，列出了一个个要完成的任务，团队成员看完后，并不清楚到底要达到什么目的，成功指标是什么，这最多算一个项目管理档案，不能叫作产品路线图。
一个好的产品路线图，应该是你读完后：
- 首先，明确产品的长期愿景；
- 然后，明确分为哪几个阶段，每个阶段的成功标准是什么，每个阶段之间有什么样的逻辑关系，才能实现最后的长期愿景；
- 最后，明确每个阶段我们具体要做什么，以及怎么做。
一般来讲，越是高级的产品经理，想得越远，产品路线图横跨的时间范围越广，这种产品路线图的难度也越高。
好的产品路线图，团队成员看完后，应该有种“哇塞，我做的事情真酷”“哇塞，我看到了我们一步一步如何实现最终的成功”这样的感觉，并且团队的每个人都知道：
- 我们这半年要做的事情，和长期愿景到底有什么关系；
- 我们这半年做的事情，分为哪几个部分，重要性和优先级都是什么。
产品路线图的内容
我一般会有整个产品团队的路线图，和每个产品的路线图。我的产品团队负责很多产品，所以整个团队的路线图更多得是写我们这半年要达到什么目标，这个目标如何帮助我们离成功更进一步。
下面我通过一个具体的实例，向你展示一下，我一般会按照什么样的框架，来写产品团队的路线图。
- 团队愿景： 成为最有效的网红和粉丝之间沟通互动的工具，这也是我们团队一直以来的愿景。这个愿景的实现包含了我的产品团队下的许多网红产品，比如粉丝给网红打赏，网红和超级粉丝互动等产品。
- 成功是什么样子？ 网红首选我们的工具和粉丝沟通，粉丝和网红每周至少互动一次。
- 下半年的成功是什么样子的？ 比如，50% 粉丝和网红每周至少互动一次。
- 下半年如何实现这样的成功：
- 帮助网红找到铁粉。（P0）
- 给铁粉特别的徽章；
- 铁粉排行榜。
- 帮助新粉丝找到自己感兴趣的网红。（P0）
- 网红发现广场；
- 每天推荐 5 个网红给新粉丝用户。
- 提供网红和铁粉之间互动的工具。（P1）
- 让网红直接选定有特点的粉丝进行互动；
- 让网红举办针对铁粉的抽奖活动；
- 方便网红创造铁粉专属内容的工具。
- 帮助网红找到铁粉。（P0）
以上三个重点问题是我们这半年工作的核心，我们将通过上面的 7 个产品功能解决。
有时，我还会详细说清楚每个部分的优先级，让团队成员可以优先解决最重要的问题，以最高效的方式实现成功指标。 比如，帮助网红找到铁粉最重要， 那这个问题就是最优先的，用 P0（priorioty = 0，优先级最高）表示，提供网红和铁粉之间互动的工具的优先级是 P1。
注意，我并没有在“如何实现这样的成功”这部分，直奔要实现的 7 个小功能，而是先拆分为三个重点，然后再说明解决每个重点问题，需要实现的具体功能。
通过这个整个产品团队的路线图的例子，我要表达的重点是：产品路线图中，一定要先明确团队要实现的愿景以及成功的标准，然后再说当前的计划和成功标准，这样团队成员很快就能知道我们当前的计划对总体计划有什么帮助。
有的时候，我会在“成功是什么样子”这个部分加上日期，这样才让大家有紧迫感。
比如，我们要在 2019 年上半年实现：网红首选我们的工具和粉丝沟通，粉丝和网红每周至少互动一次。
那么，2018 年上半年我们要实现 50% 的粉丝和网红每周至少互动一次，2018 年下半年我们要达到 75% 的粉丝和网红每周至少互动一次的指标，以及我们的产品要成为网红的前三个选择。
这样，2019 年上半年我们就可以实现最终的成功。
对于一个粉丝给网红打赏的产品，你可以这么写路线图：
产品愿景： 让网红可以以赚取粉丝的打赏为生；让粉丝得到网红特别的关注。
成功标准： 10000 个网红能够达到月收入 10000 元。
2018 年上半年的成功标准： 1000 个网红能够达到月收入 5000 元。
2018 年下半年的成功标准： 5000 个网红能够达到月收入 5000 元，1000 个网红达到月收入 10000 元。
2019 年上半年成功标准： 10000 个网红能够达到月收入 10000 元。
然后，我们具体说 2018 年上半年的成功如何实现：
目标是 1000 个网红能够达到月收入 5000 元，为此我们需要，让已经有粉丝打赏的 200 个网红得到更多的赏金，让还没有得到任何打赏的其他网红（假设目前有 3000 个）中的 800 个月收入达到 5000 元。
接下来，你就可以按照上面整个团队路线图的逻辑划分出重点问题了：
- 是让粉丝加大打赏金；
- 培养更多粉丝打赏的习惯；
- 是增加粉丝用户的数量。
然后，你就可以按照上面整个团队的产品路线图的逻辑，设计每个部分的产品功能，来能实现成功目标了。
总结
今天我跟你分享的主题是，产品路线图。接下来，我给你提炼一下今天内容的要点：
- 产品路线图的目的是制定产品阶段性的计划，从而让产品实现最终的愿景。这要求产品经理从愿景出发，为每一个发展阶段制定成功标准和策略，而不只是简单罗列亟待完成的事项。
- 即使一个产品团队负责一个产品线的多个产品，也应该有整个团队的产品路线图，以及每个产品的产品路线图。
- 产品路线图应该由产品愿景、成功标准、现阶段成功标准、现阶段发展重点、每个发展重点下的具体产品功能这些部分组成。通过划分现阶段的发展重点，增加产品路线图的逻辑性、可读性，并进一步划分产品团队，让每个人都能认识到自己的工作如何帮助团队实现产品愿景。
思考题
如果让你设计抖音未来三年和 2018 年下半年的产品路线图，你会怎么写？
欢迎你给我留言。
30 | 如何制定产品优先级 ？
制定产品优先级是产品经理的必备技能，但这个必备技能着实是一块儿“硬骨头”。
在日新月异的科技行业，计划赶不上变化， A/B 测试可能带给你新的结论，竞争对手可能打乱你的步伐，产品功能比之前计划得要复杂得多，这样的变化都会改变产品优先级。
所以，每个产品经理需要做的，就是要在高变化、高不确定性、高复杂性的情况下制定出优先级，让产品以最快的速度、最小的代价取得最大的成功。
可见，制定优先级并不是一件易事，但更难的是要说服其他人认可你制定的优先级。
为什么需要产品优先级？
产品优先级，可以让团队成员明确哪些功能是需要优先做的，哪些功能是无关紧要的，从而在最短的时间内解决产品最关键的问题。
如果没有明确的优先级，团队成员就会失去方向，各打各的小算盘无法高效合作；产品优先级弄错了，就会耽误产品进度，而且你认为不重要的功能被竞争对手抢先发布了，对创业公司来说可能就关乎生死了。
我见过许许多多的产品团队，无论是成熟的产品团队，还是从零到一的产品团队，也接触过无数的产品经理，无论是资深的行家，还是刚刚入行的新人，这些产品团队和产品经理，都有一个共同的特点，那就是永远有做不完的产品任务，从来没有把事情都做完的时候。
而且，每次产品发布前的一个星期，总会出各种各样的问题，产品经理总会有各种危机要处理，甚至会修改之前的计划。
所以，如果产品团队没有优先级，而是按照顺序一个一个地做所有的任务，那么产品永远都不会被发布。
在 Facebook，我们每个产品经理都要遵循的一个理念是：权衡取舍要无情。这句话重要到我们已经把它做成海报贴在了公司墙上，所有人每天上班前都会看到。
产品优先级的误区
在制定产品优先级时，有以下这四大误区，需要特别注意。
- 认为所有功能都优先，这句话同时意味着所有功能都不优先。 很多时候我发现，刚入行的产品经理会在产品需求文档洋洋洒洒地写上十几个功能， 而且每个功能都是紧急，这样做根本就是没有搞清楚产品的优先级。
在我看来，产品的优先级是要分等级的，如果你有 10 个功能， 最多有三个功能是最优先，也一定有三个功能是不优先的。
产品优先级的等级，我一般喜欢用 P0、P1、P2 表示，P 代表 priority，P0 指最优先，P1 指一般优先，P2 则可以以后再做。在 Facebook，我们的共识是 P0 是现在要做的，P1 是有空就做的，P2 是一定来不及做的。 - 认为优先的功能是最简单的功能，这源于产品经理对最小化可行产品的误解。 最小化可行产品， 是确保产品功能只要满足用户最基本的需求就可以了，但并不等于说产品只有最简单的功能。
最优先的功能应该是最有价值的功能，如果一个产品只具备一堆锦上添花的、最简单的功能，那它并不能算是一个完整的产品，它的优先级出了问题。 - 判断产品优先级时只考虑工程难度以及预期效果，而忽略了这个功能的潜在风险。
如果产品需要下个月发布， 有一个功能非常重要，也不难做，但是涉及到和其他的组的合作。而目前这个组的团队有问题，很有可能这个功能无法按时完成，而产品的发布时间必须要保证。
那么，这时候你就要思考这个功能到底是不是优先，是不是应该先做低风险的功能以确保产品发布。 - 在做产品计划时，没有明确什么叫做最优先。 比如，产品有三个最优先的功能，发布前其中一个没做完，那么你到底是应该选择先发布两个已经做完的功能，还是推迟整个产品的发布时间，等第三个功能完成后一起发布？
很多产品经理事先都没有考虑这个问题，导致产品发布前出现了突发情况非常慌，和团队成员争论不休，从而耽误了产品发布的良机。
所以，我建议，在做产品计划时就应该先明确，这些功能到底是不是重要到推迟产品发布也要等的程度。
你的产品优先级决定真的算数吗？
很多时候产品经理并不直接管理所有的团队成员，特别是在大公司，每个细分领域都有具体的部门来执行，而这些部门并不直接对产品经理负责。
举个简单的例子，市场营销部门会直接汇报给市场营销总监，所以你的市场营销经理更在乎的是总监在乎的指标，而不是你在乎的指标。
如果你制定的产品优先级和其他部门的不一致，那么你的产品优先级多半不算数。即使你分析得再准确，沟通得再清楚，甚至你的团队成员也哼哼哈哈地同意了，但最终他们并不一定会按照你的优先级来。
我在负责网红产品时，就经历了和市场营销部门的优先级不一致，而影响了产品的事情。我的产品团队有专门负责传媒公司营销策略的市场营销经理，当时我把对小型明星工作室更有帮助的功能，定为了最优先。而这个市场营销经理汇报的部门衡量成功的标准是，传媒公司客户的满意度，因此他们最优先的几个项目都是和传媒公司有关的。
虽然我说服了市场营销经理认可我制定的优先级，他也认为这对我们团队来说是最正确的选择，但在实际工作中，他并没有按照我制定的优先级来。而我们中间又缺乏了有效地沟通，最终影响了我们这个功能的正常发布。
后来，为了解决这种问题， Facebook 在每半年计划的时候， 都会让不同的部门交流彼此的优先项目，提前找出利益冲突的部分。
这样，在制定计划时就充分交流，提前发现问题，有冲突时要么修改各自的优先级，要么修改成功指标（毕竟成功指标是决定优先级的核心标准），可以最大程度地避免对产品发布的影响。
无情的权衡取舍还要明确我们一定不做什么
在 Facebook，我们一直在讲产品经理要无知、无畏、无情：
- 无知，就是产品经理不应该马上下结论，而是应该保持好奇心，提出假设，然后验证假设；
- 无畏，就是产品经理应该勇于制定有难度达到的成功指标，更好地激发团队潜力，而不是为了不担风险只打安全牌；
- 无情， 就是我今天跟你说的， 不管产品的想法多么好，可做的事情多么重要，都一定要分出个主次， 明确我们一定不做什么。
我在 Instagram 的一个老板，在制定产品线路图和优先级时，喜欢加一个“一定不优先”的板块，这个部分专门写那些我们肯定不做、 明确不是优先级的内容。
我第一次看到这个版块时，完全不理解为什么要花这么大精力去写一堆不用做的内容，但真正和团队磨合时， 我发现经常会有人提出我们要不要试试这个功能、要不要也做一做那个功能，或者某一个领导突然对某个东西感兴趣随口问了一句， 大家就蜂拥而至，要修改原有的产品计划，做这个功能。
这样的情况时有发生，虽说可以活跃产品团队氛围，但更多的却是干扰，导致产品的实际执行不能按照既定轨道进行。我的这个老板的“一定不优先”版块，目的就是降低这样的干扰。
他可以自如地给大家展示这个文档，问大家有没有最新的用户反馈，如果没有的话，我们就明确这个功能一定不优先；有没有什么新的信息需要我们改变策略，没有的话，我们就继续按照原定计划执行。这样一来，大家很快就能回到正轨，减少干扰。
总结
今天我给你分享的主题是如何制定产品优先级，这部分涵盖了制定产品优先级的计划、灵活调整优先级、沟通优先级、和与其他部门对优先级达成共识。
我还跟你分享了产品优先级的四个误区：第一，认为所有功能都优先；第二，认为优先的功能是最简单的功能；第三，制定优先级不考虑这个功能的潜在风险；第四， 在做产品计划时没有明确什么叫做最优先，什么情况下我们即使推迟产品发布也要等。
最后，我们跟你分享了产品经理的无知、无畏、无情，“权衡取舍要无情”是 Facebook 的理念，希望和你共勉。
思考题
我在文中提到的产品优先级的四个误区，你曾经中过哪个？
合时， 我发现经常会有人提出我们要不要试试这个功能、要不要也做一做那个功能，或者某一个领导突然对某个东西感兴趣随口问了一句， 大家就蜂拥而至，要修改原有的产品计划，做这个功能。
这样的情况时有发生，虽说可以活跃产品团队氛围，但更多的却是干扰，导致产品的实际执行不能按照既定轨道进行。我的这个老板的“一定不优先”版块，目的就是降低这样的干扰。
他可以自如地给大家展示这个文档，问大家有没有最新的用户反馈，如果没有的话，我们就明确这个功能一定不优先；有没有什么新的信息需要我们改变策略，没有的话，我们就继续按照原定计划执行。这样一来，大家很快就能回到正轨，减少干扰。
总结
今天我给你分享的主题是如何制定产品优先级，这部分涵盖了制定产品优先级的计划、灵活调整优先级、沟通优先级、和与其他部门对优先级达成共识。
我还跟你分享了产品优先级的四个误区：第一，认为所有功能都优先；第二，认为优先的功能是最简单的功能；第三，制定优先级不考虑这个功能的潜在风险；第四， 在做产品计划时没有明确什么叫做最优先，什么情况下我们即使推迟产品发布也要等。
最后，我们跟你分享了产品经理的无知、无畏、无情，“权衡取舍要无情”是 Facebook 的理念，希望和你共勉。
思考题
我在文中提到的产品优先级的四个误区，你曾经中过哪个？
欢迎你给我留言。
产品经理进修第五天 管理你的产品团队相关推荐
- 产品经理进修第三天 产品经理基本功
13 | 如何撰写产品需求文档? 很多产品经理给人的印象就是每天开会,开完会就趴在桌子上写产品需求文档.上次和国内的几个产品经理交流时,有的产品经理告诉我说花好几个星期写的一份产品需求文档,工程师没看 ...
- 产品经理多任务并行处理，如何管理提效？
产品经理(PM)主要工作内容包含需求收集,需求分析,需求落地,项目跟踪,项目上线,数据跟踪以及对业务人员进行培训,协助运营.销售.客服等开展工作. 一个成功的产品经理的能力中应该有35%的项目管理能力 ...
- 产品经理进修第一天 产品经理的定位和合作
开篇词 | 打造千万用户的世界级产品 每次朋友聚会,甭管是高雅的奶酪红酒派对还是啤酒撸串,大家一见到我,总是会眉飞色舞地跟我吐槽,说我们刚刚发布的产品哪里哪里不好用,或者哪里哪里好玩得不得了:甚至和六 ...
- 腾讯产品总监曹菲：产品经理们，五年后，你会失业吗？ 【上】
馒头商学院2015年开学大课顺利结束,腾讯产品总监曹菲,前央视主持人.凯叔讲故事创始人王凯,文案大咖李叫兽,前凡客营销副总裁.<一个人的电商>作者许晓辉,杜蕾斯策划人.环时互动CKO老金, ...
- 渣男一般的产品经理长什么样？管过几百产品之后，谈谈如何做好这一行
PMCAFF(www.pmcaff.com):互联网产品社区,是百度,腾讯,阿里等产品经理的学习交流平台.定期出品深度产品观察,互联产品研究首选. 李明升:前微博初创团队产品负责人. 序:做一个优秀的 ...
- 小啊呜产品读书笔记001：《邱岳的产品手记-12》第22讲 产品经理的图文基本功（上）：产品文档 23讲产品经理的图文基本功（下）：产品图例
小啊呜产品读书笔记001:<邱岳的产品手记-12>第22讲 产品经理的图文基本功(上):产品文档 & 23讲产品经理的图文基本功(下):产品图例 一.今日阅读计划 二.泛读& ...
- 产品经理和售前工程师_如何区分产品经理和产品工程师的能力
产品经理和售前工程师 谁是产品工程师? 有时很难区分产品经理和产品工程师. 在这篇文章中,我们将尝试找出答案. 在一百一十一个职位中,产品经理也许是最令人困惑的. 事实是,从战略产品经理到电子商务或产 ...
- 策略产品的进修之路—了解策略和策略产品
著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处. 其实生活中处处是策略.很多科学里面,也都有策略的痕迹,如何定价是策略,如何分配是策略,诸如此类还有很多. 了解什么是策略 策略是什么, ...
- 产品经理遇到瓶颈，如何突破？硅谷产品教父Marty Cagan 告诉你
想转行产品经理,但投递的简历石沉大海,我该怎么办? 感觉自己产品经理的职业发展遇到瓶颈了,突破不了,我该怎么办? 有很多小伙伴问我这类似的问题. 我都会告诉他12个字:多学习.多总结.多实践.多交流 ...
最新文章
- C++ string 详解
- HDU - 3974 Assign the task （DFS建树+区间覆盖+单点查询）
- log4j2配置文件的故事
- Flutter漫说：组件生命周期、State状态管理及局部重绘的实现（Inherit）
- 向大厂看齐！为自己的程序增加自动转储的功能！
- 小android模拟器,小姚Android模拟器工作室版本v6.2.7.0正式版
- 实时体积云渲染(地平线)：一.云的生成
- 不敌 Java、C/C++、Python，28 岁 VB 究竟输在了哪？
- VMware快照功能与（非永久）永久磁盘详解
- MFC编程记录--图片控件类
- SpaceEmacs Rock Day2 学习笔记
- .ico 图标下载网站推荐
- 打卡day07 python基础—函数
- 并发和并行以及线程安全
- 浙江环宇集团“营改增”项目启动会成功举办
- java配置环境变量path(JAVA配置环境变量失败)
- android使用精伦身份证读卡器读身份证
- 通过SecureCRT打开HCL模拟器命令行
- 随机减量法matlab程序_Matlab马尔可夫链蒙特卡罗法（MCMC）估计随机波动率（SV） 模型...
- B.特定领域知识图谱知识推理方案[一]：基于表示学习的知识感知推理算法[对抗负采样、Logic Rule，链接预测任务]在关系预测、推荐场景下应用