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

　　一、为什么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：吃了解饿就是包子。不同定义的最终产物是：同样的包子，却有不同的指代物。这就是数据标准与口径的不一致的弊端，也正是数据中台需要解决的问题。
　　解决了上述问题，做好了数据治理后，数据中台还需要成为对外提供统一的数据服务接口的数据集成平台。在这个过程中，不断完善的数据体系，会不断的丰富各类场景所需的数据。这也是数据中台都在推行OneData（一个数据管理体系），OneID（打通的用户体系），OneService（一个服务平台）的原因。
　　（2）数据融通带来了新的问题：数据隐私
　　从技术层面来看，数据中台是数据仓库与数据服务中间件的组合，因为海量的数据，所以需要分布式计算平台和存储平台，而且技术是中性的，没有善恶。从数据应用来看，数据中台汇聚了企业内外部的各种数据，除了企业自身数据，还有大量的用户数据，根据这些内容去挖掘商机是企业商业化的有效途径，但隐私的门锁，握于谁手？数据中台的价值是从正规渠道获取数据，应用到阳光下，数据资产是黑是白，就在于此。但，不可否认的是：数据中台极具使用价值。在极具价值的数据中台里，产品经理会扮演什么的角色呢？或者说，数据中台到底需要什么样的产品经理？通过数据中台项目内容与最终输出物来看，数据中台需要的产品经理分为两类：数据产品经理与数据平台产品经理。
　　（3）缜密的逻辑思维能力
　　数据中台所含数据内容庞杂，数据来源之多，远胜单业务线的数据体系，如何完成这一庞大数据体系的设计，是个极大的考验。数据产品经理，作为数据建设的推动者，需要强大的战略思维和逻辑思维能力，不仅可以判断出当下业务当中的关键流程，更可以不受限于现有业务规模，理解业务接下来的发展方向，做好数据体系扩展性设计。数据产品经理的基本能力当然更不能丢，业务逻辑梳理、维度指标体系设计、数据建模、数据可视化设计等等。归纳一下数据产品经理的技能点：语言：SQL、R语言、Python等；可视化工具：Tableau、FineBI、Cogons等；硬实力：熟悉Hadoop集群，数据挖掘与数据分析；软实力：沟通、行业认知、深度思考。这里小编需要说一下：数据产品经理不是数据分析师。
　　三、创业公司需要什么样的产品经理？
　　（1）创业公司跟大公司的环境不同
　　相比于大公司产品经理的细而专，创业公司的产品经理多而杂。创业公司产品经理的职责划分的并没有那么清楚，一个产品经理身上往往要背好几个项目，更有很多公司只有一个或2个产品经理。同样的时间，你在大公司可能只做了一个产品，而在创业公司可能已经做了45个了。
　　虽然大小公司都有各自的优势和劣势，不过有些问题是大小公司都会出现的。例如变更和增加需求，或许是由于社会发展快，竞争太激烈，原来期望的那种需求确定后再无变动的状态是越来越难实现了。
　　（2）对产品经理的要求不同
　　环境不同，对产品经理的要求也不一样；第一产品经理的心态需要改变，不管你是从大公司去小公司，还是从小公司去大公司，产品经理首先要做的就是心态的改变。
　　（3）产品经理的工作内容也会有所变化
　　在大公司历练过的产品经理，在产品文档输出方面，如原型、流程图等有很强的能力，基本功很强。
　　这是因为公司平时对文档有评审制度，文档完成后也要备份、更新。而且很多时候还面临着跨部门合作，好的文档输出会降低沟通成本，产品经理在文档撰写上有一定的自我驱动力。
　　但是很多创业公司对于产品经理的文档输出并没有要求，不在乎形式，只要把意思表达出来就可以了，所以很多时候锻炼的都是口头沟通能力。很多产品经理即使在创业公司有过几年的经验了，但是做起产品来仍然丢三落四，画的原型也总是避免不了缺漏。
　　当然不是所有创业公司的产品经理都这样，这种情况的存在有两个前提：一是看产品经理是否有一个好的领导，因为这个并不完全是因公司决定的，如果有一个好的领导严格要求，产品经理的基本素质会提高很多；二是在很多创业公司产品经理压根就没有领导，组织架构上产品和技术合成研发组，产品经理跟技术直接沟通。这样的话，产品经理有什么疏漏，技术人员发现后彼此协商及时修改即可，时间长了也容易造成产品经理不会严格要求自己。不过对产品经理来说，创业公司的经验也是有益处的。除了本身所负责的项目外，在实际工作中可能会有很多其它细小的事打扰到产品经理的工作，需要产品经理参与，久而久之会增进产品经理对业务的了解。由于部门职责不是那么清晰，如果产品经理有心的话，自己也可以主动了解很多。