什么是产品经理?

最近遇到一些事情,引发了一些琐碎的思考,尤其是对这个职位本身的思考。

一方面是大背景的变化,另一方面是个人心态的变化,所以就想谈点对这个岗位本身的一些理解。

经常能在网上看到各种调侃,诸如产品经理是条狗,什么都不会所以来当产品经理吧,看到这种自黑或者他黑,通常都是会心一笑。

随着行业的发展,流量红利的消逝,产品经理的门槛会逐渐的提升,主要原因有:

  • 市场上不再需要那么多用户产品经理;
  • 每年都会有很多优秀的应届生涌入这个行业;
  • 存量市场还有大把的产品经理。

供给端在紧缩,需求端有增无减,所以门槛提升是必然的趋势。

观察下来,最近几年产品经理岗位本身有这么几个发展趋势。

第一种是传统型的用户体验型,偏向于用户体验。

第二种是业务型,主要是业务+产品,比如电商产品经理、社交产品经理,大多是在一个细分行业有深耕,有一定的经验积累。

第三种是中台型,主要是偏向一些基础型的业务,比如推荐产品经理、支付产品经理、风控产品经理、中台产品经理等。

第四种是通用型,主要是偏向于通用型的业务,比如增长产品经理、商业化产品经理,因为所有的产品都绕不开流量和变现这2个关键词。

此外还有一些从2C行业开始往2B行业转的。

现状呢,大概就是这么个现状,具体想怎么选择,看个人规划,看能力,看意愿。

虽然说大家的title可能都叫做产品经理,然而不同的行业,不同的公司,不同的团队,产品经理做的事情差异可能会很大。

之前没接触过交互这个职位,最近和交互设计师一起合作了几个项目,感觉两者职责交叉是比较多的,刚开始合作的时候还挺不习惯的。

我们目前的协作流程是产品出流程图和PRD,交互来出原型图和交互文档,之前因为没有交互环节,产品直接把所有的文档出了。

所以我就在考虑这么个问题,如果产品把交互的事情都做了,那交互这个岗位的定位到底是怎样的,又或者说如果交互的产品感好一些,那产品这个岗位的定位又变成了什么?

合作了几次之后,我发现还是有不少差异点的。

首先,交互的工作方式是项目制的,也就是一个项目接另一个项目,而产品是需要长期跟进和迭代的。

然后,交互童鞋更擅长的是从用户体验的角度来考虑方案,产品需要综合考虑用户价值、产品价值、可实现性、性价比、时机等维度之后,再给出一个可行解,不一定会追求用户体验最好的方案。

最后,产品需要对最终的结果强负责,交互是不需要的。最起码我们团队是产品背这些数据指标,交互跟对应合作的产品绑定。

有了这样的合作经验之后,我就在反思之前做的事情,自己做了多少个需求?有多少需求是自己想做的,又有多少是上司交代自己要做的?

如果只是落地别人的需求,画画原型,跟跟项目进度,那作为产品经理的你,工作三五年之后,核心竞争力在哪里?每每想到这个问题,我就很方...

现状理清楚了,和产品职能最接近的岗位也对比了下,最后来看下目前自己理解的产品经理。

越来越觉得产品经理有几项能力是非常重要的,首先是决策能力,其次是解决问题的能力,然后还需要结合着怀疑精神和迭代精神。

决策能力很重要,产品的一个决策可能为公司带来几百上千万的收入,也可能为公司带来几百上千万的损失。

产品核心的工作流其实就是决策流,大到战略要不要做,小到战术如何做,再到功能、交互、视觉、按钮、文案,这些东西,无一不是需要进行决策的...

所以产品需要能输出高质量的决策,以及持续输出高质量的决策。市场分析、竞品分析、用户研究等方式,其实都是为了提高决策的准确率。

解决问题的能力就是填坑的能力,动用一切可用的资源把问题解决掉,而不是说我做了,但是没做完,或者没做好。

有怀疑精神其实挺难的,不管是怀疑自己还是怀疑他人。

一方面是想法一旦形成,我们就会选择性的忽略很多东西,想办法去找支持自己想法的证据,正如心理学里面那个看不见大猩猩的实验,另一方面当我们面临改变的时候,总是会本能的拒绝。

有时我们可能需要自己推翻之前的观点,又或者是被他人推翻,这个过程一定是很不舒服的。但确实是有必要的,比如之前的条件不成熟,环境发生了变化,或者是忽略了一些要素。

