❶ 如何开始学习前端知识，我的基础比较差
一、明确目标
1、明确自己以后要做什么，需要掌握什么技能。很多人在不知情的情况下盲目学习。首先，你知道公司现在需要什么人才，你应该为什么目标而奋斗。
2、系统的规划，每天学习哪些新知识和每天做的作业、练习。很多人都想自学web前端，以为过几天看完教学视频就行了。但事实上，想通过学习web前端找工作，没有4-6个月或者接触项目实战很难做到。因此，规划是必要的，而且需尽早开始规划。
3、注重学习方法，很多人在学习web前端的时候，刚开始学习的时候选择了错误的学习方法，因此最终注定要放弃，回到原来的岗位继续做自己不喜欢的事，学习web前端需要一定的技巧，在开始学习之前要多问问别人，不要盲目的自学，浪费时间。
二、掌握基础技巧
一个优秀的网络前端开发工程师必须具备系统的知识和丰富的工作经验，因此，许多大公司很难招聘到理想的前端工程师，甚至高薪也是如此。那么如何系统地学习实用的企业 web前端技术呢？在此，源妹儿不再进行技术讲解，而是集中进行技术讲解。技术并非黑白分明，只有对错，技术见仁见智。
1、必须掌握基础的Web前端开发技术，包括CSS, HTML, DOM, BOM, Ajax, JavaScript等等，在掌握了这些技术之后，还必须清楚地了解它们对不同浏览器的兼容性，渲染原理以及存在的bug。
2、要想成为一名合格的前端工程师，还必须具备网站性能优化、SEO、服务器等基本知识。
3、要学会利用前端的各种辅助开发工具。
4、除技术层面外，还应具备以下方面的理论知识：代码的可维护性、组件的易用性、层次化语义模板和浏览器分级支持等。
三、了解框架
做前端开发的都知道3大框架：Angular,Vue,React，下面说说他们的特点。
1、React：次组件重复渲染问题需要手动优化；rex可以用于状态管理，函数化，不可变，模式化，时间旅行；JSX，完全的 javascript功能；更加繁荣的社区生态。
2、Vue：可使用JSX，但推荐使用模版语言不是JSX；
3、Angular：包括模板、数据双向绑定、路由、模块化、服务、过滤、依赖项注入等所有功能的完整 MV框架；Typescript；比较 UI与后台数据一致性的不完整数据检查。
4、jQuery ：还推荐使用，它使用简单，学习方法也很简单。只要根据产品文档完成几页的工作，你就不需要做任何事情。然后，查一下这些文件。这个框架可以帮助你屏蔽浏览器的多样性，让你更加关注 Web开发的本质和学习。
5、Boostrap:它无疑是目前使用最广泛的一个框架。它是一套美观，直观，实用的网页设计工具，可以用来开发跨浏览器兼容性好，视觉效果好的网页。这个软件提供了很多流行的简约风格的 UI组件，网格系统，以及一些常用的 JavaScript插件。
四、注意事项
1、有必要理解产品的逻辑和形成过程——希望参与开发产品的相关人员可以参与到产品讨论中，以了解需求。并理解产品隐藏在未来的需求！
2、想要知道交互细节——想要参与产品开发页面的相关人员参与交互讨论，想要了解交互和设计细节！确保网页的结构合理且可扩展！只要有合理的建议！
3、了解资料界面-了解产品相关模组所需资料，与相关技术人员沟通并形成文件。
4、学习行业最新技术，参与行业交流！
前端是网站的门面，是背景实现和视觉表达之间的桥梁，贯穿整个产品开发过程，起着承上启下的作用。一个好的前端工程师可以很好的理解产品经理对用户体验的要求，也可以很好的理解后台工程师对数据逻辑或者程序逻辑分离的要求，并将这些要求转化为前端开发工作。
最后，如果基础特别差，建议可以选择前往培训班学习。重庆源码时代，专注于JAVA、H5前端、Python等IT教育培训，着力于为企业培养编程、设计、产品等方面的“实战型”人才。为互联网市场培育了10W+精英学员，学员毕业平均首薪7500+，专业就业率高达98%，学员口碑推荐入学率高达80%。无论你是零基础还是想转行，来源码时代，带你实现高薪就业~
❷ 数据分析与埋点，产品经理必须掌握的知识和技能
产品经理必须随时全面而准确地了解自己产品的各项数据，否则只能凭着感性在规划和设计产品，容易犯错误。因此，看哪些数据，如何统计和分析数据，如何进行数据埋点，都是产品经理必须要掌握的知识和技能。
如果你对此还不甚了解，可以通过这篇文章，快速地知道一个大概并枯，然后待到在工作中学习和实践时，就更加容易上手了。
首先简单讲一下什么是数据埋点。数据埋点通常是指开发工程师基于业务、运营或产品经理的需要，在产品前端程序中植入相关代码，以获取用户行为等数据的一种技术手段。
对开发人员而言，埋点需求同性能需求一样都属于非功能性需求，它们与功能性锋陪需求一起组成了产品需求。
网页中最常见的埋点方式是通过JS代码来实现的。
比如为了统计用户的点击事件，那么在每个链接或按钮处，都增加一段JS代码，用户一旦点击，无论页面是否有跳转、刷新等，都悄悄地请求了服务器，也就把一大堆信息传给了服务器存下来，包括用户的IP地址、地理信息、浏览器参数、点击的对象、时间等等。
又比如为了统计曝光事件，先定义好何为有效曝光（例如完成加载、渲染并进入用户视界），然后在有效曝光发生时，执行一段JS代码，把相关信息传输到服务器。
如果是手机APP或智能设备，则不同于网页主要使用JS代码的方式，它们往往被植入SDK（Software Development Kit，即软件开发工具包）来实现数据埋点。同时，为了避免频繁连接网络上传或下载数据，通常会将数据先存储在手机本地或智能设备中，等到一定的时机，再一次性同步至服务器。
一银蔽蠢定要记住的是，数据埋点只是数据统计和分析的一种技术手段，并非所有的数据统计都必须要有数据埋点。
比如网页事件。在通过HTTP或HTTPS协议请求时，也就是访问各种网址时，浏览器发送给服务器的数据包中，不仅仅是地址栏中你看得见的那一行链接地址，而且还已经包括了诸如浏览器信息、用户信息、来源URL等，这些信息无需再通过埋点，只需要在后端接受请求的程序中加以解析，把有用的存下来即可。
还有一类数据，也是无需埋点的，比如有多少用户成功收藏了一篇文章，这本就属于功能需求的范畴，业务数据中已有记录。
好了，通过前面提到的各种方式，数据有了，但这还不是最重要的。
有了数据之后，还需要根据需要，从这些可能相当杂乱、冗余的数据中选出有用的，按照有利于查询和分析的方式进行二次加工和存储，使之与生产环境中实时变化着的数据隔离开。然后在此基础上，生成各类报表，或者提供一个可自行敲入SQL语句查询数据的界面。
稍有规模的公司通常会有专门的BI团队，他们的主要工作就是开发并维护一个这样的数据系统，供包括产品经理在内的各方面人员，随时随地地查询和分析数据。
❸ 关于前端页面，产品经理该如何理解/如何设计
前端页面，意味着用户的直接体验过程，这当中包括了很多的技巧，我们不妨从下面几个方面来考究这个问题
界面的美观
爱美之心，人皆有之，前端页面作为用户的直接体验，其美观度无疑是是否能够给页面加分的一个重要点位，现在的用户一般情况下，我见过最多的就是界面设计的一定要逗枝高大上，甚至是有一些花里胡哨的，有些时候，甚至功能还不如界面重要，比如大屏展示，要的就是要侍指银炫，给人的感觉就是貌似要很高大上。也的确，有些时候就是要好看，其实用价值甚至不如审美价值！
页面的交互
页面的交互无疑是另外一个加分点，特别像管理系统之类的系统，涉及到很多用户的交互，那么多的交互都是要算工作量的，现在的人工作都很忙，那么在系统界面上的设计就得考虑到这个方面，需要尽可能的智能，怎么说呢，就是尽可能的减少用户自己的操作，有很多可以通过代码去解决的就不要用户自己手动去操作，一方面用户操作过多可能会出现未知问题，一方面用户操作过多，直接体现就是工作量上的提升，作为用户就是想偷懒，界面上的设计自然越智能越好。特别是现在的行业竞争相当的激烈，能够从界面用户的体验上夺得加分项，那肯定能够提升产品的竞争力度。
页面的元素
页面元素，说白了就是用户在操作过程中使用到的页面组件，这个和页面的交互会有一定的交叉，用户想以最少的步骤来完操作，那么页面上的交互组件的选择就很重要，由于页面就那么大范围，不同客户的设备还有差别，手机，PC都会有不同的体验，所以一款优秀的产品，在界面的组件选择上肯定具备良好的体验
产品的质量
产品的质量，可以从两个角度来分析，一方面就是产品的功能，产品经理的工作就是需要深入的理解用户的需求，需要以客户的需求为中心，细细揣摩用户的真正需求，有时候客户表达的是一层意思，但是真正想要的确实另一层意思，这就需要产品经理去和客户沟通，只有深入的理解了产品，才能设计出符合用户需求界面出来；另一方面，不得不说的就是产品界面的bug，说的直白一点就是产品的稳定性，用户实老宴用这个产品，能够反馈给用户的就是界面上的，那么界面的bug能降低到最少无疑是必须的，这就需要不断的测试去改进，再者，产品都是不断改进的，有可能产品初期并不完美，那么提供一个反馈界面可以供用户填写，这就能收集到用户的直接反馈，那么也就能够从用户反馈中去不断的改进，当然这不仅仅是界面上，而是整个产品
总结
一款优秀的产品绝对是用户口碑好的，就算产品再好，用户的体验不好也是无济于事，产品的界面设计也是需要从多个方面考虑，以上仅代表个人的一些见解，并不一定准确。
❹ 产品经理如何与设计和前端沟通
我在从事产品工作之前，曾经是做过美工，后来是UI，最后差点成为前端。大家知道，在互联网初期，分工没有那么明确，美工的工作不仅是作图，还要把图片输出成页面，后面才细分为UI设计和前端，还有小公司的美工会做产品的工作，根据领导的需求，输出DEMO设计图，其实也就是最早的原型图。虽然在那几个岗位上没做多久，但对于我后面从事产品的工作帮助很大，尤其是和这些职位上的人去沟通，可以说是知己知彼了。
我一向奉行四个字原则： 先理后兵
如何和设计先理？
设计心理：最怕高保真原型，最讨厌需求不停改动，最反感别人否定他的作品、最崩溃产品告诉他如何设计（产品说：你就照着那个设计就好了）。。。
第一、避免输出高保真原型
产品在输出时，除非有特定要求，不要轻易输出高保真原型。如果设计完全按照原型去做，因为高保真原型做了太多设计的工作，让设计发挥的空间非常小。如果设计不按照原型，加入自己的设计元素，很可能会偏离需求。不仅如此，需求方已经评审过原型，设计变动太大，需求方都会认为你需求发生了变动，增加了不必要的沟通。
第二、需求清晰全面，原型页面不可缺少
在原型设计上，产品要把所有可能出现的页面全部画出来。因为设计往往是根据产品原型页面去画的，如果原型缺少页面，那最后会出现前端无页面可写的状况。
第三、对设计作品，先褒后贬，先表扬，然后再提修改意见
作为一个产品，要有一定的审美能力，每个设计做出的作品都会有自己不同的风格，很难有完全能和你合拍的设计。这样就难免要和设计沟通修改的问题。沟通时，也是四字原则：先褒后贬，切记口无遮拦，妄加评论。最好以：设计得很好，但你觉得如果换种方式会不会效果更突出？或是我很喜欢你的设计，但好像和我们的主题好像偏了一点，吧啦吧啦..
第四、由设计输出页面规范，产品审核
页面规范也就是一个标准，很多时候产品也会输出，但在这里，我建议页面规范由设计和产品一起输出，设计为主，产品为辅。因为在视觉效果上，设计会比产品更专业。设计输出规范，会保证页面的整体统一性，也提高设计的参与度，而不是设计完成后高高挂起，也要参与后期的验收，让专业的人负责专业的模块是最明智的选择。
第五、让设计与前端直接沟通，产品协助
设计图完成并通过评审后，让设计与前端直接沟通，产品只是沟通部分需求细节。
接下来就是和前端的理了
前端心理：最怕需求不明确，最讨厌听这个应该很快吧，最反感产品天马行空的想法。。。
第一、需求明确，尤其是交互，页面跳转清晰可寻
第二、评审时间时按照功能去评审，而不是页面
第三、做新的特效前，找好参考网站，别人已有的绝对是可以实现的
第四、没有把握的效果，提前与前端沟通，或是提出问题，让前端建议一个解决方案
以上的这些就是产品的理了。如果你的理到了，对方却不合作，那就后兵了。你的兵不是指自己去找他们干架，这个肯定是不可行的。项目经理就是你的兵，只要你占住了理，后面就让项目经理出马解决就好了，不要直接冲突，否则后期合作会比较麻烦。
要收尾了，想起自己手下产品的问题，再哔哔几句
第一、需求变更时，应有项目经理或是需求方发邮件或是群里公告通知项目成员，而不是由产品去告知，避免成为众矢之的
第二、产品虽然需要坚持自己的观点，甚至是要强势点，但不要趾高气昂，要时刻保持谦虚礼貌，与大家是合作关系，尽量打成一片
在其他文章里我分享了与需求方和开发沟通的内容，感兴趣的可以看一下 《产品经理如何与需求方沟通》 《产品经理如何与程序猿沟通》
❺ 写给产品经理之前端是如何展示后端数据的
移动互联网的迅猛发展让移动APP呈现出爆发之势，这两年更是移动开发程序员的春天。
今天的互联网上充斥着产品与技术的撕逼。也许你会问产品经理到底要不要懂技术？由此引申出，产品经理到底要不要懂设计？产品经理到底要不要懂运营？产品经理到底要不要懂市场？产品经理到底要不要懂业务？这所有问题的来源都是大家对于产品经理的工作认识不一致。
每个人心中都有一个产品经理的定义，产品经理在技术方面更多的是去统筹和规划。不是画画图写写文档就可以了。这里面更多的需要的是对逻辑的梳理和拆分。
例如很简单的一个app内嵌发红包的活动，产品经理需要确定整个活动的流程。从用户进入页面的那一瞬间就应该被产品经理掌控。他的每一个步骤，每一个操作会带来什么结果，有哪些变量会导致活动进程失败，这些都要产品去考虑。等到活动逻辑和过程全部梳理完成，下面就要进行拆分了。还是以发红包为例，红包中金额是客户端写死还是服务端进行计算，红包领取资格需要服务端返回几种结果，每种结果对应客户端的提示是什么，用户领取红包以后服务端需要记录那些信息（帐号，uid，领取时间，金额，是否使用等），客户端哪些地方需要加入计数器进行数据统计。总结起来其实就是，产品经理需要根据开发的每一个环节，将所有内容分类整理，并分发给不同部分的开发进行研发。最后，还需要给测试准备好check list，当测试按照check list测试完成以后，才可以上线。
以上种种都需要产品对前端如何显示后端数据有一个清晰的认识才能规划好数据如何展示。是APP写死呢还是后台返回，在用户任务进行的时候有哪些可能case。只有搞清楚这些，产品才能在实际的开发中掌握好整个项目的流程与进展，才能不被开发给糊弄。
简单的说，前端仅仅将后端返回的数据展示在页面上，不做过多的逻辑处理。前端需要关心的是，数据如何更好的展示出来，页面效果如何做出来，以及其性能问题。
而后端就是负责对这些数据进行处理，提供给前端展示。
前端一般有H5、android、ios等多端界面。数据不要轻易写死在前端里面，不然到时候三端都要修改，费时费力。而将这些变化多数据让后端进行处理，前端将这个数据取出来显示出来就行了。
举个例子吧，下图是一个美团app首页团购的展示效果
上方美食等8个icon一般为固定展示栏目，非特殊情况不会修改。那么前端一般是写死在app中，等到需要更新的时候更新app即可。
而下方猜你喜欢是一个列表，该列表数据经常变化，数据写在服务端维护，app取出数据进行展示即可。
首先，前段对页面的展示是分两步走的。
第一、在本地绘制好界面，当然此时未连api会填充一些假数据，或写一些默认值。
第二、连api进行数据获取，将数据填充进界面。
既然如此，咱们简单看下前端拿到的数据到底长什么样的吧。
现在前端获取到的数据基本是json数据。
不需要特别懂里面每一个的含义，只需要知道，前端通过"title"这个键名(key)就可以拿到"合辑护甲"这个值(value)。 "title": "合辑护甲" 这一整个就是俗称的一个字段。通过该字段前端就可以获取到列表的标题了。当然这个列表只是简单的展示用，还有诸如图片地址、优惠信息、已售份额等信息没有提供，这就是缺少字段的情况。
前后端就是通过这样的一个定义获取/传递数据的。
考虑到后期拓展、需求变更等，一般来说，涉及到计算的、可能有变动的，一律不要让前端来弄。
还是刚才那个例子，在刚才那个列表中有一个“立减5元”的橙黄色tag。
这个tag信息，如果考虑不充分，比如说，后端只提供一个数字5，然后前端在其页面写死“立减x元”，x为填入后端提供的数字，颜色固定为橙黄色。这个如果需求不修改还好，如果后期需要新增一个“满20减5元”的红色tag不傻眼了吗？
到时候只能通过升级app来解决，而且不升级的老用户将永远看不到这个红色的tag。
所以说，考虑到程序的可复用和拓展性，需要产品将后期可能新增或变更的需求考虑好，和前后端进行沟通，让前后端设计好实现，尽量降低程序的耦合和硬编码。这才能使一个产品更加健壮以及让苦逼的程序猿少加班的关键。
那么刚才那个tag的需求如何设计才合理呢？
首先是tag显示文字，全权由后端提供，可以是多个字段，由前端进行拼接。然后是tag的颜色，提供几种样式让前端判断是一种可行的办法，但是直接提供tag的色值给前端的这种方式无疑给前端展示增加了无限的可能。
是不是也要增加一个tag形状的字段呢？
俗话说，过犹不及。tag形状这种东西真的很少变更，字段太多无疑会增加开发的时间成本，而且会让人有一种舍本逐末之感。
前端获取到后端数据后，如果前端不主动刷新重新请求数据的话，这个页面的数据在该页面销毁前会一直保持不变。
如何理解？
首先，第一次进入一个页面，该页面数据为空或默认数据。此时前端会链接api请求数据。数据请求完成后，填充进页面。那么本次联网请求就完成了，在前端不进行二次数据请求之前，该页面会一直保持本次请求的数据。也就是说，就算服务端修改了数据，前端此时是不能事实的进行更新的，因为我前端不知道你数据更新了。
那么在这个需要实时更新页面数据的时候和前端讲这种需求会被前端直接回绝：“做不了”。这个时候产品咋办，怪怪妥协？最后背锅的还是自己，而且自己也不知道是真做不了还是假做不了。
实时刷新也不是不能做，只是做的成本略高，需要和后端进行配合，像微信聊天一样和后端进行长连接(socket)，这样服务端数据变更前端就知道数据变更了。
当然如果稍懂页面刷新机制的话，可以要求前端在适当的时机进行页面刷新，如在页面可见的时候进行刷新，这样用户每次看到的都是最新的数据。也可以让用户主动刷新，如新增刷新功能。
产品懂技术这件事情，不仅会降低和开发同学沟通时的难度和被歧视风险，还会提升在面对开发同学意见时的判断力，会降低被技术团队忽悠的几率。同时，在需要向上级解释技术原因导致变更的情况下，也会有助于说服老板。
“闻道有先后，术业有专攻”，要相信自己所接触的开发团队是专业的，靠谱的，相信开发团队为实现需求所做出的技术方案是合理的，最优的。如果有质疑，可以加深沟通，以合适的方式提出自己的质疑。这里要补充一句的是，这个信任过程是需要建立的，也是会根据团队的表现不断变化的；同理，其实团队对于产品经理的信任度也是一样的情况。
吐槽是没有意义的，关键还是要解决问题。如果觉得产品经理不靠谱，那么有没有进行过深入的沟通？如果觉得开发不好沟通，那么有没有进行过了解，不好沟通的原因在哪里？如果当事人本身确实不可沟通，那么有没有考虑和对方的老板沟通，或者通过自己的老板如实反映情况？吐槽是最容易的，解决问题反而会很难。
❻ 零基础做产品经理需要哪些技能啊
伴随着互联网与传统行业的融合，产品经理职位逐步成为公司的标配，面对更广阔的市场来说产品经理还属于新兴职业。好的产品经理薪金极高，同样也需要具备很多素质。
接下来我们将按照工作中的职位来区分能力的掌握程度，例如产品经理的职位有：产品助理、产品经理、高级产品经理，像打怪升级一样，从助理逐渐到高级产品经理。
产品助理所需能力：逻辑能力、文档能力、竞品分析
产品经理：沟通能力、项目跟进、多线程工作能力、决策能力
高级产品经理：产品全局性、带队能力
1、产品助理
成为产品经理之前是需要一个助理阶段的过渡，在这个阶段，产品助理会接触一些功能点的需求，并不会接触到整体功能或者整条产品线。只要掌握了逻辑能力、文档能力、竞品分析，我认为就够了。
至于所谓的原型能力，其实我觉得这个对产品经理来说都不算什么必备能力，原因以下分析：
1)逻辑能力
什么是逻辑能力?其实就是大量的if…else…所组成的一个闭环。再复杂的系统，也是由底层很多“是”败枯亏“否”所察神组成的。
tips：
实践是最好提高逻辑能力的方式
可以看看其他产品经理写的产品需求，多关注流程
理解能力也很重要，但是逻辑能力强了，理解能力也就强了
2)文档能力
充分理解业务需求，将需求转为成一个个逻辑需求，最后输出产品设计。
以上这个流程需要落实到文档上，至于什么形式都不重要，重要的是便于研发理解，能给项目干系人都讲明白。
3)竞品分析
对于前端产品来说，这一点很重要：因为现在不是闭门造车的年代，我们需要充分了解市面上的竞品，对其进行分析。
切不能为了分析而分析，那究竟分析什么?简单来说，围绕你的KPI去分析竞品，竞品哪些东西可以帮你完成KPI目标，有则借鉴，无则思考，为什么竞品的功能要这样做，这样做达到什么目的。
这里解释下为什么原型能力不是必须的：产品经理画原型只是将一些流程和逻辑用直观的页面去呈现，UE会根据你的逻辑对页面进行交互设计，UI会根据需求在不同场景的展现上进行视觉设计，研发更多的是看一眼原型明白这次要做什么，更何况FE最后以UI图为准。
所以，产品经理的原型，只是一个抓手，各个岗位通过这个抓手开展工作。至于高保真的原型，实际工作中没有时间给产品经理进行炫技，只能当一个技能提升。
以上就是对产品助理能力的说明，但是对于产品助理在这个阶段一定就要明确：产品经理究竟是做什么的。产品经理画原型?交互你比不过UE，视觉你比不过UI;功能实现?这个是研发和测试的活;项目管理?PMO可能第一个表示不服。
2 、产品经理
基本很多人都处在产品经理这个阶段，因为我认为产品经理到高级产品经理不再是简单能力的提升，更多是眼界和思维的转变。产品经理，是负责产品整体功能模块，简单来说就是很多功能点所组成的一个系统。
1)沟通能力
沟通能力也是被人说烂了，很重要，但究竟什么是产品需要的沟通能力?很简单，让别人按照你的想法去做。
比如有个需求和研发沟通，需要给研发讲解为什么做这个需求、流程是什么样的等等，其最终沟通的目的还是说服让研发给你做这个需求。
tips：
沟通能力区别于表达能力
get不到对方的point，要么是对方的表达能力问题，要么是自己的逻辑能力问题
提高沟通能力有很多技巧，技巧再多也比不上大家在一条船上有用
2)项目跟进
项目跟进不是项目管理，项目管理是PMO的工作。项目跟进也就是需求跟进，对于评审完成后的需求，产品经理必须要主动的去跟进。
无论这个需求是否进入排期，是否已经开发，开发中遇到什么问题等等，只要这个需求没有上线，产品经理都有责任去了解需求在什么阶段、遇到什么问题。
项目跟进是产品经理的加分项，是产品经理责任心和专业度的体现，在这个阶段也是和研发、测试小伙伴们沟通感情的好阶段。
3)多线程工作能力
产品经理工作比较繁杂，经常负责多个需求，而且产品经理也是众多工作的交叉点，很多和需求功能无关的事情也需要产品经理去解决。能够随时切换不同工作状态，是产品经理基本功。
实际工作中，工作打断后，想要再去找回之前的工作状态是比较难的事。
4)决策能力
实际工作中经常会遇到这样的话：“怎么做都可以，听产品的”，“做不做这个功能，听产品的”等等。产品经理是需求的owner，产品功能的走向需要产品经理来决定，你有申请资源使用资源的权利，对应的就有承担产品走向的责任。
如何正确的做好决策?
靠经验：来自长年对用户、市场、竞品、业务的了解，结合自己理解得出的经验;
靠数据：依靠市场调研、竞品分析、运营数据、用户调研等，从数据维度上支持自己的决策;
靠团队：通过和业务、研发、运营等同事交流，从他人的视角更全面的得出结论。
最后，你收集了很多信息，可能有的信息还是相悖的，但是最后决策必须是你自己决定，因为你是产品经理。
3、高级产品经理
高级产品经理基本已经脱离了产品功能和需求，需要跳出来，站在一个整体的角度来审视产品——这个是最难的，因为你的所有判断和想法都是你自己思考出来的，你需要平时的积累，输出一套属于自己的方法论。
1)产品全局性
通过自己的方法，对产品有一个全局性的思考，比如以下一些问题：
产品的界限在哪里，什么需求是做了没有用的
为了完成目标，有哪些切实可行的方法，结合业务、运营等全资源考虑
如果一个全新的产品立项，你能否用一张图反映出业务规划
能看透产品的人很少，上述那些能力通过训练可以掌握，对产品全局的感知，我个人认为是考验一个人思想的高度和宽度。说的有点虚，因为我没有掌握这个能力，但是我觉得方向还是对的。
举例：
一次在MBR会议上，产品boss对我们部门的产品提出一些切中要害的建议。我们采取矩阵管理模式，产品boss没有直接负责我们部门的产品，只是通过会议上PPT的讲解，就可以一针见血的指出一些问题。
每个产品都有属于自己的本质，这个本质会连接到用户解决痛点、会连接到公司实现目标、也会连接到所有部门为这个本质去工作。所以，从产品的全局性抓住产品本质，才能更好的创新出符合用户的功能。
2)带队能力
其实很多产品经理就开始带队了，但我还是觉得在高级产品经理这个阶段带队更加稳妥。你需要带领小伙伴们一起成长，当然一部分产品工作也需要别人来分担。
带队没有什么可说的，切记工作中你要说：“跟我一起上”，不要说：“弟兄们给我冲”。