和G打交道蛮久啦，分享下toC 和toG产品经理的区别吧，
一、产品需求的来源：
1、toC。大多数情况下，通过分析竞品，抄袭竞品，加上适量的用户调研，形成了需求池，用户故事，再根据“科学”的排序，指定出迭代计划；
2、toG。甲方爸爸说，要发明1个轮子；产品经理们，去找以后需要用到这个轮子的单位聊，单位的同事一般会规定好轮子的形状，正方形、圆形、椭圆形等；轮子的颜色和尺寸也会提前定义好。需求表，梳理出来后，找单位签字画押。
从产品需求角度，toC产品，需要产品经理自行BB很多东西；toG产品，甲方爸爸会规定好需求内容，甚至会告诉我们，千万不要自己去BB东西。如果遇到更加强势的G部门，那么，产品经理其实不是产品经理，准确地说，是1名需求分析师。
需求分析师的主要职责如下：
1、负责业务需求分析：主要包括业务功能设计、业务流程设计等；
2、召集和发起可行性评审，向业务部门和开发人员讲解需求；
toG的产品产品经理，特别是在前线的交付产品经理，干的活，和以上2点，如果重合度很高。这时候，就不能再自称“经理”，而是“分析师”。
二、在产品的交互层面
toC的产品，都非常注重交互体验，强调把用户当小白用户，dont make think等等交互设计理念；也非常注重产品的视觉设计；交互，1个toC产品的必备组成部分，是1个重要的组成部分；
toG产品，相对于toC产品，那么交互就只是1个加分项。交互的优先级和重要性，相对不高，有下面几个原因：
1、toG产品，以web端居多，而在web端，toG产品绝大部分是由“菜单——列表——详情”这3个部分组成，可以称之为ToG产品三重奏；G部门已经非常习惯甚至依赖了这种操作方式。
交互方式的相对固定，且G部门不太愿意改变这种交互方式。
2、toG产品，G部门一定会要求在上线前，进行系统操作培训，会有PPT材料，系统操作手册，甚至有系统操作视频，加上培训会上当面演示操作，G部门的业务人员，对操作系统已经有了认知。
简单地说，G端产品的用户，是专业用户；
而且，因为业务相对独立，他们经常使用这些功能，已经熟能生巧了。功能层次深、多几次操作，对他们的工作效率本身没有太多影响。
如果是toC产品，操作复杂，功能藏得太少，那就太不友好了。C端产品，还是需要做到越少点击越好，在web端，尽可能让用户在3步以内完成操作。
3、成本考量。
toC产品，是花了各种时间或者经济成本拉来的用户，需要想方设法地让C端用户喜欢，并且让用户用得爽。产品视觉设计太丑，会成为用户流失的原因；产品的操作链条太长，用户可能会没耐心，或者用户产生挫败感，或者让用户鄙视这个产品设计，这些都可能会让用户流失。
toC产品，拉个用户来不不容易啊。如果因为交互上流失了，那就可惜了。所以，需要在交互上下功夫。
toG产品，产品群体相对非常固定，就那某些部门的某些人员，基本不存在用户流失问题；而且，这些系统本身就是这些，是从上而下，要求他们必须使用的。比如，财务系统，那不管这个财务做得多么难用，点击可能几十次，系统经常假死，财务人员还是要用。
toG产品在业务流程优化下功夫，会在交互上下功夫带来的效果更加明显些。
下一篇，聊一下在产品运营层面的异同。
