编辑导语：作为产品经理，你是如何抽象功能设计的？B端场景与C端场景下的抽象产品功能设计，又有哪些不一样的思路？假如这类问题出现在面试场景中，你该如何拆解和应答？本篇文章里，作者就该问题进行了解答，一起来看看吧。
面试官发问：请你以一个项目为例，谈谈你是如何抽象功能设计的？这是面试中非常常见的场景，面试初中高级的产品岗大概率会遇到的问题。
以前看过一个很牛的自媒体的主理人说，我每天坚持输出一篇高质量内容，还要做社群运营，大家觉得我好像无所不知，相关的问题都能信手拈来。其实并没有什么高深的技巧，我只是提前把可能遇到的问题思考过了，剩下的都是开卷考试。面试也是如此，不打无准备之仗。
接下来文章从3个方面和大家聊一聊这个问题可以怎么答，并在文章末位附有实操案例。这是我个人的答题思路，欢迎拍砖交流（本文立足于B端产品的面试场景）。
大家要认识到一点，在面试现场提出的任何问题，都是有考察成分的。哪怕你们聊得很愉快，聊起了生活与家庭，氛围很融洽，实际上你说的话都会有意无意被面试官放到审视的位置。
所以提前对面试官的问题做好分类思考，在面试过程中保持思路清晰，是一种有效的策略。
比如此问题，我认为面试官主要考察几个方面：
B 端和 C 端在产品设计上，有一些差异点。C 端要求洞悉用户心智，了解用户画像，用户群体相对单一，决策人即为使用人。
而B端的需求提出人和最终使用者很可能不是同一个人，B 端产品在日常工作中更多的是整合各类岗位的诉求、抽象业务场景做标准化的设计，需求的复杂度高于 C 端的单一场景。因此面试官很看重 B 端产品的抽象设计能力。
但是抽象的东西不好表达，所以要从项目立足阐述抽象的思路和结果。个人认为B端的抽象设计能力与 C 端的创新想象力有异曲同工之妙。
对比项目实践，项目复盘带来的成长更是倍数级的。经常做复盘的人应该有这种感受，某个时刻，脑袋豁然开朗，很多业务场景和诉求都串联起来了，一下子都明白了问题的本质所在。
而没有复盘习惯的人，碰到这类问题会当场傻了，也许在心里嘀咕：我也就凭感觉、凭经验做的，没想很多啊。容易在回答时陷入细节，直接讲述当时接到了什么需求，然后做了什么功能，导致答题的思维高度不够。
而方法论的输出，说明你的项目沉淀到了足够的深度，而且把踩过的坑总结成为了一套逻辑自洽的心法，大概率在以后的工作中能帮助你避开很多不必要的麻烦。大家在工作中可以观察有逻辑做事的人和凭感觉拍脑袋做事的人，在出方案的效率与执行结果上，有非常大的差距。
某运营大神在人才选拔上有一个深刻的见解，他认为识别人才，可以从三个层次去区分。
第一层次的人才是“野生纯天然”，这一层强调企业和平台背书的作用，可能在相同的环境下去做同样的事情，谁都能拿到不错的结果；第二层次的人才是“见过好体系”，就是在业界得到了基本的学习和锻炼，有系统的方法论；第三层次的人才是“建过好体系”，能因地制宜地做好体系设计。
我们避免成为第一类，离开了平台你什么都不是；我们立志成为第三类；但是在面试中大多数的情况，需要有技巧地展现我们属于第二类人才。让面试官明白，系统的方法论能帮助企业避开不必要的坑。
一个有抽象思维、有复盘思考习惯、有能复用的方法论的人才，谁不爱呢？
这个出发点就好比面试开场就要求做自我介绍一样，初次见面的陌生人，总得找点共同话题交流吧。最好的共同话题就是项目本身了，项目容易造假，加水分，但是细节是很难注水的。一般针对项目连续问 4-5 个问题，有水分的人基本就进行不下去了。
所以在面试中，切记从实际出发，可以从思维高度上去包装，但不要无中生有。有人就问了，我的项目经验不足，不注水要怎么答啊。看下去，下文给你真诚作答的加分思路。
回到最开始的问题，请你以一个项目为例，谈谈你是如何抽象功能设计的？4步走解决这个问题。
在开始之前先介绍项目的背景是基本的礼貌，面试官不一定是本行业的从业人员，对你公司的业务模式也没有深刻的了解。先说明项目背景，有利于在共同认知基础上开展对话。
鉴于B端业务的跨部门，跨角色，一个需求的提出，往往有错综复杂的历史因素。所以抽象需求的要点是通过多方交谈，提取需求共性。经典的5why 原则是经证实的有效、简单、实操性强的“刨根问底”的方式。在答题的时候，可以详细说明自己推理的思路。
王戴明老师在他的《SaaS产品经理：从菜鸟到专家》一书中提出，学习的方式有：向自己学、向他人学、向书本学、向标杆学。
向自己学适用于项目的复盘与总结，遇到新的问题的时候，我们可以参考向他人和标杆学习。业内领头羊的实施方案，已经成功验证了商业逻辑是成立的，告诉我们此路已通。
特别是B端内研系统的产品，不应仅仅局限于解决眼前的问题，这样会让我们只能做到60分及格。而是应该放开视野，看看商业化产品的的解决方案是如何设计的，推敲背后的业务逻辑和市场机会，有利于设计灵活而强大的产品架构，了解当前设计方案的局限性与边界，从60分做到80分。
例如权限的设计，在行业内有很成熟的解决方案。无非是用户、角色、权限（数据权限，功能权限）的关系，根据项目的复杂度还会涉及用户组、角色组、组织架构关系。
了解Oracle、Salesforce等跨国软件的权限架构，可以让我们清晰认识到复杂业务的顶级设计方案，但是不意味着我们的项目就需要用到这么高级的权限架构。也许最简单的用户 + 权限在当前的项目阶段就已够用。
行业内的顶级解决方案可提供思考方向的参考，但方案的设计需要结合自身的项目状况，考虑实际落地的策略。B端产品在寻找竞品解决方案有一定的门槛，并不一定能找到可参考的案例，但是解决问题的底层逻辑都是相通的。
另外在设计原型、输出解决方案（流程图、文字描述等）的过程中，我们可以排查将来研发或者上线推广的障碍点，提前与研发团队的小伙伴们，业务相关方沟通、确认。和业务方确认原型是比较重要的一步，有条件的情况下可以进行demo演示操作，或者按照场景演示demo，确认方案能否解决他们遇到的问题。
这三步操作中，比较有难度的就是在提取需求共性上，初入门的小伙伴们往往会被业务部门五花八门的需求弄晕，业务要啥就做啥。如果有持续的思考和行业案例积累，输出适合自身业务的标准化解决方案就是手到擒来的事情了。
如果你觉得以上的作答毫无亮点，或者底气不足，可以从这2个方面补充一下。
其实无论是项目介绍还是功能的抽象设计，都可以用这样的思路来回答，典型的STAR原则（情形、任务、行动、结果）或者PDCA原则，这也是反映我们项目复盘能力的一种策略。
大概率上，面试官对你上文的作答感兴趣，也会继续追问当时抽象设计的功能，最终效果怎么样？如果再做一遍，你会怎么做？可以做得更好吗？
如果你深度参与业务并反思了业务的瓶颈，一定会规划了不少功能，希望帮助公司解决问题。也有可能有些功能做了，因为种种原因没有上线。
在遇到本文“抽象功能设计”的问题而又没有更好的案例时，可以选择这种答题思路。把你对业务的观察、调研推理思路、产品规划和落地策略一一剖析给面试官，展示你的产品思维、业务思维亮点。
面试官：请你以一个项目为例，谈谈你是如何抽象功能设计的？
作答：
我们公司主营服饰、珠宝私域电商业务，企业私域直播为主要的营销渠道。
大致的业务流程是：买手和运营部门负责日常商品与直播场次选品，销售通过微信为客户1V1提供服饰搭配、直播导购、代下单、售后等一条龙服务，这种服务形式和公司的客户群体为50岁以上的中老年女性有关。
企业内部的OMS系统支撑着业务的运作，其中商品管理模块链接了买手、销售这两个角色：买手推荐给销售的商品会出现在这个列表，销售日常会在列表中搜索商品，帮客户搭配导购或者直接代下单（业务背景介绍）。
在与业务对接的过程中，我发现销售总是要加一些查询条件，比如尺寸、颜色、价格，方便他们快速找到某款商品。而买手提出的需求是关于商品排序方面的，比如直播主推标记的商品要排在首页，新款商品也要排在首页。
接到需求的时候我准备按照销售的要求加查询条件，但直觉这一方案并不能解决实际的问题。于是我开始追问他们具体的业务场景：
1）问销售：
2）问买手：
最终根据多方信息的反馈和交叉对比，我提取出了1个核心观点：该模块承担着“根据既定目标快速检索商品”和“主动推荐合适商品，提升转化效率”的目标。如果把立即购买理解为 C 端的商城，这个模块要达成的目标就是：提升【人找货】以及【货找人】的效率（提取业务需求共性）。
于是我将需求规划为2个阶段：
第一阶段提升人找货的效率，具体实施措施包括扩大商品搜索的范围，不仅仅局限于销售提出的查询条件；以及商品按照买手的规则和常用的电商商城规则重新排序，让优质的商品排列在最前面，获得最大的曝光。
第二阶段，可以根据客户的画像智能推荐相关的商品，提升客单价和转化率。但是介于系统内的历史因素，要达到这一步有一些难度，需要提前在相关接口中埋点、搜集数据，再做下一步的迭代（参考行业标准化方案）。
第一阶段的规划落到原型上非常简单，但是所有业务部门看过后都赞口不绝，催促快速开发上线。至此我认为功能的抽象设计已经达成了阶段性的胜利，接下来就是观察上线结果是否符合预期了（原型、方案确认）。
本文由@RaRa 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。