有时我们可能不太认同别人的观点,需要提出一些不同甚至相反的观点,这要求我们既要有能力去怀疑他人,又要愿意提出来。

迭代是在之前的基础上进行自我提升,明确哪些东西是可行,可以后续复用的,哪些是不可行,需要进行修正的,然后再不断的打怪升级。

这些都是产品经理的能力储备,实际并没有说清楚到底什么是产品经理,为了解决这个问题,我们退后一步,来看一下产品经理的定义。

先来看下百度百科的定义:

产品经理(Product Manager)是企业中专门负责产品管理的职位,产品经理负责市场调查并根据产品、市场及用户等的需求,确定开发何种产品,选择何种业务模式、商业模式等。并推动相应产品的开发组织,他还要根据产品的生命周期,协调研发、营销、运营等,确定和组织实施相应的产品策略,以及其他一系列相关的产品管理活动。

没有相关经验的人肯定是看不懂的,有相关经验的人大概率也不会再来看这个定义。嗯...

再来看下俞军老师的定义:

产品经理是以创造用户价值为工具,打破旧的利益平衡,建立对己方有利的新利益链,建立新平衡的过程。

最开始看到这句话的时候我其实是不怎么理解的,随着工作年限的增加,对产品理解的深入,越来越认同这个定义。

从这个定义出发,来看下整个产品链条,首先是要能够创造价值,其次是能够把价值传递出去,最后是能够从中获取到价值。

那产品经理就是有能力和意愿,并且会用实际行动去打造这个价值闭环的人。

能力,无需多言,属于基础条件。

意愿,指的是愿意去做这些事情。有能力有意愿,固然是最好的。如果能力储备稍差一些,有强意愿也是可以的。

实际行动,指的就是为了完成这个价值闭环,做了哪些事情。

能够满足这几点的人,可以称之为产品经理,反之则不可以。

比如一个人很有能力,也很有意愿,但从未付出过什么行动,只是说说而已。

再比如一个人有能力,也很有意愿,但东西只做出来了,并未关注后续的东西,或者说没创造什么价值,那同样也不能称之为产品经理。

所以啊,产品经理只是一个title,重要的是你做了什么,以及怎么做的。

以上就是本文的主要内容,欢迎斧正、指点、拍砖...

公众号ID:产品经理从0到1

  有同学可能会听说过这样一句话:“一个产品经理就是一款产品的CEO”。

  黑马的一位大佬说:产品经理是 “以产品为笔,与世界对话!”。

  作为互联网产品规划师,产品经理是产品的总owner,需要发现问题,并且描述清楚,进而转化成任务,最终实现产品目标。

  以一款APP从0到1上线过程为例,产品经理需要分析市场需求,针对需求确定产品的定位,然后制定方案,设计产品原型图,再组织协调团队资源,跟进产品开发、测试以及后续的上线等工作内容。


  1.产品经理每天的工作大致是什么?

  体验产品、观察竞品、看用户反馈、脑爆各种创意,将创意写下来,协调和跟进设计师、程序员把创意做出来。

  2.想做产品经理,需要掌握的能力是什么?

  产品经理不仅要会:需求分析,产品原型设计,完整项目管理,团队合作。还要懂业务、懂策略、懂数据。能够了解企业真实需求,提出优化解决方案,才是一位优秀的产品人。

  3.产品经理主要有哪些类型?

  根据服务对象不同,划分为B端产品经理和C端产品经理。两类产品虽然具体工作侧重点不同,但是底层能力和工作方式是一致的。

  按照工作内容不同,又可以大致分为4个类型:功能型产品经理、技术型产品经理、策略产品经理和商业产品经理。

  4.目前的市场趋势是什么样的

  一场疫情,让企业数字化转型的速度加快,在国家十四五规划中,也多次提及数字化转型。

  谈及数字化,很多人觉得很高大上,其实我们生活的方方面面早已被数字化覆盖,支付方式由之前的线下转到线上属于数字化转型、线下销售转为线上直播带货也是数字化转型、企业管理由传统人力转到线上系统管理也属于数字化转型……

  在数字化转型过程中,除了面向用户的产品增多之外,面向企业的To B产品也呈现量级增长。而无论是To C还是To B的产品,都需要产品经理来把控上线进程。所以企业对产品经理的需求爆发式增长。

  5.产品经理是否需要懂代码?

  一般来说,产品经理不需要会敲代码,也不需要能看懂代码,但是一个完全不懂技术的产品经理很难和程序员沟通,也很难写出一份优秀的需求文档。

  那么产品经理对技术需要了解到什么程度呢?知道某个功能是找哪位程序员去实现或修改,免得出问题的时候到处找人。

  简单了解程序的运行原理,和功能的实现难度,比如一个可以实时语音聊天的小程序难不难?这样可以更好的评估开发排期。

  作为产品,需求靠谱,产品规划清晰,懂数据才是关键。由于很多产品迭代和优化是根据用户产生的数据来进行的,所以数据查询和分析是产品经理必备的技能,MySQL、R语言、Excel等各种软件和分析方法越精通越好。

  6.产品经理有没有专业要求?

  客观来说,有计算机专业背景的产品经理在最开始是有一定优势,但是产品经理的专业背景从来不是决定性因素。

  本来产品经理就没有所谓对口的专业,业内很多产品顶尖专家在大学期间学的内容也和IT没啥关系。正所谓:人人都是产品经理。

  一个人文社科专业毕业入职阿里的时候问HR:为什么会录用我这个专业的人来当PM?HR的答复是:凡是技术能解决的问题都不是问题,真正的问题是在解决人与人之间的社会问题上。

  所以说,决定因素最终都是在人的本身:自己是如何看待优劣势,并加以利用和弥补的。

  7.产品经理未来发展方向是什么?

  不夸张的说,产品经理是最接近CEO的岗位。产品经理作为产品的leader,指点江山,一般很少跳槽。主要路径是找到一个好的方向,好的行业去深耕,从产品经理(助理)做起,升级高级产品经理、产品总监,CEO,或者创业拉伙做自己的公司(产品)。

