作为一位基层产品汪，当面对完全陌生的业务时，该从何下手？
各位 2B 的产品经理有没有遇到这样的场景：
老板有一天亲切务必的邀请你去他的办公室，面若桃花的说：“小王啊，我这里有个好机会想给你。“你心下一颤，料到不会是什么好事。果然他紧接着说：”最近市场部接了个大活儿，那个去年一直谈不下来的上门美甲连锁店，终于肯愿意入驻我们平台合作，只不过对方有个小要求“他看向你说：”想在现有产品的基础上，根据他们的服务特点，稍稍做一些修改“看你面色越来越差，他拍拍你的肩膀说：”部门会专门给你安排几位研发同事全力配合你的工作，希望你能尽快梳理好他们的需求，最好能在下个月上线！“
这一大串话听完了，你也大概明白了老板的需求：哦，原来要在不影响现有产品底层结构的情况下，采集 VIP客户需求，根据其服务特点改进现有产品的服务路径，使其在不影响用户体验的前提下更好达成客户商业目的。
老板的需求 & 客户的需求似乎都明白了，可该怎么做呢？是否觉得老虎吃天无从下口？其实只要把握以下几个核心要点，梳理好 2B 业务流程便不是问题。
对于小王这样一位基层产品汪，对公司产品规划没有实际的决策权，老板特意交代的工作肯定是公司重视的业务，他面临的问题就是怎么做？而且怎样才能做漂亮？以下几点建议可作参考：
一、 未见客户前，充分做好对方的背景调研
对方是美甲领域的知名品牌，年服务客户数上千万的高端美甲连锁店。如果有条件/有需求，可以亲自体验一下对方的服务，在服务中通过自己的亲身体验感受目前的服务流程是怎样的？哪里可以优化？把服务流程中存疑的点能当时询问服务人员的最好都一一发问，并且将对方的回答也都一一记录。除了可以在事后仔细分析其背后的真实需求外，也可以圈定一部分和对方对接需求时需要当面重点交流的问题。
比如：对方在服务前通常问用户一些关于手部护理的问题，甚至细化到了护手霜的品牌。小王就问服务人员为什么要询问这一系列的问题。她的回答是：”这是公司的要求。“显然这并不是我们想听的答案，如果可以把这个点在需求对接会议上充分讨论相信可以得出不一样的结论
如果因为时间、地点等等原因没法亲自体验服务，那么事先在网上搜集相关资料也是极好的。特别是如果对方已经和一些平台合作的情况下，在那些平台上看看客户的评价反馈。对于差评和好评都应特别关注。在自己的产品研发过程中更好的扬长避短。
前期自己收集好的问题一一整理到「会议议程」里，会议前以邮件形式正式通知对方时发出这些问题，让对方负责对接的人有个大概了解，如果里面有一些他也是摸不准的问题也能事先做好准备。
特别要注意的是：这些需求点一定是一条一条的干的问题点，不需要太多的描述，只要确保没有遗漏就好
你会发现事先摸一遍对方服务流程，对你今后的工作开展，需求对接省去了近 1/3 的时间。
二、约见客户中，务必达成输出双方共识的文档
产品经理应该要非常珍视每次和客户约见的机会，毕竟前期摸索的成果以及后期的研发的依据都是靠和客户充分沟通来一点点堆积起来的。由于很多时候和产品经理对接需求的并不是对方公司的高管，而是高管的助理等相关角色，因此对于很多问题他们当时也无法给出准确答复，这种时候，即时发出下次会议邀约变得非常重要。
业务上但凡涉及到资本/人力/物力的调整，都需要在会议上要求对方给出明确答复，切不可开发都开始做了，才发现其功能点上还有疑虑，这样很大可能会直接拖垮研发进度
几个好习惯：每次沟通后都输出带有流程图的「会议纪要」；每次需求沟通都务必深化上次会议的讨论内容。
先解释第一点：为什么要输出带有简明流程图的会议纪要。流程图最能表示产品经理对对方业务结构的思考理解，很多时候口头表述的和实际思考的结果是不同的。我们都知道信息在传递的过程中存在丢失。会议中确定业务流程难免会有业务点被遗漏，尽管在你来我往的对话中看不太出来，但反应在流程图上却是一目了然。
（涉及公司业务做了打码处理）
继续解释第二点，每次会议中，都应该在上次会议的基础上继续讨论。主要是为了避免无效讨论和帮助产品经理深化客户业务的细节把握。如果每次会议不是就上次会议达成共识讨论，而是一个新的方向，那产品设计永远无从下手。并且产品经理还应注意控制会议节奏，当客户要讨论一些在上次会议上已经明确得出结论或者已经被 PASS 的议点时，最好委婉的提醒对方：”这个我们不是已经达成共识了吗，并且上次讨论后就已经发送邮件给您了“
三、梳理完成后输出高质量的文档，重点标注本次产品设计的要点
在和客户数次需求沟通会议后，确保对于客户的需求挖掘和整理几乎已经没有疑点和死角后，就应该细细整理出一份和客户需要确认的最终需求对接文档出来。这份文档应该含有以下几个要点：
明确对方的业务目标和自己公司的商业目标
数次会议后达成的共识（本次产品设计中涉及/不涉及的功能点）
对方参与的用户角色（需要考虑相应的角色划分）
业务主流程（若比较复杂，还需要附上关键部分子流程）
本次产品预计设计的功能点及其包含的功能
需要对方协助的一部分工作（需要提供的辅助材料、相关的人力/物力/宣传）
其中需要重点关注的有：达成的共识中不涉及的功能点，若是客户意见强烈希望在产品上得以实现，则需要在和老板商量和给客户一个大概（模糊、糊弄过去）的时间；客户的用户角色则是参与产品使用的角色，一般要涉及到用户角色划分以及相关权限配置；本次产品设计的功能点：若有 DEMO、草图是最好，若没有则可以输出一份需求清单 List 类似的描述文件，让对方大概知道里面有什么功能，大概的层级是什么；需要对方协助的工作：这里需要和市场部的同事提前确认一下宣传和运营 Follow，其他的多是一些基础资料初始化的东西。
四、系统化思考，从全局审视产品，减小开发量小
业务梳理完毕后就要准备撰写产品文档了，此时不要着急下笔，最好先想好哪些地方是目前的系统支持的，哪些地方可能需要特殊处理。这就是考验产品经理实力的时候了。最好多画几版草图，并且和这方面的研发负责人进行一次深入沟通，多听听他的建议， 尽可能减小开发量。
五、及时更新需求文档
2B 业务沟通随时随地都面临着需求变动的风险，有时候一天好几个变化，这个时候往往产品已经研发了一半了才通知有一些小变动。此时，需要和客户再三确认后调整方案，将修改好的方案及时传到文档服务器上并邮件通知整个项目的参与人。
若文档是几个人联合起来共同完成，可以采用一些文档协作工具，彼此一边写文档一边标注对方可能存在的遗漏点。也是一件提高效率的事。
