来滴滴差不多两周了，来的时候就很清楚自己将会做to B的产品。之前的实习经历、项目经历都是关于C端产品的，事实上前期调研并没有做太多，问卷做得也不多，而且可以说是相当的不专业，完全不满足信、效度的标准，更多的直接切入主题，目标就是探索对产品的需求量有多大，有没有必要去做。

上一段实习，整体来说还是非常愉快的，相处融洽，即使离开了，同事、领导之间的关系也保持得非常好，这是人际上最大的收获，在工作上算是比较全面地了解了产品经理的基本职责。这段经历更多地会注重怎样把这款产品交互做好，让用户在最短的路径完成最有价值的事情，当然会处理产品从设计到上线的全流程，只不过，产品评审主要是与内部成员探讨，与甲方沟通。对于下一份实习，期待更加专业的工作流程，更多的前期用户接触，即，使我做得产品更加有迹可循，工作内容更加专业化。

缘分吧，一个几乎可以说是没有B端经验的小白，竟然来做了B端的产品，而且好像还是目前滴滴非常关注的部门，毕竟因为客服事件也引起了较大的社会反响。

刚来的时候最先接触的是一份实习生快速入门的wiki实习指南，讲真，至今我都没有看懂其中的逻辑关系，希望这份文档的小哥哥看到后不要打我，哈哈哈。大概内容我都回忆不太起来，也就是相关系统的介绍wiki入口，没有深入接触还真是不理解。

接手到第一个需求，快车会员接入方舟系统，方舟是一个客服专门使用的后台，用户电话进来可以查到相关信息并给到解决。这些名字很奇怪，还有些什么倚天屠龙记，我在想这个命名者是不是一个武侠小说爱好者。

回归正题，第一次接到需求的时候，看到一个需求提报，有他们的解决方案，第一感觉，这个不就是一个完整的解决方案吗？还需要我干什么？吴老师将我拉入一个钉钉群聊，讲真，刚来，很怕说错话，不敢在群里面问任何问题，害怕说错话后果很严重，或者自己问的问题很白痴，人家根本不想搭理你，直接当作傻子被撵走。原来这个群里面都是需求的提供方，我最关键的事情是，在拿到需求时，先自行读懂整个需求之后，快速找到需求提供方的代表，搞清楚需求的具体情况，因为需求的提供方并没有非常专业的产品设计功底，毕竟他们的工作也很忙，他们提出的需求，或者说是解决方案都有可能是违的，甚至是想当然的。很快的找到了一个超nice的客服对接小姐姐，任何问题都能够快速给到我回答。前面跟吴老师一起开会时看到他做的东西大多都是直接在图上用红色符号标记，好像没有画原型。嗯～，这次毕竟是增加一个新的页面，准备上手原型，原型之前，吴老师还多次跟我交流过他对这个需求的想法，所以在加入自己的想法之前更多地是满足吴老师的想法，于是着手开始画原型。

大概花了一周的时间，是完成了这个产品方案，并且也通过了产品评审。第一个产品需求，时间确实花得比较长。但发现了许多问题，按问题点方式总结如下：

1. 忽略重大细节。方案形成过程中，多次忽略细节，比如，漏掉了非常重要的标签，这个动作很小，但是影响巨大，忽略了黑金会员的权益是无数次，信息量巨大的时候没有考虑到翻页，没有考虑到按时间检索等问题。虽然每一次沟通都有跟相关人员进行沟通，也有记录，但记录零散，没有自己梳理清楚哪些核心关键点，可能忽略的细节。记性不好，看过的东西也会忘记。下次应当形成自己的重点记录方式。

2.忽视全局观。产品的设计理论上是没有什么规范的，好像都是自由发挥，但并不是做一个新产品，而是在现有产品中嵌入新的功能，所以很多场景的设计在一定程度上需要遵循现有场景的规范。如，某块信息下，暂时没有相关信息，我们给出了“—”表示无数据信息，导致整篇都是大量的“—”，可能和其他没有消费的券产生重复。后来反观其他页面，发现可统一表示为“暂无数据”。诸如此类问题，其他地方也有遇到，因此，在设计的过程中需多观察其他页面的展示情况，拿捏不准可与设计（闫肃）沟通。

3.策略的合理性和功能关联位置。这是吴老师在评审中遇到的问题并自己总结发给我的。针对这个问题目前我可能暂时没有理解得很清晰，策略合理与否暂时没有一个非常好的评判标准，我目前只能从使用者的使用方便性以及全局是否协调的感觉层面来制定策略。功能关联位置这次可以体现在快车会员与专车会员板块，最初的需求提报是希望把快车会员直接当作一个tab，下面只呈现快车会员的相关信息。后来才发现任何类型的车辆用户都会有会员体系，因此若直接将快车会员作为一个tab，可能后期的tab数量惊人，影响客服快速筛选。因此就根据功能的相关性，将所有车型的会员相关信息整合到一个“会员信息”tab下面。因此，可能需求方只是从自身的方便上提出的需求，但是我们应当考虑其位置摆放的合理性以及功能的关联性制定合适的策略。

