我在加入贝壳之前，是在豆瓣负责整体的产品和运营体系，并且豆瓣也是我工作最长的一家公司。所以当初选择到贝壳时，大把人跑来问我，你为啥选了一个差异这么大的公司？其实我自己也觉得挺大的。不过我还是做了非常充足的心理准备，整个过程中遇到的挑战依旧不少，也有很多的收获。
回到问题本身，其实这个问题分成两个部分：一个是切换公司带来的挑战，另外一个是业务类型的差异感受。
1、公司差异
先说前者，贝壳和之前所在豆瓣无论是公司规模，还是发展时期都差异很大。豆瓣的公司规模相对小一些，且在平台期。而加入到由链家升级转型的贝壳，是一个十几万员工的，正在转型的巨型公司。
我恰巧在贝壳起步时加入，刚入职面临的挑战就非常大，团队刚刚组建，就几个人，可以说一穷二白。而公司此时在以 All in 的状态从链家升级成贝壳，做业务转型和组织变革，推进的速度非常快，我的团队需要在资源匮乏的状态下支持业务发展。
外界看到的你都是机遇，你看到的全都是挑战。招人搭团队，梳理产品结构，做计划定方向，同时要灵活应对发展初期的各种局部调整，每件事都不轻松，何况是一起涌过来。开着飞机换引擎，很长一段时间我和团队很多人日常都处于焦虑状态。
这个过程最主要的是找到自己的节奏，而不是被外力推动，所幸我认为现在的状态调整得还不错。业务的复杂度也是超出预期的，房产经纪是发展了几十年的行业，和所有传统行业一样，都积累沉淀了海量的行业知识和经验沉淀，学习曲线又长又陡峭。
但业务发展速度并不能容许你慢慢的一点点学习了解，需要快速熟悉业务了解细节。这非常考验人的学习主观能动性。我比较不要脸，不懂就直接问，多总结多梳理会让自己对业务全貌有比较快速的认知。我有段时间有个习惯是下班回家路上，在车上掏出电脑做做笔记，整理下当天的工作。
前期整个过程中还是有很多节点十分痛苦的，心理压力非常大，但是 no pain no gain。
2、业务差异
再说后者，业务类型的差异。倒不是说切换起来有多难，更多的是一些意识上惯性，和过去的经验积累会有差异。属于某个点想通了，思路就顺了。做内容社区，也就是非常经典的用户产品类型，按马斯洛需求金字塔，视角其实是从上往下的，大多数解决的用户精神层面的需求。
产业互联网是从底层开始的，且不说普通用户的需求相对来说刚得多，业务体系中的服务者也是你的用户，解决的更是人家吃饭的问题，马虎不得。
有个例子是部门内的一个 PM 跟我说有个 bug 会导致极少数经纪人（千分之一概率）无法使用某个功能，解决起来很复杂，暂时不解了。这在用户产品的判断体系里很合理，一个功能偶发不可用，解决成本又高，那就放一放。但是在这儿显然不行，这个 bug 意味着千分之一的人没法工作。同理心的话可以想象一下自己某天上着班电脑突然罢工了，自己是怎样个心情。
传统线上产品的设计逻辑大多是短路径，快速反馈，拿数据做修正迭代。背靠产业的完整产品体系背后接的是服务，服务履约流程长，涉及线上线下，路径设计会有种种的约束和限制，相应的逻辑细节也会更复杂。产品是贴着业务走的，考虑清楚了先解决问题，其次才是形态的优雅什么的。最怕的是不接地气，需求抽象后实现的结果和实际的业务细节差异太大。你觉得老子产品做得这么牛逼你还不用，用户觉得你做的这都是啥啊能别硬塞过来恶心我么？
另外，业务体系复杂的时候，在不同的环节，成熟度不一样，所以解决的问题类型也不一样。业务推动是需要逐步进阶的，比如大多数情况下，一个产品或者功能服务做出来，首先可能仅仅是把之前用 excel 解决的事儿先给搬到线上来，这个过程中的「创造感」可能没有那么强。但这已经很了不起了，至少得先从 offline 到 online，后面才有机会基于数据交叉，节点拆解等等，进一步的效率提升或者流程重构，进而才有真正的「高科技」赋能。
上面说的这些，只是「差异」的很小一部分。真正能做好的，又懂业务，产品基本素养又好的 PM 其实很难得，培养难度也更大一些。
我在当初决定做职业转型（至少我自己这么认为）时，做过一段心路回顾：「互联网作为通用工具，对于已有产业的改造和效率提升，还有挺长的路要走，衣食住行领域都有很大的空间。不同的业务模式带来的新奇感和相对更具象的接触和理解人的需求，都对我有很强的吸引力。虽然没有确定最终要去哪儿，但心潮澎湃。」
作者：孙哲，微信公众号：职人社（ID：Zhirens），职人社是围绕个人职业经历和能力的内容社区平台，提供聚焦于专业、职业和行业的交流讨论，提倡价值连接。