来 源:人人都是产品经理

在后台中,数据面板能够直观反映出业务变化,并有助于决策层发出业务调整与决策。那么搭建数据看板的时候,要如何搭建呢?又有哪些注意要点呢?

数据看板一般用作后台系统的首页,主要呈现公司当前业务相关或运营管理相关数据和图表,方便公司内部人员实时了解公司内情,掌握业务发展情况,并能够对数据变化做出业务决策。

数据看板是公司内所有人员都会关注的,无论是公司高层还是基层业务操作者都会关注相关的数据指标。只是不同的角色的需求不同,如下图:

不同的角色的默认看板页面是不一样的,要设计多份看板页面,至于不同页面是否可以互通,这就要取决于公司业务数据是否属于商业机密,牵扯到RBAC权限模型的设计,这里就不多赘述了。

设计看板可不是脑子一热就开始画原型了,那样得到的看板是不切合实际的,而且也不一定准确,尤其是对于数据大量且复杂的业务而言,需要先设计好报表。数据看板中有不少数据是需要后台去实时计算的,在数据量太大的情况下,筛选条件和统计项较为复杂时,图表加载速度会变慢,也会耗费大量系统资源。而如果先设计好数据报表,在数据看板中,查看图表的速度才不会收到影响。

不要急于数据可视化的设计,需要数据报表所呈现的数据经过多次测试没有问题,再经过至少一轮的迭代优化,再着手进行可视化方案的设计。

数据报表的设计需要经过以下流程:

b端产品经理不同于c端,业务是一切产品设计的核心,必须围绕业务进行产品设计。首先要明确分析目的,并进行业务诊断,最重要的是打通分析链路。

例如要分析利润曲线,与利润相关的数据有利润率、在架率、产品种类、报价策略、市场行情变动等

根据公司具体业务不同,明晰哪些是需要重点关注的,哪些是可以暂时搁置的,特别是要跟业务团队多沟通协调,共同商议出一个分析框架。

一般可采用枚举法,列举可能干扰到核心业务数据所有因素,再一一排查。

公司不仅要求分析业务结果等业务强相关数据,生产过程关系到每个人的工作效率和工作成果是否达标,生产过程同时也是对人员kpi的考核。

定义好分析框架后,要进一步确定观察指标,主要是对观察维度进行拆分,逐渐细化,只有在更精细的维度分析数据才最有可能得到准确的答案。

比如在架率又可细分为日间在架率和夜间在架率,还可继续细化为某某产品在架率,甚至可以细化到业务员王二在日间12:33误操作某交易量极大的产品,造成利润损失。这样就打通了从业务结果——生产过程的分析链条。

又比如报价策略有可细化为具体sku的报价问题,该数据又可关联到上游供应商近期内价格调整频繁,而报价策略未结合该特点导致该产品报价过高/过低。