4.沟通障碍。吴老师提到，如果钉钉敲字沟通不了的信息，是否可以尝试换种方式，为了在沟通的过程中不浪费对方的时间，提高自身的处理效率。我会提前把自己要问的问题都记录一遍，顺便再过一遍，重点部分会批注一下。当然，结果是效率提升了很多。其次就是不知道问什么，吴老师提到，你不需要讲太多，让他讲你就能明白很多。说话需谨慎，我需要对自己说出的每句话负责。

5.评审讲解障碍。自己的需求应当是自己把握机会，突然想起就像在学校开周会一样，总是会抢前面的几个发言机会，因为那个时候老师的精神状态是最好的，提出的意见是最用心，最中肯的。所以我理解为什么我当时推脱不第一个讲的时候吴勰的反映。我很注重自己每一次的发言，就像演讲一样。幸好提前看过各位大佬的评审会，使我这次即使第一次讲，也没有看出来多紧张。第一次，可能是描述问题没有太清晰，吴老师反映前面的东西讲太多了。嗯，可能是1句话能表达清楚的我却用了2、3句。这个问题下次可提前心中预演一遍。其次，很多问题我不是很能从关键的点去回答，差不多都是吴老师替我解答的，感觉像是个老师带学生，这节奏太慢，下次争取自己回答80%以上的问题吧。

6.文案相当重要。前后几次已经出现反复修改文案的事情，总体目标都是降低客服理解成本，因为本产品的目标就是把客服当“傻瓜”，不需要思考就能立刻反应，客服方甚至可能因为一个小的改动拖延整个需求的上线时间，由此可见文案的重要性。文案的需求大多是来源于客服方，但吴老师也反复给我提出过许多文不对题的地方，这就是我考虑事情不全面的地方了，下一次就不仅仅是完成一件事情了，更多地应该将自己当做一个客服的角色去考虑每个字段是否可轻易理解，甚至可以将高保真图直接拿过去给客服现场检验。

to C和to B的区别

使用对象来讲：虽然还没走完技术评审，但大概知道B端产品是做什么的，我们的需求来源于内部人员，所以对象是比较明确的，能够迅速找到使用对象，还有一个专门整理这些需求的人，所以在前期需求这块很轻松，不比C端产品，用户量大，且喜好不一，还要细分场景，挖掘用户特点。所以个人觉得B端产品做起来似乎要稍微轻松一点。

工作特点来讲：

c端产品经理最大的要求就是要有用户嗅觉，能够准确提炼用户的需求，为产品的市场化方向和用户利益寻求到一个平衡点，即，要实现企业的商业目的也要满足用户的基本利益；还需要具备一定的运营基础，通过用户反馈不断优化产品；数据分析能力，能够根据数据结果反推产品功能；懂得一点运营、营销、品牌策略，并适当地将其展现在产品中；最后C端产品需要有较好的交互设计能力和用户体验感知，这些都是围绕公司的战略和产品方向展开的。

B端产品需要产品经理具备优秀的公司战略和需求梳理能力、推动能力，这个可能在滴滴这种大公司更为明显的感受到。需求梳理能力这块已经感受到了，需要理解需求的意思，确定需求的真实性，甚至还需要重新走一遍需求，稍有不慎就会遗漏某一个重要的点。推动能力可能在后期才能感受到，吴老师讲第一个方案才完成30%，还有后期的技术评审、排期上线，这应当就是说的后期推动问题了。但是在运营和数据分析这块就显得比较薄弱，因为C端产品可以快速根据数据埋点获得数据，并可根据数据迭代，做进一步优化方案，而B端产品就比较麻烦了，我们的数据可能是提出不到的，似乎更加注重产品生态，而绩效就难以感知了，可能短期内难以体会到成就感。

两者的共同点和区别还有很多，这次暂且谈这么多，目前从C到B最大的感触就是，不那么关心运营和数据反馈，更多地是满足需求方，给出的方案符合产品的整体风格即可，当然在沟通交流这一块有了很大的认识，很大程度决定了成果和效率。

第一个需求完成的速度比较慢，有一种工作不饱和的错觉，所以才会有大量的时间总结，吴老师问我的期望是什么，接下来可能会期望多来一些需求，通过不断的实践与试错，能尽快拥有自我决策权，如果能获得一些相关工作台的更多权限，全方位了解把脉、擎天柱、乐高等工具辅助平台，可能对每个小需求的解决会有更宏观的思考。