提笔欲写此系列，缘起最近刚刚看完一本成功学书籍《跃迁》；与其说这是一本成功学书籍，不如说是职场养成系指导手册。

其中，个人颇为赞同几个观点：

更多的内容，网上已有很多很优质的拆书文，在此不做赘述。

其中，知识IPO这个观点戳中了我——工作及学习中的经验心得必须得进行复盘、总结、交流，才能更好地复利。

那么作为一个产品人，最好的切入点，就是对产品本身的复盘。

所以本人以最大颗粒度的分法——to B及to C归类，将自己做过的产品心得梳理一下；其中，很多观点仅是个人鄙见，亦欢迎有识之士交流指正。

一、家校APP

产品用户：全国中小学教师、学生、家长

产品服务购买决策者：中小学校长、市区县教育局

产品功能：校友圈、发布通知、岗勤管理、学校网站嵌入到手机端展示或在线课堂

用户主要诉求点：学校管理的线上化，除了教务本身无法用线上替代，其他功能能用APP完成的就用APP完成

产品成果：下载量1w+，累计10w+（后来离职了，数据是听同事转述）

产品原型：4大模块，每个模块包含若干feed（信息）流

产品原型四大模块：

用户角色分为——教师、学生；没有家长。围绕的场景主要是教师及学生的赋能——给教师发布知识点、样题、优质教学资料的功能；学生反复练习及线上答疑的功能；学生做错的习题集统计并发给教师端，教师进行1V1的辅导。此外营销经验总结，才是学校的PR及通知之类的东西。管理层的功能——人事、绩效、审批、班级及学生管理、教学业务统计。实际上，本类需求才算是to B的，应单独做此APP，不会与to C的教务类融合为一个APP，做成一个很复杂冗余的APP。

2015年夏天，我研究生毕业，并且同时从猎聘助理产品岗离职；彼时，正值国家扶持IT创新发展的高峰期，在2010后的宏观调控的刺激下，IT创新几乎以一个季度一个风口的形式涌现。

作为一个一年级的产品小学生，却在一个奇妙的际遇下接到了此大活儿——做全国中小学教务APP。

现在回想，当时入职后进行产品设计时的我，对于产品的设想、产品的定位、产品的核心功能、现有家校产品的用户使用痛点，都没有深层次的认知。产品总监找我纯是为了干活画UE出PRD。

复盘一下，这个产品上线之后虽然下载量不小，但是反响一般。归因于：

因为此版APP上线后反响并没有达到预期的80分标准，产研团队间逐渐撕裂，本怀着一腔热情的我，看着研发们一个个对于版本迭代的抵触情绪，随即心态崩了离职。

K12教育行业不好做，是一个比较重度但又对在线化较为保守的领域，此项目对于初出茅庐的我几乎是一个下马威，导致我后续面对K12在线教育都有些胆怯。

如果此时有条件，再让我重新操刀做此产品，我会先会去做用户调研：实地调研中小学老师们怎样岗勤管理、怎样做教务通知、怎样做线上学习任务分配、怎样布置课堂作业及课后作业、怎样管理所辖教师开兴趣班等等问题。

二、某房地产抵押贷公司的全系统

产品用户：房地产抵押贷公司的经纪人（销售）及后台人员（风控、审计）

产品服务购买决策者：无（公司内部的业务系统）

产品功能：

用户主要诉求点：吸引客户、及线上化办公协作

产品成果：推进了10余个区域（城市）使用本套系统

产品原型：在此公司，我几乎没画过原型，所以后续也没有任何文档（用别的系统做一个类比，侵删）

2016年夏天，在做完微校APP的一个版本迭代后，我和公司提了离职。在家里边看韩剧边看书画画，并不着急找工作，仅是把简历挂在网上而已。一周后，应邀进入了一个一线房地产金服（即房地产抵押贷）公司，做一名产品。

在我入职时营销经验总结，该公司的整个评房系统及后台作业系统已经基本成型。所以，在勉强坚持了一个季度后，我便离开了，经由本公司的技术总内推到了母公司的技术总那里，自此开启了我的房地产互联网之旅（详见下述）：