维度细化的过程中,可能会逐渐拆分为一级指标、二级指标……n级指标,但并非拆分中的每一个维度都要作为观察指标。是否作为报表使用要结合公司业务特点并且和业务部门多次沟通协调达成共识。

在维度下钻的过程中确定哪些维度是需要进行统计的,哪些是不需要用到的。

数据口径指的是对于数据的定义,如果系统内部统计口径不一致,就会导致业务分析出错。如果不对数据口径进行清晰的定义,开发人员在调用数据时可能会直接采用已有的口径,这个已有统计口径不一定符合当前数据指标的需要。

产品人员应该单独书写一份关于数据口径的定义的文档,并上传至系统内部的文档共享系统,方便业务人员随时查阅。如果系统允许,尽可能与业务部门达成共识,形成一套标准的数据口径。

确定好需要统计的数据维度形成观察指标后,要对观察指标分类处理,有些指标属于关键性因素,有些指标属于次要因素。有些指标单位时间内产生的数据波动较大,统计频次可能要到分钟级。而有些指标数据波动较小,可能一天只有几次变动,统计频次可设定为小时级。

一开始的呈现形式以简单、好调整为主,不必急于线上化,也不必追求酷炫的交互效果。严格遵循mvp原则,用最小功能集合去迭代产品。

报表在设计初期必然面临指标的频繁调整,以及数据不准确,统计范围需要变更等种种问题。初期可采用系统定时通过邮件发送报表,报表的形式可以是一张简单的excel表格,这样先试用一段时间,确定要分析的数据字段、监控指标等没有问题后,再着手进行线上化的设计。

确认好线下的报表迭代优化完毕后,设计线上化的方案,一般考虑以下几个方面:

  • 默认查询时间,统计具有延时的特点,有些数据统计必须等待订单完成才能纳入统计范围,比如默认查询时间定为t-6至t-2
  • 排序规则,默认按照哪一项数据排序
  • 筛选项设置,哪些数据选项需要筛选
  • 统计项设置,哪些数据需要合并统计
  • 其他极端情况考虑,数据极限值,最大时间范畴,取数为空时的处理等等

大致的形式如下,但在实际业务中数据远比这个复杂:

报表线上化固然有其优点,方便、快捷,效率高。但是也存在一些弊端,比如不够灵活,excel表格可以方便做成各种你想要的数据透视表,而线上只能固定其中的几种。线下还可以采用任何关联要素利用vlookup进行匹配,线上则已经固化了分析指标。

因此,产品上线一段时间后,要及时复盘功能是否好用,是否得到认可。

  • 使用率:可通过数据埋点看该项功能的使用率,使用率不够要和业务部门沟通问题,及时迭代优化
  • 观察是否实现最初想要得到的目的,分析链路上是否还存在障碍
  • 用户满意度:与业务部门沟通,看使用过程中有什么不方便的地方,效率方面是否还可以得到提升

当数据报表完善之后,那么实现数据可视化也就非常方便了,效率是b端产品的核心,设计看板也不应该花费太多时间在交互体验上。这里主要满足以下几个设计要点:

  • 简单高效,优先满足查询效率,而不是酷炫的交互
  • 信息具有强关联性而不是孤立的一个数据,具体就是要有环比、同比来体现变化
  • 数据图表的刷新频次和统计频次要符合业务的需求,最好能做到实时更新
  • 选用的数据能够体现出趋势和规律,对于无趋势特性的数据,直接展示数字比较好
  • 对于不同的数据指标,不同的数据特性需要选用合适的图表。
  • 数据波动、对比、排序,不同的衡量方式也应该选择其对应的图表类型

数据报表可能有十几种报表,几十个数据指标,但这些并不是都需要呈现出来的,选用哪些数据指标和衡量方式,需要和业务团队沟通确定。

需求是分层级的,有些需求处于核心业务的需求,有些属于经营管理层面的需求,而前者永远是公司发展的核心,因此其重要性和优先级要高于后者。

对于上图来说,部门员工的相关kpi,个人绩效属于经营管理层面的数据要求,第一期工程可以先不考虑实现,先确保实现核心业务相关的数据看板的可用性和准确性。

战略看板设计主要突出简洁、唯结果论的特点,要主次分明,并且多的展现纯数字内容而非图表,下图举例:

一般设置6个左右的数据指标,有利于专注于分析最重要的指标。

需要支持自定义配置,可根据业务发展需要灵活调整看板需要呈现的数据。

之所以采用数字形式而不使用各式各样的图表,一是为了保证第一时间掌握业务现状,二是公司中高层对业务数据非常敏感,不需要曲线来表示规律,只用看到数字就能看出业务异常。

