产品经理，该如何在你的业务赛道深耕呢？

　　我们要充满危机意识地去吸收一切知识，才能在自己的赛道上屹立不倒。
　　今天这篇文章只讲一个问题，并且要把这个问题讲透，那就是：“谁是真的产品经理？”
　　很多情况下我们会质疑：
　　如果一个产品经理对产品没有决策权，他还是不是产品经理？
　　如果一个销售人员可以对产品直接提出需求，他算不算产品经理？
　　如果老板随时对产品指手画脚，下面的产品经理还算产品经理吗？
　　其实这个问题是这样看的：产品经理是对产品的体验负责，对用户价值负责的那个人。其它的角色哪怕偶尔会提出所谓的“需求”，只要他不是站在平台和产品的角度上考虑问题，他就是一个“假的”产品经理。
　　打个比方讲：假如你是一个物业业主APP的产品经理，但这个APP的很多功能规则都掌握在物业部手里，比如当你想方便业主日常生活提高体验做一个扫脸智能进出的功能，决策权和硬件设备预算申请都要物业部审批。
　　那这个时候，有的产品经理就会想：我只是一个傀儡啊，只要物业部有个人稍微学学产品，就可以替代掉我啊！
　　真的是这样吗？上文这个业主APP产品经理和物业部的业务需求人员，到底谁是真正的产品经理呢？我们来分析一下。
　　首先，对于物业APP来说，产品经理是有决策权的，虽然这个APP看起来处处受制于人，但很多传统企业产品或者B端APP其实都是这样的，我们可以称之为业务支撑型产品。
　　那么这种产品的定位是什么呢？或者KPI是什么呢？
　　其实往往就是保障业务的顺利运行，在系统层面上不出问题。比如你打卡因为数据传输失败而导致业主进不去屋，那就是产品经理的问题；但如果业主投诉打卡规则不明确而导致外来人闯入，这就不单单是一个系统层面的问题，主要是一个底层规则的问题，起码业务部门要负主要责任。
　　基于这个假设，上文产品经理应该做的事，就不应该是“新增人脸智能打卡功能”，要不要这个功能，主动权在业务部门手里，他应该做的是“提升现有刷卡进出功能的智能性”，这个角度讲才叫做支撑型产品的发力点。
　　但有的同学会反驳：如果支撑型产品只考虑这么一点，那领域也太窄了，如果仅仅是在某个行业的一个点去思考，那就完全没有在这个行业的线性和体系里面深耕啊，后面当然很容易被替代了。讲到这个问题，我们已经看到了这个矛盾的本质，那就是：当产品经理权责过窄，如何合理拓展并顶住压力做出价值？
　　这看起来似乎是个很大的命题，但是道理其实很简单：目前随着传统企业慢慢的转型，互联网已经不是少数人的游戏，更多的互联网产品经理其实不是浪潮之巅的位置，而是普遍大众的岗位。一方面讲，产品经理的要求越来越高了，另一方面讲，业务部门也对同事有了产品能力的要求。也就是说，未来的各行各业各个岗位，产品能力都会变成一种标配和必需品。
　　那么有的同学觉得：这样来说的话，产品经理的地位不就岌岌可危了吗？怎么样才能保住自己的饭碗呢？
　　其实答案一直很显然，就是找一个业务赛道深耕，然后不断提升自己的产品能力。这两点听起来都烂大街了，但是难就难在大部分人是不知道怎么做的。所以我会在两个方面各举一个例子，来说明我们应该如何切入，并不断提升我们的能力。
　　如何在业务赛道深耕呢？比如说最近很火的裂变，怎么样能叫深耕，然后懂增长，懂裂变呢？刚巧微信刚刚出台了打击不合理裂变的政策，我们可以就这个点聊一聊。
　　对于裂变来说，本质是通过一定的机制来扩大内容的转播达到增长的目的。之所以叫裂变，是充分利用了用户的分享和推荐，形成了指数增长的态势。但现在很多课程都是先分享、再加群、再转发，弄个半天才能看到内容，结果看到了内容之后又大跌眼镜，这对于平台来说，就是劣质内容的传播噪音，对于用户来说，就是感情和价值的双重欺骗。
　　所以如果每天研究这种“裂变”，严研究如何包装自己的分销机制，那就是跑偏了，算不得深耕。
　　那什么算是深耕呢？
　　深耕指的是你更加清楚这个行业的基本逻辑，更加接近底层的原理，这样你的眼界可以让你的决策凌驾于其它人维度之上。比如对于裂变，其实核心是内容要好，内容好的前提下，我们通过利益的适当诱导来促进内容的曝光。也就是说增长的来源应该是优质内容曝光带来的，而不是利益套利益带来的。
　　如果靠玩小把戏裂变，那么你引来的流量也是短暂而不精准的，就算短期你可以狠狠薅一把羊毛，但总有一天你的粉丝会爆发，你的人设会崩塌。
　　正确的深耕应该是通过裂变数据进行分析，比如对于教育赛道来说，看看什么样的内容和标题，吸引了什么样的群体，这个群体的转化率如何，是否可持续且有好的反馈？
　　通过不断的试错积累丰富的分群经营经验并迭代优质内容，才是我们深耕得到的核心价值。当你有一天可以熟悉互联网产品运营手段的优劣势，同时可以比业务人员更懂业务，你就成功了。
　　那么产品能力方面呢？我们从最常见的一个场景，体验优化讲起。
　　体验优化是什么？首先要定义体验，体验是触及用户后，用户与产品互动后得到的直观感受。体验是很严谨且准确的东西，并不是一种很玄的东西。比如你的界面加载7秒钟，第3秒有20的用户选择了跳出，第5秒有80的用户选择了跳出，这就是赤裸裸的体验问题，如果这个载入体验优化到3s以内，可以为你减少跳出率到20以下。
　　所以体验要从数据和场景中来，并不仅仅是界面好不好看，交互好不好用。
　　体验是什么决定的？我觉得有三点：
　　范围层产品逻辑的设计
　　表现层视觉和交互
　　研发的进度和质量
　　底层产品设计是往往我们容易忽略的部分。比如领导让改版一个界面，很多人就第一时间埋头苦干，打卡axure先画10几稿原型再说，这样往往就是领导不知道你在改什么，你也不知道领导要什么，做后要么是草草上线最后再被改掉，要么是拖着拖着这个需求就不做了。这种情况的发生，是对彼此生命莫大的浪费。
　　正确的打开方式是什么呢？
　　首先拿到一个命题，要拿到数据和用户的场景进行分析，先检验底层逻辑的问题。比如一个审批功能，如果是重要需要确认，那么默认就是未审批状态；如果是公示周知，那么默认就应该是逾期自动认同状态。底层场景的不清晰，会浪费很多人力。
　　视觉和交互层面是最容易被关注的点，只要能够充分满足底层逻辑，并贴切地表现出来，一般没什么问题。但研发的进度和质量是最关键的点，也是产品经理需要持续修炼的能力。即如何把你的产品主张和节奏正确地同步给研发团队，并跟进上线，同时保证关键产品设计的高还原度。
　　研发质量的提高，可以用问题解决模型来做，即：定位问题拆解问题落地方案。比如：人力经常不足，可能是人力投入不合理、紧急需求过多、代码质量过差、招聘缓慢等很多问题导致的，这时候就需要产品经理牵头协同关键人物一起把问题定位出来并推动解决掉，否则只能是恶性循环。
　　所以产品能力层面的深耕还是有一片金矿待我们探索的，无论是研发领域的敏捷、管理领域的OKR、数据领域的爬虫挖掘、设计领域的心理学和美学，都是我们提升的方向。再小的项目，只要是涉及到协作和研发流程，只要我们用心去做，总能比业务部门得到更多的产品方面的经验，这也是我们可以积累并赖以生存的核心资源。
　　总结一下，如果你作为产品经理，你的地位被挑战，你的能力和业务部门趋于同质化，你要做的就是主动出击，在既定赛道上深耕，无论是业务能力还是产品能力。你最最不要做的就是和业务同事互相看不起同时自命不凡，因为产品经理高人一等足以封神的年代已经过去了，在这个HR都会讲用户体验的年代，你要做的是接地气，并用产品能力融会贯通。
　　真的产品经理，一定是懂产品，并且有丰富实战经验的。一切标榜自己是产品经理，却思维毫无框架、毫无系统意识的伙伴，其实都是假产品经理。
　　但真与假的界限会越来越模糊，作为真的产品经理：
　　我们要充满危机意识地去吸收一切知识，才能在自己的赛道上屹立不倒。