记录一下自己产品方法论的迭代

每个产品经理都有自己的产品方法论。

随着大家工作和经验的积累、认知的深入，产品方法论也会不断更新，就像产品迭代一样。

老K本人做产品经理短短6年时间，对产品经理核心能力的认知就经历了5次迭代。

本文记录一下我对产品经理从入门到跑路、从看懂到看开的过程。

01 需求

我刚入行做产品时，那是个“万众创业”和“人人都是产品经理”的时代。

由于供求关系失衡，那时做产品经理的门槛低的吓人。

有多低呢？会用axure画原型、能随便侃两句用户体验、产品价值等，基本就能拿到产品经理offer。

一点都不夸张，亲测有效，我当年就是这么从市场转产品的。（当然现在不行了）

一开始做产品，我认为产品经理的职责就是把用户的需求变成产品的功能，期间需要做的是识别需求的真伪、频次和优先级等。

用的方法就是简单粗暴的感知需求。

当时深信产品经理就应该是产品最铁杆的用户，以及“一秒变白痴”去体验产品。

真就应了那句话：这不是用户的需求，这是你产品经理的需求。

现在看来，感知需求其实挺粗糙的，如果做的产品就是面向年轻人，那还好，自己就真的是目标用户。

而如果产品是面向特定标签的人群，比如老板、老年人、股民等，无法浸入到真实的场景，很难感知到真实的需求。

野路子产品经理经常陷入的误区就是无比自信的瞎提需求：用户都是沙雕，我比用户他妈还懂他们。

02 数据

这个阶段还是围绕着需求来的，不同的是，获得需求的方法从感性回归理性。

最开始做的是O2O产品，自己就是真实的用户，所以自己去挖掘需求也没啥大问题。

后来做了一款P2P理财产品，这就有点难办了：我对理财毫无经验也毫无兴趣，自己挖掘需求，那就是满脑子的“还特么能有这个需求？？？”

还有一个小原因：拿着你拍脑袋得出的需求去跟程序员辩论，非常容易陷入各说各话的情况，谁也说服不了谁。

这个时候，有数据拍脸，情况就非常不一样了。

所以在这个阶段，我非常重视数据，用问卷调研的数据分析结果决定需求的真伪、频次和优先级、用A/Btest决定用户体验的差异、用埋点来确认产品流程是否合格。

整个人都变得无比理性：数据是不会骗人的，是最好的决策依据。

这个阶段我对产品经理的工作非常的满意，很理性、很互联网、很geek…

03 业务

我曾经认为产品经理都是USB型人才，掌握的都是通用性技能，即插即用。

直到后来，我跨行业跳槽，跳到了B端saas行业。

从C端跨越到B端，之前的很多东西好像突然都不灵了，甚至你面对的产品使用者，也从“用户”变成了“客户”。

to B产品与to C端产品区别是多方面的：更多的付费、付费人与使用人不一样、获客靠销售而非运营、产品更复杂更贴合业务…

其中最重要的是，产品与业务深度融合，其结果就是，如果你不精通业务，很多产品设计都没有依据、无从下手。

我们团队做过多款HR saas工具，为了了解用户的使用场景和痛点，产品经理就要与HR小姐姐反复的沟通，在这个过程中，大家建立了深厚的友谊。

闲暇的时候，产品部的同学经常帮HR小姐姐们处理一些非涉密的工作，在兼职HR的过程中切身感受用户以及使用场景。

到最后，在某些特定的业务场景，HR小姐姐甚至会跑过来请教我们的产品经理，这样才能算是深入到业务中。

除了泛B端saas产品之外，基本上所有涉及传统行业的互联网产品都与业务紧密结合，比如旅行、电商、在线医疗、在线教育等等。

在这些互联网赋能的传统行业里，高级产品经理基本都精通业务，每天花在业务上的时间多过产品，是典型的“T型人才”。

04 协调

我一直认为，大城市的互联网行业拼的是能力，不是人情。

直到我做到中层管理，才发现有人的地方就有江湖，而江湖不是打打杀杀，江湖是人情世故。

往大了说，作为天使投资人的雷军，投资最多不超过两层关系，仅限于朋友和朋友的朋友。

往小了说，在产品线复杂的公司里，要争取更多的资源，保证产品的顺利迭代和推广。

协调能力，是处于管理层的产品人的核心能力之一。

协调更多的资源，没那么多方法论，很多时候说白了就是刷脸。

凭什么能刷脸，取决于很多，比如你的职位、所属产品线的地位、跟大领导的关系、与目标人的私人关系等等…

我情商不高，不太擅长与人打交道，人情世故的东西，大家可能比我更懂。

05 佛系

不同职级的产品经理做不同的事儿，初级产品画原型、中级产品捋业务、高级产品拉关系…

如果说有一件事儿能贯穿产品经理的整个职业生涯，那可能就是吵架了。

一开始跟程序员吵，后来跟市场运营吵，再后来跟其他部门负责人吵，最后跟老板吵...

一开始我也想不明白，为什么产品经理在跟所有人吵架。

抽身出来之后，以一个旁观者的身份看待这个问题，我才有一点点开窍： 产品经理可能是整个公司里唯一一个站在用户这边的人。

开发要“少快好省”的写代码、销售运营要增长、老板要营收，可能只有产品经理才会去为用户考虑，因为工作职责里有满足用户需求这一条。

立场不同，协作起来就免不了吵架了。

我也是这么一路吵过来的，拍过桌子摔过门，现在也看开了：工作嘛，还要佛系。

只要你别太过分、别把产品往死里作，那我就都行、可以、没关系~

- end