产品经理也应该培养数据敏感性,以便于能够理解业务,做出更符合业务需求的数据产品。

业务看板设计主要突出垂直细分的特点,研究业务增长就是业务增长的图表,研究活跃用户就是活跃用户的看板,或许这其中会有写关联性,但这种关联是弱关联,如果数据看板之间含混不清,那么分析业务也会有很多阻碍。

业务看板与战略看板最大的不同点是,注重生产过程,所以多使用增长曲线来体现数据规律和数据变化。研究增长曲线:

上图所示仅为单一维度,实际业务场景往往是一个关键业务指标关联着其他的数据指标,图表要支持维度下钻,点击能够查看二级指标的图表信息。

要能够支持x轴平移和缩放,y轴的刻度能够根据数据大小自适应。

业务看板解决的核心问题是:及时发现业务问题和便于分析业务异常,视觉设计上要注重各个指标的色彩鲜明,便于察觉指标与指标间的关系。

业务看板描绘的业务不同,数据不同,需要安排在不同的页面上,业务看板需要足够细分,绝对不能互相杂糅,纠缠不清。

选择合适的图表类型能够最大程度满足视觉可视化的呈现效果,满足业务数据查看和分析的需求。

以下选用几个典型的业务场景做说明:

(1)描述业务增长曲线,利润曲线、销量曲线、用户数量等,重点表示业务发展的趋势

所有数据都从相同的零轴开始,使用与展示总量与分量之间的关系,必须设置透明度以避免重叠

数据起点为上一个数据集,主要用于展示数据分量占数据总量的百分比,然后对分量所占百分比进行对比

折线图和面积图都可以用来展示连续数据随时间变化的趋势,但选用还是有其侧重点:

  • 常规面积图适合表现总量和分量之间的关系,比如总量是总用户量,而分量是各个渠道的用户,那么选用面积图较为合适
  • 堆叠面积图适合表现分量所占数据总量的比例
  • 折线图更适用于展现分量与分量之间的对比(不含总量),避免了面积图阻塞的问题
  • 通常情况下,需要展示数据总量的业务,使用面积图会更好些

(2)描述业务流程问题

描述业务流程最常用的图表是漏斗图,销售漏斗图、用户留存漏斗图,但漏斗图只能表示单一流程,如果想要表示具体的用户数据流向,和多维度更加复杂的流程数据,就很难表示了。

桑基图能够很好地表示用户从加入购物车到收获的全流程,主支宽度总和与分支宽度总和相等,不同宽度代表不同流量的大小。

漏斗图这里就不过多赘述了,比较简单。

气泡图最适合展示数据的分布范围,横坐标可设置为时间,纵坐标可设置为商品的价格,表明商品价格区间随时间变化的趋势,而不同的颜色表示不同的商品,这样对于价格频繁变动的商品,查看其每天的价格分布以及趋势很有帮助。

不常用以及过于简单的图表,这里就不再详细展开了,使用图表以好用、够用为原则,不必过于追求复杂图表,否则业务团队觉得麻烦,不愿意使用,那就背离了产品设计的初衷了。

另外,自行开发可视化图表耗时耗力,常见的解决方案是使用ECHARTS 、QCHART、AntV等开源可视化库,只需调用相应的api接口即可。

由于b端业务的特性,后台系统不对外开放,仅企业内部人员使用,因此着重强调的还是围绕业务问题进行业务数据建模,打通分析链路、维度下钻和报表设计等层面,看板的设计反而较为简单(b端对于视觉体验的要求不高),况且市面上已经有很多非常成熟的可视化解决方案可供调用,视觉体验的设计下限比较高,因此后台产品经理应该把主要精力集中在后端逻辑层面。

产品经理要尽可能的多参与前期业务设计的过程中去,旁听业务讨论也有助于理解业务部门痛点和难点在哪里。业务调研和访谈的形式不够深度,业务方在表达诉求时也可能会偏离他们的初衷,产品经理只有深入业务逻辑才能对业务方提出的需求多加辨别分析,形成有产品经理专业意见的设计方案。

如果你在数据产品经理道路上有困惑,可扫码加老师获取「1V1免费咨询」,帮你理清转行思路,匹配更高效的解决路径~

《数据产品知识框架高清思维导图》

《数据产品知识框架高清思维导图》内容概览

《用户增长资料包》内容概览

我要回帖

更多关于 什么是EE产品经理 的文章