快生活 - 生活常识大全

分析关于产品经理需要具备的端设计思维分析创业公司


  一、为什么B端的需求这么难做?
  (1)产品架构复杂,功能庞大
  往往B端系统数据结构比较复杂,而事故严重度又比较高,对产品经理考虑的严谨性要求比较高
  (2)用户思维和客户思维的转化更难
  往往产品经理刚入门的时候,会去在意用户的体验性,考虑交互、样式和用户心理;但是到了B端,价值 》流程 》体验,如果过分考虑体验,那么就本末倒置了。B端的业务,产品经理很难站在用户的立场思考问题,因为你很可能不是这个场景下的使用者。
  (3)难以深入理解业务和市场
  如果B端的产品经理不能深入理解业务和市场,在你聊需求的时候,你可能跟客户都是牛头不对马嘴。B端产品经理对自己的要求,永远是要比客户更加懂业务!
  (4)客户角色多,需求描述不清
  客户角色多元,需求提出方可能并不是系统的使用者。管理者提出的需求可能会干扰需求的优先级决策;很多B端产品经理无法区分关键角色,从而对需求的本质判断不正确。
  二、产品经理初期关键词
  (1)行业分析:要想做好行业分析,需要知道WWH(who、what、how)方法论:Who需要你知道分析的渠道来源是哪些,What需要你知道分析的内容是哪些,How需要你知道分析如何评估。
  渠道来源(who):百度指数、微信指数、艾瑞指数、易观数据、行业论坛。
  分析内容(what):行业背景、行业发展、行业领军、行业需求、行业产品、解决方案。
  分析评估(how):专业易读、数据可靠、理解透彻。
  (2)市场分析:要想做好市场分析,需要知道市场分析的目的是为了什么?本质来说就是为了赚钱,无论是分析行业背景、市场现状还是商业模式等方面都是为了赚钱。
  作为产品经理主要是做什么呢?不需要进行细致的分析,细致的分析有市场人员去做,我们只需要有一个大致的把控:市场现有阶段、市场现有规模、市场未来前景、当前竞争态势。
  市场分析四步走方法论:行业背景、前后市场、用户分析、商业模式。
  行业背景:PEST分析、行业技术、行业预测。
  前后市场:市场规模、当前市场、未来市场。
  用户分析:用户需求。
  (3)竞品分析
  牢记目标:分析不是目的,优化、创新才是目的。
  竞品分析方法论:WWH(Why、What、How)分析法。
  Why:确定竞品分析的目的;确定目标,才会明确竞品分析的方向。
  What:确定竞品;明确哪些可以作为竞品,直接竞品OR间接竞品。
  How:如何分析;善用SWOT分析,善建KANO模型,明确用户需求与KANO模型之间的关系。
  (4)用户分析
  真正懂用户的产品经理才能创造出改变世界的产品。
  对用户调研分析之前必须明确分析完成对后续工作的指导性在哪里,否则调研没有任何意义!
  用户分析方法论:
  调研目的:明确用户分析的目的,为下一步工作做好准备。
  用户画像:根据用户画像,明确目标用户;步骤:收集-分析-验证-优化。
  用户问题:对用户和问题的分析,用户体验分析,DAU和转化率。
  得出结论:根据调研的报告输出用户分析的报告。
  三、产品经理应具备的B端产品设计思维
  (1)业务思维:
  做B端产品,首先要培养的就是业务感。在做产品设计时,你代表的不是产品经理,也不是技术,而是设想一下自己作为一个真正的需求提出方,你面临到问题是什么,希望系统提供怎样的支持?
  如果不能有很好的代入感,不能深刻的理解业务痛点,那么设计出的产品一定会有所遗漏,如同保姆和亲妈带孩子的区别一样,虽然保姆技巧足够,但情感投入相差千里,自然孩子的感受也就相去甚远了。
  设计建议:
  服务心态:要明白所有的系统都是为业务做支撑的,解决不了业务问题的系统设计的再华丽也只是浮云一片;
  同理心:跳出系统和自己的岗位,站在需求提出方的视觉来充分体会业务痛点,并以此思考解决方案。这样你就能很清楚的知道自己的设计是否实用,是否有遗漏和改进空间。如果你能做到在业务和产品经理双重角色中切换自如,那你就具备极强的业务感了;
  流程和系统的结合:设计系统功能之前,将业务流程从头到尾梳理清楚,充分考虑线上和线下操作的联动,再在流程中需要系统支持的环节中加入系统功能,让线下流程和线上功能完美贴合。流程和系统是相互成就的,系统是为了更好的辅助流程,千万不要本末倒置,让流程来迁就系统。
  (2)极简思维:
  无论是系统功能,还是流程上,我们都要尽量追求极简,极简的流程可以极大的减少人工成本,极简的系统操作起来更加流畅更容易上手。
  但是,极简并不意味着简单,而是要求我们能够分清楚主次,充分提炼,对于重要的功能和流程,一个都不能少,但对于可有可无的功能,能少则少,能系统自动处理的就不要人为操作,能操作一步就不要用两步来实现。
  (3)积木思维:
  好的产品设计和架构一样,也是符合SOA理念的,理想的B端设计模型是将已有庞大复杂的流程化繁为简,先碎片化为一个个可以独立使用的服务,将这些服务都存放进工具箱里,然后再根据业务场景提取相应的服务,像搭积木一样,重新组装为业务需要的模块,快速适应业务变化。如此可以极大的降低研发成本,这也是目前广为流传的中台化思想。
  (4)全局思维:
  全局思维是一种大局观,要求我们站在一个更高更广的视角俯视全局,做到心中有数,不要在单个细节的得失处理中迷失自我了。
  设计建议:
  明确方向,目标为王:做为某个产品的总设计师,产品经理往往充当着船长的角色,在航行过程中,经常会遇到风雨坎坷和烟雨迷雾,这就要求船长能时刻保持清晰的目标感和方向感,分主次、懂取舍,带领船队突破阻碍,到达目的地。
  大局意识,合纵连横:设计一个点,要考虑到一个面,由面再及点。在设计单个功能时,要考虑到上下游系统的联通,以及本系统横向模块的影响,不能只考虑到此功能本身。
  例如库房新设计了一套借出流程,满足了临时将商品借出库房的需求,但若只考虑到WMS本身改造,就狭隘了,因为涉及库存的变动,一定要考虑到ERP和营销侧系统的联动。
  以终为始,反向演绎:项目中经常会遇到倒排期的情况,这就需要我们具备反向演绎能力,根据项目的目标,结合资源、时间等因素综合评估,反向推演出各个里程碑和阶段性目标,并以此做取舍,保证大目标的实现。
  审时预判,提前规划:产品经理要懂得审势,根据自己的经验和公司战略,提前做出一些预判和规划,以防事情到跟头了措手不及。例如年初公司确定OKR,提到今年要从线上业务向线下发展,作为供应链产品经理,就要提前考虑到采购、库存、仓储这些系统是否能支持到线下业务的开展,设计系统时提前做好规划。
  适时归零,空杯心态:新环境新业务面前,为了更好的掌握全局,我们要学会适时的归零,多吸收,懂变通。如果没有这种心态,我们可能会变得不思进取,顽固不化,而我们最傲娇的旧经验终会变成自己前进路上最大的绊脚石。
  (5)回路思维
  无论我们设计的现场动线,还是流程,还是系统功能,都要有很清晰的路径,路径包括正向和回路,除了能正向操作达到目标以外,还需要能回转到上一阶段。有来无回的,就是死路。
  浅析:创业公司与数据中台需要什么样的产品经理?
  市场下沉,垂直细分,这些不知何时流行起来的词汇,代表了近些年商业发展的趋势。对于产品经理这个岗位,亦是如此。电商产品经理、社交产品经理、金融产品经理、数据产品经理等等,这个岗位也在不断地走向细分。今天,小编,带领大家换个视角,从公司发展的轨迹来看一下,不同的时期,产品经理应该以怎样的姿态存在。创业公司和数据中台需要什么样的产品经理?
  一、公司发展与产品经理细分
  世间万物都遵循着规律二字,公司的发展也同样遵循着产品生命周期理论。在公司的"减法"阶段,例如夭折期和衰退期,公司对于产品经理自然也是没有新需求的,这两个阶段,等待着产品慢慢凋零即可。那在公司逐步进行"加法"的发展过程中,产品经理这个岗位会发生怎样的变化呢?
  (1)产品使命:"生死",此阶段产品正待呱呱坠地。产品经理要对产品全面负责,不仅仅是产品的前端后台,可能用户调研、需求分析、团队管理等等,这些都需要产品经理亲力亲为。在这个阶段,抛开薪资层面不谈,最起码在工作层面,你能够深刻体会到什么叫做"传说中产品经理是最接近CEO的男人"。总之在这个阶段,你就是老板口中的"那个男人",任何与产品相关的事情,老板都会找你。这一阶段的重点,是要打造出第一版产品,并快速获得市场反馈。成功的话,则逐步迭代,抢占市场;就算是失败,也要让它快速失败,及时止损。
  (2)产品使命:"增长"此阶段产品开始牙牙学语。产品已经有了初级形态,开始与用户逐步建立联系。但在不断获取用户的过程中,会发现产品对于运营的支持太差了,于是这时候运营产品经理就出现了,专门负责给运营打助攻,比如活动的h5,微信公众号后台等。这一阶段的重点,是快速积累用户,并将产品推向市场。
  (3)产品使命:"优化",此阶段产品进入豆蔻年华。用户开始高速增长,产品各方面的性能均已不能满足需求,前端与后台的用户体验都需要进行优化。这个时期,对于产品细节的把控,就逐渐重要了起来。细节的优化,需要更加精细化的专业化分工,前端与后台需要不同的产品经理独立负责。这一阶段的重点,就是不断地对产品进行优化迭代,逐步提升用户体验。
  (4)产品使命:"变现",此阶段产品步入而立之年。俞敏洪说过:"不以挣钱为目的的创业,都是耍流氓"。对于产品,亦是如此。当产品完成用户积累之后,就开始进入着力变现的阶段了。此时,后台产品经理的侧重点,将会转向CRM、广告、销售、工单等系统的建设。这些系统的建设,必然离不开商业产品经理的支撑。而商业产品经理最重要的工作,就是为产品量身打造商业模式。这一阶段,产品注重于商业模式的构建与不断完善,在为别人创造价值的同时,也要不断地提升自己的价值。
  (5)产品使命:"方向",此阶段产品应该乐知天命。
  当产品发展到一定阶段之后,不改变就会被淘汰。此时策略产品经理出现了,运筹于帷幄之中,决胜于千里之外,有风控、算法、推荐等类型,通过研究策略,让产品更加智能化,让商业更加智能化。这一阶段,必然要不断地调整产品的战略规划,而智能化则是必然的发展方向。
  二、数据中台需要什么样产品经理?
  (1)什么是数据中台?
  首先,数据中台是为了汇总与融合企业内的全部数据(甚至企业外的数据),打破数据隔阂,解决数据标准与口径不一致的问题。举个例子,多个系统中都有"包子"这个字段,但定义不同:A:有皮有馅就是包子;B:有荤有素就是包子;C:吃了解饿就是包子。不同定义的最终产物是:同样的"包子",却有不同的指代物。这就是数据标准与口径的不一致的弊端,也正是数据中台需要解决的问题。
  解决了上述问题,做好了数据治理后,数据中台还需要成为对外提供统一的数据服务接口的数据集成平台。在这个过程中,不断完善的数据体系,会不断的丰富各类场景所需的数据。这也是数据中台都在推行 One Data(一个数据管理体系),One ID(打通的用户体系),One Service(一个服务平台)的原因。
  (2)数据融通带来了新的问题:数据隐私
  从技术层面来看,数据中台是"数据仓库与数据服务中间件"的组合,因为海量的数据,所以需要分布式计算平台和存储平台,而且技术是中性的,没有善恶。从数据应用来看,数据中台汇聚了企业内外部的各种数据,除了企业自身数据,还有大量的用户数据,根据这些内容去挖掘商机是企业商业化的有效途径,但"隐私"的门锁,握于谁手?数据中台的价值是从正规渠道获取数据,应用到阳光下,数据资产是黑是白,就在于此。但,不可否认的是:数据中台极具使用价值。在极具价值的数据中台里,产品经理会扮演什么的角色呢?或者说,数据中台到底需要什么样的产品经理?通过数据中台项目内容与最终输出物来看,数据中台需要的产品经理分为两类:数据产品经理与数据平台产品经理。
  (3)缜密的逻辑思维能力
  数据中台所含数据内容庞杂,数据来源之多,远胜单业务线的数据体系,如何完成这一庞大数据体系的设计,是个极大的考验。数据产品经理,作为数据建设的推动者,需要强大的战略思维和逻辑思维能力,不仅可以判断出当下业务当中的关键流程,更可以不受限于现有业务规模,理解业务接下来的发展方向,做好数据体系扩展性设计。数据产品经理的基本能力当然更不能丢,业务逻辑梳理、维度指标体系设计、数据建模、数据可视化设计等等。归纳一下数据产品经理的技能点:语言:SQL、R语言、Python等;可视化工具:Tableau、FineBI、Cogons等;硬实力:熟悉Hadoop集群,数据挖掘与数据分析;软实力:沟通、行业认知、深度思考。这里小编需要说一下:数据产品经理不是数据分析师。
  三、创业公司需要什么样的产品经理?
  (1)创业公司跟大公司的环境不同
  相比于大公司产品经理的细而专,创业公司的产品经理多而杂。创业公司产品经理的职责划分的并没有那么清楚,一个产品经理身上往往要背好几个项目,更有很多公司只有一个或2个产品经理。同样的时间,你在大公司可能只做了一个产品,而在创业公司可能已经做了4-5个了。
  虽然大小公司都有各自的优势和劣势,不过有些问题是大小公司都会出现的。例如变更和增加需求,或许是由于社会发展快,竞争太激烈,原来期望的那种需求确定后再无变动的状态是越来越难实现了。
  (2)对产品经理的要求不同
  环境不同,对产品经理的要求也不一样;第一产品经理的心态需要改变,不管你是从大公司去小公司,还是从小公司去大公司,产品经理首先要做的就是心态的改变。
  (3)产品经理的工作内容也会有所变化
  在大公司历练过的产品经理,在产品文档输出方面,如原型、流程图等有很强的能力,基本功很强。
  这是因为公司平时对文档有评审制度,文档完成后也要备份、更新。而且很多时候还面临着跨部门合作,好的文档输出会降低沟通成本,产品经理在文档撰写上有一定的自我驱动力。
  但是很多创业公司对于产品经理的文档输出并没有要求,不在乎形式,只要把意思表达出来就可以了,所以很多时候锻炼的都是口头沟通能力。很多产品经理即使在创业公司有过几年的经验了,但是做起产品来仍然丢三落四,画的原型也总是避免不了缺漏。
  当然不是所有创业公司的产品经理都这样,这种情况的存在有两个前提:一是看产品经理是否有一个好的领导,因为这个并不完全是因公司决定的,如果有一个好的领导严格要求,产品经理的基本素质会提高很多;二是在很多创业公司产品经理压根就没有领导,组织架构上产品和技术合成研发组,产品经理跟技术直接沟通。这样的话,产品经理有什么疏漏,技术人员发现后彼此协商及时修改即可,时间长了也容易造成产品经理不会严格要求自己。不过对产品经理来说,创业公司的经验也是有益处的。除了本身所负责的项目外,在实际工作中可能会有很多其它细小的事打扰到产品经理的工作,需要产品经理参与,久而久之会增进产品经理对业务的了解。由于部门职责不是那么清晰,如果产品经理有心的话,自己也可以主动了解很多。
网站目录投稿:凡雁