尤其是产品经理，职业习惯的借鉴竞品成了开发、设计师口中的抄袭。
比如腾讯之前的立知、和即刻APP，就因为抄袭还走上了官司。
但要承认借鉴竞品可以明显的降低产品研发时间，同时更快的打造不属于竞品的用户体验。针对小团队来说，抄袭某产品的功能、还有热点产品的业务方式，还可以带来巨大的收入回报。
运营、设计师、产品经理在抄袭借鉴的过程中容易陷入一个误区：
别人能做，为什么我们不能做？
因为没有深入调研和洞察对方产品，无脑完全抄袭，不考虑技术成本、技术难度，导致产品无法开发上线，最后商业模式根本无法实现。
比如我在带团队搭建大数据平台下，我们发现了一些瓶颈和错误的案例，就是走了这样的弯路。
每个互联网产品无论是APP、还是web，最终承载的是业务模式。解决用在各类场景下的问题
比如记录喝水的APP，方便日常对饮水管理的用户，提供了一套完整针对水的方案。核心壁垒是水数据管理、人体健康与水的关系。
比如拼多多背后强大的供应链能力，能够直接找到厂家对接的运输方式。普通人开发一个拼多多，没有上面的资源，根本无法启动项目
每个互联网产品都有自己的壁垒，从创业初期开始，创业者或项目产品经理就要思考BAT能不能快速超过你？ 核心壁垒可以是运营方案、技术功底、资源优势等。
先发制人，总得要一个壁垒才可以实现行业的top1和营收机会。
回归到本次案例来，带着团队原计划完成APP的数据统计平台。行业里有gIO、神策等不同厂家。
由于关联数据统计，产品经理一拍脑袋就原封想借鉴类似产品。但在实现过程中发现了技术壁垒的问题。
比如前端或客户端的数据统计，需要多少字段？多少事件？能不能把整体统计封装一个SDK？
▲ 神策技术架构
其实这都是技术问题。
传统统计方法是针对某几个数据做接口对接，可以实现简单的报表展示，但是一个互联网产品有几十个、上百个页面，如何适应到其他互联网产品呢？还能满足自定义数据的查看？
产品经理则聚焦在数据字段、页面展示、报表展示上，却无法洞察和了解到数据统计平台的技术壁垒，这也可能造成项目直接失败。
由于前期没有花时间调研技术壁垒和攻破成本，让项目遥遥无期。
抄袭的一定是要站在通用性上
产品经理首先要借鉴的是对方产品的全局功能，比如交互样式、UI样式、和非业务数据的功能性模块。
消息通知、信息流、个人中心都属于这类功能性模块。
但支付、钱包、数据统计的SDK方式，则是偏向技术底层的支持。
同样类似知乎、简书这样的产品，则是由内容矩阵构建的，产品经理无法抄袭对方的内容运营壁垒、内容矩阵。
综上，产品经理的竞品借鉴需要较多的个人经验、项目案例来积累。只有亲自走过一到坑，才知道困难在哪里。
不要轻易认为抄袭别人多简单，要多考虑别认为什么没有这么做？和他的壁垒是什么？