对于本套产品的心得体会：

1. 在线估值的APP：在没有任何测试人员进行测试的情况下投放到市场，此风险非常之高。产品也没有写任何测试用例并跟进测试的习惯，故在投放市场后，多名KOL销售反馈卡顿、兼容性、报单后等待延时等各种问题，产品透支信任度。

2. 对于业务后台系统：在未配置成熟的情况下，不要进行系统实施及试用教育。

虽然后台系统无非是增、删、改、查、显、算、传，但业务系统不同于日常应用，它的使用对于用户来说是有学习成本的，它的使用结果对于用户来说是工作成果。故而，它的每一次loading等待、报错、非正常跳转，对于用户更是有很大的心理压力。

我在未做好系统的适配的情况下，就把系统开放给后台人员使用，给后台人员造成了系统操作不友好的首因效应，此为一大失误。

“首因效应”是由美国心理学家洛钦斯首先提出的，也叫首次效应、优先效应或第一印象效应，指交往双方形成的第一次印象对今后交往关系的影响，也就是“先入为主”带来的效果。虽然这些第一印象并非总是正确的，但却是最鲜明、最牢固的，并且决定着以后双方交往的进程。

3. 下户助手APP：我对这个系统的感受是——未做好市面上的竞品调研，盲目为了做而做的一个APP。其实微信或者钉钉本身即可替代其进行作业。

4. 对于to B后台业务系统，这里有一个我至今未解的难点——怎么才能兼容多套SOP（标准作业流程）。

当时此公司在房地产金服市场已是名列前茅，各个地方的作业管理亦是非标。当时我们部门另一产品同事负责北京的后台系统的部署，北京的SOP大致为：评房、报单、征信、初审、产调、下户、复审、终审、完成。而我负责的上海区域的SOP大致为：评房、报单、初审、产调、复审、征信、下户、终审、完成。每一次北京调整后，上海刚刚配置好的内容旋即又乱了，得重新来一遍。

三、某大型房地产网站的OP后台

产品用户：房地产经纪公司的运营人员

产品服务购买决策者：无（公司内部的业务系统）

产品功能：房源管理、客源分配引擎、房源排序引擎、经纪人排序引擎、网站配置

用户主要诉求点：为经纪人吸引商机、并尽量最简化操作成本

产品成果：已上线几乎该房产经纪公司覆盖的所有区域（50+）

产品原型：

在子公司（房产金服公司）勉强坚持了一个季度之后，2017年元旦，我加入到母公司——某房产经纪龙头企业。自此开启了我的产业互联网之旅：

因为出道即是在搜狐当网站运营实习生，后来辗转到本来生活网、猎聘网。所以，不同于现在大多数的产品经理，我对做PC产品非常熟悉。

也因此，此地产经纪公司给予我充分的信任及发挥空间——做整个网站的重构，涉及到网站底层业务逻辑重构、网站展示重构。

这几乎是我挑大梁的第一个产品，虽然后来也有一个partner入职，但是整个0-1的时期，我都得做功能规划、产品逻辑梳理、UE及PRD准备，在极度的压力和不确定性下前行。

不过人生没有白吃的苦，复盘一下，我对于此产品的后悔之处相对也较少。

本套网站前后台的心得体会：

1. 网站前台的UI排期太紧，UI的规范设计及评审的力度不够，参与UI评审的人员专业性不够（但此算作C端体验问题，在part2文章时进行分析）。

2. 网站OP后台——在未进行经纪人与房源关系的业务逻辑深层研究就上线，几乎是拍脑袋做的经纪人排序引擎。房产网站，展示的经纪人排序孰高孰低、孰轻孰重与每位经纪人的利益息息相关。

该功能的每一种角色人、应该分配的权重、应该展示的顺序，我们未进行特别科学量化的验证测试。所以，后续又修改了几个版本进行该问题的修复。

来源【写作训练营】自媒体，更多内容/合作请关注「辉声辉语」公众号，送10G营销资料！