背景
2018年11月，大概是我一个非常重要的转折节点，在原单位当了8年多的项目经理，因公司业务调整，成立了子公司，我被抽调进入了产品岗，成为了一名产品总监，这并不是什么手握大权的大官儿，你大概可以理解成小组长，甚至目前可以管理的人员数量和项目经理相比，都微不足道。子公司从事的是线下电商数字化的业务，主要的商业服务对象也是我们集团的主营业务实体，它本身并不是从零起步的，已经经历过大概四代核心领导层的换帅，最终由我过去的老板，也是我现在的老板来接手。所以当它出现在我面前的时候，已经是一个200个人规模的大公司了。
感谢我直接上级（后称“我的领导”）的赏识，我才有机会在职业生涯中，跳过产品经理的岗位，直接变成一名产品总监，这种独特的职业履历，也正是我今天来写下这篇随笔的原动力。
我的履历
虽然我没有实际当过一天的产品经理，也没有以产品的身份实实在在地实操过互联网业务，但是通过观察和学习，我发现互联网从业人员应有的能力和我这种半路出家的人，思维模式上并无二致。我先做一个自我评价吧，主观地讲（可能存有自我偏见），我是一个：
- 标新立异的人，习惯于回到问题的原点进行思考
- 勤奋愿意解决问题的人
- 执行力很强的人
- 共情能力还不错的人
- 有点完美主义倾向的人
除此之外，我的专业是计算机，也从事了十几年软件研发工作，期间是啥缺干啥，从写代码、PS、文档、PPT、摄影等都得会一点。大概也是我的这种习惯的行为模式，导致我总是能在解决眼前的问题的时候，以简单直接的方式直截了当。
举个例子：前年公司搞年会，要想做个人脸识别的签到，我的同事会人脸识别，他主要负责搞定核心科技，而我就得去弄个摄像头啥的。既然是年会吧，你干巴巴地放一个摄像头肯定是low爆了，所以当时我大概花了10块钱就把这事儿办的妥妥的：
- 找到一张小黄人的图片，在它的两手之间PS了一个横幅，然后把它交给打印店
- 将打印好的小黄人剪下来，然后将小黄人的眼珠子拿刻刀划掉
- 然后把摄像头放在小黄人背后，整个摄像头就隐藏起来了
这大概就是我。
我的内心
上面这样的例子，虽然一点都不难，但是要做出来，我认为至少有几个要素：
- 愿意去把事情做得尽可能更好
- 对这个集体和目标有更多的热爱
- 把事情的结果和自己的个人品牌建立关联
- 动手能力要过关
我的过去如此，大概我的现在也如此。
作为一名下属，我觉得是我这种遇事迎头解决、全力以赴的方式，让领导一次又一次更加信任地将事情交给我。但是我不是万能的，我一定有解决不了的事情，这时候我的另一个经验就发挥了作用，我会尽力将我的困难及时地向上反馈。从协作网络的角度讲，我应该算是一个合格的网络节点。而这些认知，也大概变成了我对别人的期待：
- 在成为一名专家之前或者同时，你需要成为一个优秀的网络节点，这样才能在一个组织网络中，让组织的效用最大化
- 既然是网络节点，就需要快速、准确地传递信息，不论是你能做到的，还是不能做到的，都需要及时反馈
这就是我内心的一些价值主张。
新公司
回到我的新公司，一个既新又充满历史的组织，新是因为对于我是新的，顶层boss是新的，管理思路是新的，旧是因为人是旧的，思维模式是旧的，具体执行的组织结构是旧的，遗留的系统是旧的。
这里的新旧，不是我作为好坏评判的标准，所以暂且忘记哪些是旧的，哪些是新的。
单纯讨论公司的架构，可能需要我铺垫太多跟公司相关的背景知识，你才能做更进一步判断，那么我就从我们做出“产品”的团队，来向你描述我们的组织形式。
我们的产品，大多并不大，从形态上，你可以理解为像微信这样功能相对不是特别臃肿的形态，从用户规模上，你倒是也不用太在意，如果数量庞大，大概公司也就不会经历四轮换帅了。还有一些产品的形态，像是一个短期的活动，你类比一下美团搞个朋友圈裂变？又或者是一个在线抽签的小程序？虽然外在形态上不复杂，预期用户规模也不大，但是因为历史原因，我们有面向几亿用户的架构设计，我们的服务之间也是尽可能松耦合。如果公司是一步一步发展成现在这样的，我们大概会称它为过度设计，但既然是已成事实，那现在倒是也是一套不错的规范。
在描述组织形式之前，我花了这么一大段来写产品的目标，是因为我认为组织之所以有各种不同的形态，是因为没有一劳永逸的组织，它是人和目标之间妥协后的一个结果。
现在的组织形式分两个维度，按职能分：
- 产品团队：定义产品、设计产品
- 研发团队：前端研发、后端研发、大数据研发、算法研发、测试、外包
- ------ 没有运营？对，目前并没有，所以谁操心谁来……
按产品分：
- 产品1：产品总监、产品经理、研发、测试
- 产品2：产品总监、产品经理、研发、测试
- ……
- 在最顶上还有一个领导，负责这个事业部的战略、资源、决策、对外撕逼等
但是完成最终的产品除了上面这些同学是不够的，前面介绍过，我们是一家大公司，有面向几亿用户的架构，所以在我们事业部外，还有UED、大数据团队、服务器管理团队等，这些也都可以理解为基础资源。
够了吗？还不够的，因为我们的产品也不是孤立存在的，我们一个事业部下面的产品1、产品2，可能是互斥的，可能是互补的，目标通常也都是服从事业部总体战略的，但整个公司，其实有一个更宏观的战略。就我们公司而言，我们对外统一有一个小程序，而我们的产品1、产品2，当然也不是所有产品，大部分也都是在这个小程序下面的，你可以理解成不同的功能或者模块。而这里说的小程序，是另一个事业部。
至此，我所描述的关于组织形式，甚至包括我们的“地形”也和你描述清楚了。
现状
我觉得任何主观地评论都不如客观地陈述更适合我这种管理学菜鸟，但我可以把我看到的写下来，咱们一起讨论。
案例A：
现在产品经理会负责定义产品，并获得产品总监的认可，然后和研发、测试的同学宣讲，研发的Leader会同意研发的同学接手这个项目，并自行确认研发细节和产品的同学沟通，同时测试的同学会形成测试用例，并和产品的同学进行确认。前面提过，我们没有运营，而且我们的产品同学表示，我们不会。
虽然他们嘴上说不会，但是他们可能更多想要表达的是不愿意，他们所指的运营，可能更多的是产品上线后的推广和使用。至于产品形态在实际生产中的应用，他们脑子里有个简单的雏形，也基本都通过实际行动体现在产品中了。为了便于读者理解，我这么类比你可能更容易理解。以一个公司撒钱发红包的例子来说，用户需要扫一个二维码，然后微信发个红包给用户，这里需要有线下二维码，他们会在大街小巷出现，它应该是呈现在一个易拉宝上面的，然后放在路口而不是放在垃圾桶后面。到这里，我们的产品同学大概都能想明白，但是，具体这个产品，是否要有个活动主题，是应该结合春晚还是结合元宵晚会，奖品是每次扫码都给吗，还是扫几次给一次，还是多试试做个ABTest？这些是我们的产品觉得不应该去思考的。
这大概是关于如何造出产品的一个案例。
案例B：
产品总监（我）：我觉得有个问题咱们讨论一下哈，咱们这个项目虽然形态上是要发红包出去，但是我们其实对收上来的数据是有要求的，我们要求同一个用户，要领多次红包，这样的数据才对我们的数据建模有帮助。我们之前有个假设前提，是用户都是贪婪的，用户会到处去找不同的二维码扫，但是用户第一次在我们的产品里面领取到红包后，我们并没有任何提示让用户去扫第二个，那么按照大部分产品，比如支付宝的用户习惯，用户可能扫完就走了。因为线下活动的条件限制，我们只能在收银台摆放我们的二维码，这就导致这些二维码的曝光率会大大降低。既然是收银台，那么正常的用户行为，可能是一次游逛，仅去了一次收银台，那么用户去下一个收银台就缺乏动机，我们就得把这样的动机，在我们的产品里面表现出来，我们不指望那些不喜欢钱的用户去领，但是我不能让那些其实想要领钱，却因为我们没有告知他，导致他压根不知道居然还能再领钱的事情发生，举个简单的例子，我们在领到钱之后可以给一个用户提示，让用户知道。从这点讲，我们现在还有需要改进的地方，否则真的数据收上来，质量不行，咱们这笔钱就白花了。
产品经理：我们现在的产品就两个页面，没有地方可以加什么提示了，真的加了，也没有人看的。
产品总监（我）：我只是希望你想一想这个问题的解决方法，不一定是我说的在扫码后加个提示。
产品经理：我觉得你想要让数据有效，你就得砸钱啊，你说数据不好看，你就砸时间长一点，你现在只有两万块钱，我当然没有办法保证质量，我觉得有人扫这个红包，这个产品就是个好产品了。
产品总监（我）：你知道我们现在客观情况是不可能无止尽砸钱进去，而且好像并不是钱多钱少的问题，而且我的权限也改变不了这个钱的多少。但是我觉得目前这个产品有很多可以做的事情：
- 在你的扫码二维码上，把咱们缺失的信息传达出去，也是一个简单实际的方案
- 在你的页面末尾加个提示，也是可以的
- 在你的页面前置一个今日扫码资格次数，也是电商常用的伎俩
- 或者你做个应急预案，咱们就算现在不改产品，也可以在上线后实时监控数据，如果数据不行，我们可以把这批用户的手机号拉出来，给他们群发短信告诉他们还可以再去别的门店领钱，这也是个方案，不过如果要这么做的话，我们现在就得提前让研发的同学准备查询语句、找短信网关的同学去协调资源，到时候怎么看，什么时候需要启动这个策略也都需要提前明确。
我们估计也只有这么一次撒钱的机会，我们都不希望这个东西因为数据不行再做第二遍，如果真的到了那一天，人家只会认为我们的产品有问题对吧？
产品经理：继续辩解……短信也没人看、不会领的人就是不会领、第一次数据我觉得不好很正常、一开始让我做这个的时候，我就提出来了，这个东西不可能数据会好，你又没有钱，你要做这种砸钱的产品，你有钱了再说，你想要数据好，你就多申请点钱啊。
产品总监（我）：就这样吧，我觉得咱们上不上线感觉意义不大了……
产品经理：最好别上
产品总监（我）：（冷静了一会）你这么理解啊，如果用户扫一次，我们算是解决了拉新的问题，但是第二次、第三次再扫，其实是解决我们产品活跃度的问题，如果我们大部分数据没有这样的活跃度，我们的这个方案，就还需要去优化。
就这样一次又一次地循环讨论，然后大概在我的领导路过之后，这个话题变得缓和了一点，后面会怎么样我还不清楚，我非常期待有一个比我想出来的方案更好的方案，或者哪怕是上面的方案，也尽可能落地一点。
这大概就是一次真实的交流，当然，有时候我会被说服，因为人家说的很对，我也虚心接受，或者在讨论时，我意识到自己追求的那一点完美，似乎无伤大雅，我就自动终止了。
案例C：
产品总监（我）：嘿，我也不太清楚你们实现后的细节，你给我说说憋。
前端研发：好啊，我给你说一下，%*&（**（……）*——
产品总监（我）：对哦，我确认一下，这个LBS信息你记录了没有啊？我要手机的LBS，你们不要弄错了哟。
前端研发：哦，这个我不知道啊，不是我记录的，是后端的同学。
产品总监（我）：那你回头帮我和他说一下吧。回头如果我们被薅羊毛了，这个数据可能会很有用。
前端研发：记录这个干嘛，咱们产品是为了发红包，这些无关的就不要了。
产品总监（我）：呃%%%%%，再见
这里我做个检讨，我们产品团队，并没有在一开始，刻意去强调应该记录的内容、字段，以及这些数据的用途，可能我们讲清楚了项目的目标、暴露给用户的功能，却漏掉了最后在后台要做分析所需要的这些素材，但这些数据一旦没有存，在未来想要复盘的时候，将出现重大的缺失，虽然凭借我们的聪明才智，总能把后续的“总结”工作做得很完美，但我还是希望未来将这部分需求定义，也作为前期沟通需求的一部分，提前加进去。
当然，上面这位前端的同学这么说，除了因为和我太熟了之外，也客观暴露出一个问题，那就是前端潜意识认为，我没有做错什么，因为我做的都是产品的同学让我做的，所以我不接受修改。
故事先讲到这里，这大概就是我所要破的局。
你有什么高见？
