产品经理需要具备的7个B端产品设计思维
副标题[/!--empirenews.page--]
C端重交互，B端重逻辑。看过很多关于C端产品设计的方法论，但对B端产品的设计宝典却少之又少。构思了一个月，增增减减，总结了几条关于B端的产品设计思维，抛砖引玉，欢迎各位朋友一起查漏补缺！ 小Q最近在思考一个问题， 工作5到8年以上的高级产品经理和1到3年的初中级产品经理，除了趟了更多的坑以外，在产品设计能力上到底有哪些优势？作为供应链这一类的典型B端产品经理，随着年龄的增长，咱们的沉淀到底体现在哪些方面？如何保持持久的竞争力而不被后生们埋汰？ 经过一段时间的观察思考，小Q发现产品技能本身并不是衡量高中级之间的标准，基本上干满3年以上的产品经理们，都具备足够的需求分析技巧和系统设计能力了（如果还不具备，那是不是要考虑一下自己是否适合这个行业了？）。 但随着阅历的增长，高级产品经理们会更加注重积累自己的产品设计思维和知识体系，而这些思维并不是一两个项目就能够快速催生出来的技能，而是需要在无数的经历中不断的提升自我认知，最终找到的一套自己独有的放之四海而皆准的设计法则。 01 业务思维做B端产品，首先要培养的就是业务感。在做产品设计时，你代表的不是产品经理，也不是技术，而是设想一下自己作为一个真正的需求提出方，你面临到问题是什么，希望系统提供怎样的支持？ 如果不能有很好的代入感，不能深刻的理解业务痛点，那么设计出的产品一定会有所遗漏，如同保姆和亲妈带孩子的区别一样，虽然保姆技巧足够，但情感投入相差千里，自然孩子的感受也就相去甚远了。 设计建议
02 极简思维刚出校门那会，总以为能够设计出一套比别人复杂的系统就是牛叉，本来一个很简单的功能，一定要锦上添无数的花，每天沉浸在自己制造的复杂的逻辑和交互里无法自拔；也曾经天真的认为那些看起来简单的功能是设计者的失职，直到无数次的锤炼和洗礼以后才慢慢明白，什么是真正的“大道至简”。 无论是系统功能，还是流程上，我们都要尽量追求极简，极简的流程可以极大的减少人工成本，极简的系统操作起来更加流畅更容易上手。 但是，极简并不意味着简单，而是要求我们能够分清楚主次，充分提炼，对于重要的功能和流程，一个都不能少，但对于可有可无的功能，能少则少，能系统自动处理的就不要人为操作，能操作一步就不要用两步来实现。 设计建议
03 积木思维好的产品设计和架构一样，也是符合SOA理念的，理想的B端设计模型是将已有庞大复杂的流程化繁为简，先碎片化为一个个可以独立使用的服务，将这些服务都存放进工具箱里，然后再根据业务场景提取相应的服务，像搭积木一样，重新组装为业务需要的模块，快速适应业务变化。如此可以极大的降低研发成本，这也是目前广为流传的中台化思想。 设计建议1）很多服务是在业务发展过程中慢慢被提炼出来的，当一个功能能够被多个业务共用时，就可以考虑将其抽象出来，作为一个独立的服务。 比如订单取消，由于客户、客服、库房都可以发起，所以就应该将各个系统的取消逻辑统一为一个取消服务，供各个系统调用。 2）服务的拆分和重组的颗粒度需要根据实际需要来制定，太粗了可复用性不高，太细了又容易增加开发成本。可以将常用的关联性强的功能一起封装打包为标准服务，若业务需要更粗或者更细粒度的服务，再定制化开发。 例如：常规场景下分配发货仓库和占用库存是一体化的服务，可以统一封装为一个分仓服务；若某些情况下只需要占用某仓的库存，则再封装一个库存预占服务，只提供占用库存的功能。 3）积木虽好，但终有其局限性，当一个工程的需求超过了当前所有积木能够组装的范围，强行组装往往会适得其反。同理，服务化和中台化也不是万能的，它们更适用于支持标准化业务场景，当业务的发展超过了当前服务所能覆盖的范畴了，就需要制造新的积木块了。 04 脉络思维B端产品设计工作中，80%的时间都是在梳理错综复杂的流程和业务逻辑，特别是遇到一个突如其来的大项目时，业务的同事往往不可能考虑的一应俱全，这就需要产品经理协助梳理。 如何将一团乱码的需求化解成一条条清晰明了的可落地执行的需求点呢？这就需要我们具备脉络思维。 脉络思维要求我们像庖丁解牛一样，先找到需求的主骨架，顺着骨架继续拆解四肢、内脏、筋骨，一步一步拆解到最小颗粒度，做到游刃有余。 设计建议1）先理清主干场景和次要场景。主干场景往往是业务方提出需求的初衷，最需要支持的功能，此类需求优先级一定最高;次要场景一般是搭配主干场景使用的，再没有主干之前，实现了也没有用，所以优先级较低。 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
