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