提笔欲写此系列,缘起最近刚刚看完1本成功学书籍《跃迁》;与其说这是1本成功学书籍,不如说是职场养成系指点手册。
其中,个人很是赞同几个观点:
- 在这个信息碎片且爆炸的时期,如何才能不消磨自己的时光,分散自己的注意力?
- 作为职场新人,如何选择城市、行业、公司、职位?怎样的选择能大于努力,成为高手?
- 怎样才能从简单的工作循环中脱颖而出,升维到更高级的循环中?
- 怎样练就自己的知识谱系,成为行业专家,构建自己的影响力?
更多的内容,网上已有很多很优良的拆书文,在此不做赘述。
其中,知识IPO这个观点戳中了我——工作及学习中的经验心得必须得进行复盘、总结、交换,才能更好地复利。
那末作为1个产品人,最好的切入点,就是对产品本身的复盘。
所以本人以最大颗粒度的分法——to B及to C归类,将自己做过的产品心得梳理1下;其中,很多观点仅是个人鄙见,亦欢迎有识之士交换指正。
1、家校APP
产品用户:全国中小学教师、学生、家长
产品服务购买决策者:中小学校长、市区县教育局
产品功能:校友圈、发布通知、岗勤管理、学校网站嵌入得手机端展现或在线课堂
用户主要诉求点:学校管理的线上化,除教务本身没法用线上替换,其他功能能用APP完成的就用APP完成
产品成果:下载量1w+,累计10w+(后来离职了,数据是听同事转述)
产品原型:4大模块,每一个模块包括若干feed(信息)流
产品原型4大模块:
- 用户角色分为——教师、学生;没有家长。
- 围绕的场景主要是教师及学生的赋能——给教师发布知识点、样题、优良教学资料的功能;学生反复练习及线上答疑的功能;学生做错的习题集统计并发给教师端,教师进行1V1的辅导。
- 另外,才是学校的PR及通知之类的东西。
- 管理层的功能——人事、绩效、审批、班级及学生管理、教学业务统计。实际上,本类需求才算是to B的,应单独做此APP,不会与to C的教务类融会为1个APP,做成1个很复杂冗余的APP。
2015年夏天,我研究生毕业,并且同时从猎聘助理产品岗离职;彼时,正值国家扶持IT创新发展的高峰期,在2010后的宏观调控的刺激下,IT创新几近以1个季度1个风口的情势出现。
作为1个1年级的产品小学生,却在1个奇妙的际遇下接到了此大活儿——做全国中小学教务APP。
现在回想,当时入职落后行产品设计时的我,对产品的假想、产品的定位、产品的核心功能、现有家校产品的用户使用痛点,都没有深层次的认知。产品总监找我纯是为了干活画UE出PRD。
复盘1下,这个产品上线以后虽然下载量不小,但是反响1般。归因于:
- 我们的用户调研做得不到位。据悉,在我入职前仅和几位校长及学校领导做过1次会谈而已,这是1个大疏漏。在to B需求分析的宝典——《有效需求分析》1书中有写到:需求分析人员在启动前需要与产品策划的关键角色进行明确的访谈:了解他们的平常、了解他们的痛点,这是决定产品上线是不是能够成功的先决条件。
- 产品完全是为了逢迎boss口中的“做1个校园版微信”进行产品定位,产品team没有针对产品定位本身进行更多的讨论及策划。
- 对各个角色的使用处景,彼时稚嫩的我没有做场景梳理,没有画用户故事地图。而家校APP最大的痛点,就是如何让学生在使用APP时得到正向的效果。
由于此版APP上线后反响并没有到达预期的80分标准,产研团队间逐步撕裂,本怀着1腔热忱的我,看着研发们1个个对版本迭代的抵牾情绪,随即心态崩了离职。
K12教育行业不好做,是1个比较重度但又对在线化较为守旧的领域,此项目对初出茅庐的我几近是1个下马威,致使我后续面对K12在线教育都有些胆怯。
如果此时有条件,再让我重新操刀做此产品,我会先会去做用户调研:实地调研中小学老师们怎样岗勤管理、怎样做教务通知、怎样做线上学习任务分配、怎样布置课堂作业及课后作业、怎样管理所辖教师开兴趣班等等问题。
2、某房地产抵押贷公司的全系统
产品用户:房地产抵押贷公司的经纪人(销售)及后台人员(风控、审计)
产品服务购买决策者:无(公司内部的业务系统)
产品功能:
- 在线房屋估值APP(销售吸引定单使用的APP,只有1个功能——录入房子出评估价)
- 业务流程后台(报完单后,风控及审计人员的流程作业后台)
- 下户助手APP(下户专员使用,对房籽实地情况考量、收集信息的APP)
用户主要诉求点:吸引客户、及线上化办公协作
产品成果:推动了10余个区域(城市)使用本套系统
产品原型:在此公司,我几近没画过原型,所以后续也没有任何文档(用别的系统做1个类比,侵删)
2016年夏天,在做完微校APP的1个版本迭代后,我和公司提了离职。在家里边看韩剧边看字画画,其实不着急找工作,仅是把简历挂在网上而已。1周后,应邀进入了1个1线房地产金服(即房地产抵押贷)公司,做1名产品。
在我入职时,该公司的全部评房系统及后台作业系统已基本成型。所以,在委曲坚持了1个季度后,我便离开了,经过本公司的技术总内推到了母公司的技术总那里,自此开启了我的房地产互联网之旅(详见下述):
对本套产品的心得体会:
1. 在线估值的APP:在没有任何测试人员进行测试的情况下投放到市场,此风险非常之高。产品也没有写任何测试用例并跟进测试的习惯,故在投放市场后,多名KOL销售反馈卡顿、兼容性、报单后等待延时等各种问题,产品透支信任度。
2. 对业务后台系统:在未配置成熟的情况下,不要进行系统实行及试用教育。
虽然后台系统不过是增、删、改、查、显、算、传,但业务系统不同于平常利用,它的使用对用户来讲是有学习本钱的,它的使用结果对用户来讲是工作成果。故而,它的每次loading等待、报错、非正常跳转,对用户更是有很大的心理压力。
我在未做好系统的适配的情况下,就把系统开放给后台人员使用,给后台人员造成了系统操作不友好的首因效应,此为1大失误。
“首因效应”是由美国心理学家洛钦斯首先提出的,也叫首次效应、优先效应或第1印象效应,指交往双方构成的第1次印象对今后交往关系的影响,也就是“先入为主”带来的效果。虽然这些第1印象并不是总是正确的,但却是最鲜明、最牢固的,并且决定着以后双方交往的进程。
3. 下户助手APP:我对这个系统的感受是——未做好市面上的竞品调研,盲目为了做而做的1个APP。其实微信或钉钉本身便可替换其进行作业。
4. 对to B后台业务系统,这里有1个我至今未解的难点——怎样才能兼容多套SOP(标准作业流程)。
当时此公司在房地产金服市场已经是名列前茅,各个地方的作业管理亦是非标。当时我们部门另外一产品同事负责北京的后台系统的部署,北京的SOP大致为:评房、报单、征信、初审、产调、下户、复审、终审、完成。而我负责的上海区域的SOP大致为:评房、报单、初审、产调、复审、征信、下户、终审、完成。每次北京调剂后,上海刚刚配置好的内容旋即又乱了,得重新来1遍。
3、某大型房地产网站的OP后台
产品用户:房地产经纪公司的运营人员
产品服务购买决策者:无(公司内部的业务系统)
产品功能:房源管理、客源分配引擎、房源排序引擎、经纪人排序引擎、网站配置
用户主要诉求点:为经纪人吸引商机、并尽可能最简化操作本钱
产品成果:已上线几近该房产经纪公司覆盖的所有区域(50+)
产品原型:
在子公司(房产金服公司)委曲坚持了1个季度以后,2017年元旦,我加入到母公司——某房产经纪龙头企业。自此开启了我的产业互联网之旅:
由于出道即是在搜狐当网站运营实习生,后来展转到本来生活网、猎聘网。所以,不同于现在大多数的产品经理,我对做PC产品非常熟习。
也因此,此地产经纪公司给予我充分的信任及发挥空间——做全部网站的重构,触及到网站底层业务逻辑重构、网站展现重构。
这几近是我挑大梁的第1个产品,虽然后来也有1个partner入职,但是全部0⑴的时期,我都得做功能计划、产品逻辑梳理、UE及PRD准备,在极度的压力和不肯定性下前行。
不过人生没有白吃的苦,复盘1下,我对此产品的后悔的地方相对也较少。
本套网站前后台的心得体会:
1. 网站前台的UI排期太紧,UI的规范设计及评审的力度不够,参与UI评审的人员专业性不够(但此算作C端体验问题,在part2文章时进行分析)。
2. 网站OP后台——在未进行经纪人与房源关系的业务逻辑深层研究就上线,几近是拍脑袋做的经纪人排序引擎。房产网站,展现的经纪人排序孰高孰低、孰轻孰重与每位经纪人的利益息息相干。
该功能的每种角色人、应当分配的权重、应当展现的顺序,我们未进行特别科学量化的验证测试。所以,后续又修改了几个版本进行该问题的修复。
3. 对C端体验的创新性不够,当时我做了现如今的智能找房模块策划,但是由于工期及其他缘由未通过终究的评审,此是我对此网站最为遗憾的事情(但此算作C端体验问题,在part2文章时进行分析)。
4. OP后台单1页面逻辑太多,过于脆弱。如今我加入到另外一房产老牌流量网站,才看到成熟的OP系统——是非常扁平、可扩大、模块间解耦非常充分、易于保护的。而那时候,我设计的OP系统为了最大化下降操作难度,而把若干动作在1个页面进行展现及复杂校验。
e.g:有1个房源审核的页面,包括房源标题、描写、带看、图片的认领及审核,需要在1个页面内全部完成。后来做此功能的技术告知我,这是他写过的最复杂最难受的后台页面。
上述就是迄今为止负责或参与过的大型to B产品的复盘。后续也参与过1些其他to B系统的产品策划,如人事系统迭代、门店管理系统的策划等,不过产品层面的成果很少,不足以报告。
综上:如曹政在《谈谈to B业务的难点》1文中所言,to C业务的个体诉求简单直接;to B你要面对的不同个体诉求不1致、决策影响程度不1致,你需要充分理解不同个体的不同诉求并到达对你最优利的条件,非常考验智慧。
我个人也有类似的观点:to B系统注定是比较难的,to B系统承载着现实世界协作的数字化映照,其难易度可想而知。
对to B的产品经理的工作,包括但不限于以下部份:
1. 竞品调研更加得下本,乃至得下血本购买产品;
2. 用户调研更加考验产品经理的功力,别让参与调研的人觉得没得聊,要从具象问题开始。比如:句式可以是“你希望得到诸如XX产品XX操作吗”、“为何觉得XX好”、“XX哪些还不够好”等1步步开始问。
3. 管理者讨厌被管理。你给管理者做的功能,大几率情况下他们是不用的。比如:很多公司的业务报表系统,管理者其实不看,而是看助手给的精简版Excel。究其缘由:公司宣导问题、系统信任度问题、管理层时间有限及IT水平普遍低等等。而此时作为产品经理,你没法决定管理者行动,你只能适应。
4. 你的系统能力圈1定要定义好。比如:在房地产金服公司,我曾被总经理要求“系统给业务人员赋能KPI”,但是这明显是不符合常理的。系统只是工具,系统不是救世主,不可能实行后1个月内事迹翻倍。作为产品负责人,1定要不被外界意见所裹挟。
凡是过往,皆为序章。
复盘自己的to B之路也是1路的不容易,没有哪一个to B产品是容易的;或许等到牛逼的1天,我再返回to B大军中摸爬滚打。
作者:韩露