屏幕前的各位可能已经看烂了产品经理的要求啊，工作内容啊之类的，但是可能在我的内容里面各位能看到不一样的地方。

当说到toB产品，可能大多数人想到的就是死板的画风，毫无新意的功能，但是其实正是这种风格才能做好toB的产品。

在我眼里，toB产品虽然在创新，流量等方面比不上toC端，但是其逻辑的复杂是toC端远远比不上的，这也是为什么toC转行toB不好转，但是toB转toC好转的原因。

在面向公司级别的系统时，纷繁复杂的业务要求功能与功能之间互不干扰又能彼此联系，而且不仅要在系统上操作顺畅，还要配合系统外的操作实现整个流程。比如在新装一块电表之前，得先在系统里派发任务，派人现场勘查完之后，上传系统审批方案，审批通过才可进行配表，当线下配表人员安装完之后将信息录入到系统中，之后才可以通知接电；在划分用户时，需要用计量点、台区这样的虚拟概念，而在线下服务用户时就是根据线上的虚拟概念进行服务的。而这只是一个小小的功能。

在正式接触toB产品前，其实可以花个1分钟看看toB产品需要的能力：

重要程度，满分五星

一、掌握软件☆☆

常用的大概就是：word、excel、PPT、visio、xmind、AxureRP、navicat、powerdesigner。前面的都很了解了，有人可能会问为什么需要用到Navicat和powerDesigner呢，这两个不是数据库的管理工具吗？这个问题在后面文章讲到写需求规格说明书的时候大家就明白了。

值得一提的是，掌握软件我觉得这项能力应该排在倒数几名，不能说不重要，只能说工具终究是工具，是辅助我们做事的东西，这就相当于Java编译用eclipse还是IntelliJ IDEA，甚至用记事本，说到底都是帮助我们完成编程的工具，真正要强化的是自身实力。

二、沟通能力☆☆☆☆

沟通能力还是蛮重要的，因为一个toB软件的诞生需要经过销售/市场前期->产品经理->开发->测试->实施->运维，而产品还要与客户对接，在需求跟踪时，还要与测试商讨测试用例，直到项目落地，产品经理心里的石头才能落地。由此可见产品经理是整个项目的一个桥梁，如果沟通能力不加以锻炼，很难在众多角色之间斡旋。

与不同角色的沟通需要不同技巧，我是一个产品新手，这方面我还得继续摸索，不过有几点心得可以分享：与开发沟通时一定一定逻辑要清楚，对技术要有一定的了解，不然很难让开发听从你的安排，逻辑不清楚导致的误解，背锅的还是你自己；与客户对接时，不要什么需求都答应，因为很难说他们就知道自己想要什么，到时候明明签了需求确认书，他们还得删功能，就会让开发不满，当然，我也不满。

三、逻辑分析能力☆☆☆☆☆

逻辑分析能力十分重要，对于产品经理来说，任何花里胡哨都是以此能力为基础的，没有什么快速的方法能提升自己的逻辑分析能力，只能培养，不过值得注意的倒是有两点，第一点是作报告以分层的方式考虑，第二点是从软件的生命周期出发。这个能力很玄学，我是工科出身可能思维逻辑分析的能力要好一些，总不能说去学编程锻炼逻辑分析能力吧。

四、演讲能力☆☆

与客户商谈时，需要在演讲时体现出我们的专业，就需要一定的演讲能力支撑；需求评审内审阶段，需要同开发、测试、销售、boss一块讲清楚项目，演讲能力就显得尤为重要，之所以低星是因为演讲是锦上添花的能力，没有好的演讲能力，如果能说清楚逻辑也是可以的

五、协调和解决问题能力☆☆☆☆

在一天阳光明媚下午，本可以舒舒服服坐在阳光下享受活都干完的时光，这时客户召开紧急线上会议，紧张刺激的会议结束，功能疯狂乱改，开发无情做不了，测试真实甩锅，这时的我是甘于默默忍受压迫，还是赴死反抗，不说了，学心理学去了

六、工作效率☆☆☆☆☆

这个没什么好说，掌握一切快捷键和模板思路，尽可能提升工作效率，空出的时间都将是自己的

七、政策文件挖掘解读能力☆

这个能力相当厉害，由于是辅助增强型能力分值才低，但是一旦用好真的很厉害，我也没有过多接触，所以不在此信口开河了，但是可以利用业余时间看一看政策，真的很重要，但不是主要。

八、文档编写能力☆☆☆☆☆

话不多说，直接上图

还有一些数据项说明文档，规范文档也要写。

当掌握这些能力之后，就可以入行了，很多人把设计原型放在首位，我觉得有点主次颠倒了，当经验丰富之后，未来的发展方向可以是业务层面的专家或者管理方面的专家，但是现在不妨试着思考，我应该具备什么能力？我怎样学习和提升这种能力？当把自己的路规划好之后，说不准或许自己想要的就是过程呢