2011年应该是互联网井喷的一年，各大书店的畅销排行榜，从各领域的人物传记逐渐被互联网、用户体验等字眼代替。相信很多人都看过苏杰那本人人都是产品经理这本书，可能是这个”人人都是“让后来产品经理一度成为了互联网次代名词。这个职位以无门槛、无专业限制、热门行业、高薪等标签，并能因自己改了小小的element就能直接影响亿万用户的体验，这种所谓的成就感，让无数小白趋之若鹜。当然，我不否认，那时我也是。

不过应该庆幸的是，在14年我选择了最热门且最有争议的一个行业—“互联网+金融”；更庆幸的是，团队是在一个成熟公司框架下的内部创业，意味着你有很优质的资源背景，且你是一个要具备多种螺丝型号的“螺丝刀” ，而不是一个螺丝钉；最庆幸的是，我有一个十分信任我的boss。这三点是直到目前最能说服我自己不后悔放弃原有专业知识，甘心选择一切从零开始。

言归正传，目前负责的项目，是我接手的第一个产品，一个小型BI系统，目前已经迭代到第二版，用户群就是身边的产品、运营、渠道等相关的同事。最大的好处就是大家都在一个屋檐下，沟通成本比较低；但同样的，项目启动的时候我就已经做好了要随时被批斗的准备。老大们对数据的关注和敏感性都特别高，在产品上线的最初期就筹划建立了专门的数据团队，但这个团队都不是专业的数据分析出身，野路子注定了这不是一条平凡之路。作为最初数据团队唯二的成员，从最开始的各种零散的数据需求，到现在的基本的BI体系，这期间踩过的坑和当初预想的一样，多如牛毛；但同样的，获得的成长，也是。

tob的pm，除了需要必备的专业技能外，在实际中更多要关注是业务体系，高端一点讲是Business Sense；通俗一点呢，就是一句话—“你要比你的用户还要清楚他们真正想要的是什么” ，这句话是在设计产品的每一环节都要问自己的。这意味着你要深入到各个业务模块，了解他们最日常的工作，抽丝剥茧出最真实、最高频、对业务最有有指导性的需求。 我想这就是做tob产品的好处：你会发现很多业务表层之下的东西，知道每一个业务模块运转起来的核心要素，找到最能解释并驱动业务发展的衡量指标。如果真的可以做到上述，应该会比业务人员还要更了解业务的核心。但这就需要极大的快速学习能力、高效的沟通能力、换位思考能力、抽象逻辑能力、洞察力、敏感度、还有持久的耐心。 我想这应该不比toc的产品容易到哪里去。

还是说我自己吧，在项目最初期，了解了目前市场上对app数据监测的比较常用的网站，【友盟_专业的移动开发者服务平台、 TalkingData-AppAnalytics 、百度统计——最大的中文网站分析平台 、「我要啦」网站流量统计 、Google Analytics（分析）官方网站 等】 做了一份很详细的各平台的分析，熟悉了移动应用大概的数据关注方向，基于app的应用设计我结合了很多上述平台的指标内容，一是认为这些平台已经有很成熟化的指标体系，有很强的通用性，也是各app都在关注的；二是我们也接了一些平台的SDK，自己再做也可以核查第三方统计的数据统计的准确性。但在业务上，考虑到数据的保密性，很少有开源的系统平台可以直接参考。而且不同的商业模式下业务体系也不尽相同，没有一个放之四海而皆准的标准可以一概之，所以在业务层面上就需要依据自身定制化。 而且还要再明确一点，BI系统也不是CMS、CRM系统，它没有那么强的操作性，它更像是一个展示数据清洗、数据归类、数据提取再到数据可视化的一个结果，平台上提供更多的是已经加工处理过，可以驱动决策的各种可视化图表。那么问题来了，不可能把所有的数据展示在上面，到底要放哪些指标，要用怎么样的计算逻辑、要展示什么内容？

“要全面了解业务逻辑” 到“感知用户需求" 这都不是拿个小本本坐下来找业务人员聊聊天喝喝茶就能知道的。这个时候"多型号螺丝刀"的优势就体现出来了，因为人员有限，在着手设计平台的业务系统的同时，我也是个分析报告产出机。“运营活动的参与度分享率是多少？哪些因素导致的？ 渠道上哪些数据是有水分的，从哪些角度发现的？交易为什么会在某个时间段集中爆发，背后的用户心理动机是什么？..... ” 每天都会收到很多涉及多个端口的需求。然后要从海量的数据中整合、归纳、找出原因，反馈到相关的同事，帮助他们优化或解决项目上遇到的困难。慢慢的我也就知道各业务方最常问的问题有哪些，哪些指标对他们是最有价值的，到后来就基本明确了产品方、运营方、渠道方都是怎么流转的、怎么看数据的。这对我后来设计内容上给予了很大的帮助。

内容有了，但不能胡乱往系统里面塞，信息架构_百度百科【information architecture】在这个时候就是一门极具魔力的学问，我特别佩服那些可以从乱麻一样的事情中，找到可以摸索的逻辑脉络，最后把事物深层次的逻辑串联起来，让人一目了然的人。相对toc的产品，tob的产品更要挖掘理解深层的本质，这是业务逻辑上最最重要的一项技能。这一点我也在不断的学习中。在设计过程中，我自己认为这个东西做出来是回答这样三个状态的问题 “以前发生了什么和为什么会发生？ 现在正在发生什么和为什么会发生、未来可能发生什么和我们如何应对？” 秉承着这一逻辑我做了几个版本的组织架构已供选择。

这个项目1.0版已经很早就实现了，但随着产品从初创期到成长期，目标和模式也在不断优化和调整，业务方关注的也在不断变化，最初版本很多地方已经不能满足现有需求，作为数据支持方也要“与时俱进，开拓创新”。现在2.0版也具雏形，3月底准备正式上线。 因为是对内产品且要最大化利用资源，项目只有一个pm+一个半开发，实在不忍心让自己的产品长得太丑... 在做原型的时候我顺便也做了产品的UI/UE， “螺丝刀”在不断解锁新技能。

总结下来，其实不用太过担心做tob的产品会丢失一些pm的专业敏感性，每一件事都会有AB面，每一件事情也是不断的在发生变化，可能因为刚开始工作或者在体系很庞大的组织里，我们没有太多可以选择工作内容的机会，“别人安排你做什么你决定不了，但你还能够做什么，你决定得了。” 我相信题主的产品也是需要不断推新，需要不断适应业务的发展轨迹，很多时候当业务发生改变的时候，可以业务人员一起参与讨论，去不断发现新的需求，探寻新的形势，即便是甲乙方的关系，在不违反相关规则下，也可以给予相关的意见和建议。我想有的时候我们的方向“转换”是从tob换到toc，其实还有一种“转换” 是跟着一个项目在不同业务发展阶段，不断发现和定位新的问题，去见证、适应他的革新，这样真实的了解一个产品的从零开始的生命轨迹，对以后做其他类型的产品的也是有很大的参考价值。