数据百问系列：关于数据仓库，什么样的产品是好的Partener？
0x00 前言
本次讨论的主题是：对于数据产品经理的突出能力，你更看重哪一方面？
问题：
现在有两个产品可能会和你合作：
- 一个产品，不懂技术细节，但是能给你带来业务价值，能帮你把数仓推广到全公司，帮你在老板前露脸
- 另一个产品，对数仓很了解，甚至能帮你设计一套数据仓库，可能比你设计的还好，但是其他方面一般般，比较偏研发
这两个产品，你会选哪个做你们的合作伙伴？请说出你的理由！
分析：
本话题是一个发散性的话题，并没有限制太多的内容，主要是想跟大家讨论一下在实际工作中我们会更希望产品经理具有哪一方面的能力，又是为什么这么选。
0x01
选择第一种：
讨论一：
第一个啊，我觉得搞数仓从来技术难点就不是第一位，最重要的是能从上至下的去推动这件事情，打通部门之间的数据孤岛，还能让他们觉得做这个事情是有好处的，愿意支持你去做。如果业务之间都在打架，再好的技术也是巧妇难为无米之炊~
讨论二：
第一个。第一业务价值也是很重要的，业务比技术的不确定性更多，有时候更有价值；第二业务价值是最终归宿，虽然说好的技术根基不可缺少，但是目前“我”已经可以解决大部分技术问题了，有一个能在业务商业方面擅长的，组合起来产生力量，就显得很重要。
讨论三：
我选择第一种。主要从几个方面进行思考：
- 首先，现在任何一家自主研发的企业，都或多或少有着一定的数据量，随着大数据概念的起来，数据由后面被推到了前面，成为了主要研究课题，但是实际上对于数据应用的场景还处于探索阶段。 数据是资产，如何让资产发挥最大价值是需要产品经理来思考和设计的，
- 其次从数据产品的能力模型，由于市场上对这个岗位没有明确的标准，所以我将其分解，产品能力，数据能力，产品能力就是要敏锐的市场洞察力，业务深度理解能力； 数据能力，是从另外一种视角去逆向思考，并且抽象业务框架，从帮助业务提高业务效率，产生最终收益。
- 最后，从我数据产品角度来说，即使太强的技术，没有应用场景，我觉得都是闭门造车，最终的结局就是淘汰。 以上为个人见解。
讨论四：
选一。原因：技术只有在解决业务问题才会有价值，数仓的一些建模方法可以在实践中学习，而业务的理解与数据的打通才是重点，如果有人帮助你去理解熟悉业务，并辅助你推动数据驱动业务会轻松很多。
讨论五：
从社会现象上来看，从来都不缺那种这也懂那也懂的人，当然，现在复合型人才很受欢迎。不要被这种受欢迎现象迷惑了，国家、社会、企业，其实更需要的是某一领域拔尖的人，他们才是发展的推动力。 同样，回归到东哥的这个问题，一个技术，一个产品，技术又是为业务服务的。业务又是依赖技术去实现。分析如下情况:选1:产品能将你设计的数仓发挥1 1>2的价值。选2:技术角度，数仓虽设计更好，但也只是限于技术，也就只能发挥普通的1 1=2。综上所述，选1更为理智。选2更偏执于追求技术(虽然我也是搞技术的，但要是让我做决定也不会选2）。
讨论六：
看自己现阶段的需求，前者像另一个次元的帮助，后者像同一个次元的帮助，因为都是搞技术的，如果非要二选一的话，选1，从业以来感受到的都是业务大于技术，先占地盘，后练技术，机遇不是何时都有的。其实比较倾向于都做合作伙伴，如果有偏向的话，与1业务做伙伴，遇到瓶颈难处，请教2技术大拿。
分情况选择：
讨论七：
从定义上，软件业是服务业，这个提法是很有深意的。 软件项目的价值，产品只占40％以下，60％是产品背后的服务。 如果终端用户很牛，会选第二种，且是第二种的后半句，产品厂商提供按需定制的工具，你的设计都不一定是人家要的。此时，你提供的是40％那部分，另外那些，人家自助了。但同时，对工具是否顺手，要求高。 另一种就是甩手掌柜型的，花钱买的不仅是产品，还包括服务，甚至第二种的前半句，让你设计模型。此时，客户很少关注产品功能，甚至很少操作产品，只要结果。此时，产品好坏实际并不重要，反正是你用的多，你自己用自己的产品，向客户提供服务。 其实，还有第三种，A用B的产品，向客户提供服务，A是60％那部分，B是40％，从产品角度，A会根据自身能力，选第一或二种。
选择第二种：
讨论八：
我选择第二，针对于企业来说，业务应该适应于企业发展和经营情况而改变，我觉得一个好产品并不是只靠口碑推广就能获得价值，而是我能为为公司根据发展需求去设计一套符合自己实际需求和实用的数据产品，并且用数据产品业务目标去引导，改变企业管理和发展方向
0x02 补充
对于这个问题，我感觉还是应该分情况来讨论。毕竟是“你”想要的伙伴，那么选择哪一种其实是由“你”现在所处的位置、“你”的能力、“你”想要获得的收益、“你”想要实现的目标等多种主观跟客观的因素共同决定的。所以在讨论中才会出现各种两种不同的声音。而对于我来说，我想我会在以下三种情况下进行不同的衡量与选择：
- 我自身的开发能力很强，不需要产品为我解决技术上的问题。 那我会选择第一种，技术问题我来搞定，但是我需要产品为我打通老板及各个部门间的关系，说服他们支持我们的数仓建设，能让我们引入数据并将数据打通。 也需要产品能很好地理解业务场景，让我少花时间在业务理解上的同时也让技术能实实在在地落实于业务中。
- 我自身开发能力较差，又希望能有个懂业务也懂技术的人带一下我，那我会选择第二种。 有些数据产品经理其实是从技术岗位转过去的，一个能比我设计出的数据仓库还要好的数据产品，还具备业务能力，就算业务能力一般，他也能给我带来很多的帮助。 当我的数据仓库开发不下去的时候，他能站在数仓与业务的角度给我建议，对于我来说，这就够了。 如果是业务能力很强的产品经理，当我的数据仓库开发不下去了，就算是各个部门的数据过来了又能怎么样，我搞不定它们而他也帮不了我，这样反而容易让项目搁浅。 当然，你也会说，你开发能力差肯定会有大拿带着你的，技术上的事基本上不用数据产品来帮你解决，你问一下部门里面的大拿就可以了。 的确，但是对于自己负责开发的模块，我觉得还是直接跟产品对接比较好，在业务的理解与需求上面，他肯定比其他同事要更加的清楚，而这个时候，如果他还懂很多的数据仓库开发知识，那么对于我来说，帮助就很大了。 当然，还有一点就是这个阶段的我更关心的是我能不能把需求写出来而不会去过于操心这个数据仓库最后会推广的怎么样。
- 我开发能力一般，但是我可以搞定数据仓库的建设，虽然它设计的不是很好，但是运行起来还是可以的，这种情况下，我会选择第一种。 我已经拥有能把数据仓库开发好的能力了，我现在想要的就是我所开发的数据仓库能落地下来，得到其他部门的支持与认可，获取到相关的资源并应用于业务中，那么一个业务能力强的数据产品就可以帮到我很多了。 他能推动我们项目的进程，为我们的项目争取到资源。 “先圈地再优化”，不管我们的数据仓库设计的怎么样，反正先用起来，后续我们再慢慢地进行改进就可以了。
0xFF 总结
两年前我肯定选2，做好做不好无所谓，自己学到就行了；现在会选一，因为希望有个产品帮我想好价值，帮我推广；再过几年，我希望我能选2，到时候招个产品给我干活就行了，价值我很清楚。
感谢所有参与讨论的朋友！
