前言
在我的职业生涯里, 我曾意外带过一段时间产品团队, 虽然做产品的时间很短暂, 但因为长期从事技术工作, 让我在这段短暂的经历中收获了异常丰富的内容. 借着这篇文章就想和大家聊聊作为一个前端工程师应该具备哪些产品思维, 如何和产品有效沟通和交流.
正文
产品经理究竟是做什么的?
产品经理是一个很宽泛的岗位, 在不同的行业, 不同的企业其内涵可能差别很大, 举个简单的例子, 在一些日化企业, 例如宝洁, 据我所知 保洁公司是最早采用产品经理来管理产品的研发生产的企业, 但工作内容和我们所了解的产品经理是完全不同的, 彼此掌握的技能也相差很大.
但核心职责我认为是不变的, 也是从我的角度区分一个产品经理是否合格的基本判断标准. 这个后面会讲, 回到宝洁的产品经理, 其工作内容主要是从市场部门搜集需求, 包括用户调研的内容, 对内容进行分析, 甚至直接接触用户, 然后构思和设计新的产品, 包括包装, 产品功能, 其中包含一些日化的专业性知识.
之所以会有这样的岗位诞生, 主要是因为在过去的生产关系中, 从市场端的需求到研发部门, 包括包装设计和专业设计, 再到工厂生产, 这么长的一个链路, 缺少一个直接对结果负责的人, 市场不会关心是否研发部门的问题, 研发部门也无法确定是否工厂的工艺问题. 相比软件企业中的项目经理, 产品经理会更侧重于外部, 如果把企业看成是一个外部用户和企业员工的关系总和.
那么 产品经理主要负责的就是用户和企业的关系, 而项目经理则负责企业和员工的关系.
因此产品经理做的事情概括起来就是, 通过设计改善既有产品来协调企业和用户的关系, 用户越满意, 和企业关系就越紧密, 企业包含了企业内所有为用户提供价值的部门.
所以什么样的企业其实不需要产品经理?
-
强公关型, 例如媒体广告, 用户和企业的关系并不通过某种产品来连接
-
服务政府的企业, 像很多给政府做软件的, 其实就是技术外包, 如果有同学在这种企业干过, 应该明白, 此类企业的产品经理其实就是项目经理.
如何用直觉判断一个产品经理是否合格?
作为技术工作者, 产品设计和管理并非我们的专业, 因此我们不好在专业性上去判断一个产品经理是否合格, 我在这里用了直觉两个字, 其含义在于对于我们而言, 接触产品的时间大多数是在各种需求评审或者是线下交流, 我们必须能够快速的判断产品经理说的东西是否合理, 这种快速判断就是一种直觉, 也是作为前端工程师想要避免无效加班需要修炼的一种工作能力.
这个直觉包含
- 逻辑是否自洽
- 理由是否含糊不清
- 通过数据是否可以证伪
让我们拆开来讲讲
逻辑是否自洽
通常我在面试的时候, 会针对面试者关于简历中他提到的一些项目进行提问, 其实这和我平时跟产品经理交流的方式类似, 就是针对细节进行提问, 这种提问方式不需要我仔细琢磨和思考问题, 我尽管提出我想知道的或者我不懂的问题即可, 直到没有问题可问为止, 而产品能否准确回答出我的问题就成了他设计产品的逻辑是否自洽的关键.
这种提问方式的关键在于, 抓住一个点连续提问, 而不是发散思维, 通常产品在进行需求评审的时候给出的原型五花八门, 有详细也有粗略的, 我们可以专挑那些不怎么详细的部分, 不断的提问. 这既是减少后期实际开发中问题的方法, 同时也是提升自己工作能力的一种方式.
所以一定不要做一个闭嘴工程师, 学会在需求评审中提问非常关键, 当产品被你问的语无伦次的时候, 你大概就知道他是个水货了. 尤其是你自己还是个新手的前提下...
提问的能力对于每个人来讲是不同的, 一开始你可能提出一两个问题就问不出来了, 不过没关系, 后面加加班, 你就知道下次该提什么问题了.
理由是否含糊不清
我遇到过很多扯淡的产品最喜欢用的反驳理由是, 用户那里就是这样的, 运营要求的, 老板说要这么搞. 先不说我们能不能反驳掉这种需求, 但作为一个前端工程师, 你应该懂, 当一个产品开始这样敷衍你的时候, 这家公司都是有问题的...
通过数据是否可以证伪
此处的数据不一定是具象的, 也可能是一个结果, 但核心命题在于, 产品提出如何需求, 设计, 改进的方式, 最终应该能够通过上线后的结果证伪, 比如产品说这个需求可以改善转化率, 那么如果转化率不改善的原因会是什么? 产品应该先假设失败情况下的原因, 并且我们也应该知道
这个需求能达到的预期结果是什么, 如果达不到会有哪些原因? 如何分析是什么原因造成上线后不如预期? 这是个通用句式, 你应该记下来, 你可以在评审的结束时间抛出来. 秀一下你的产品思维 😁
一个成功的产品不是一开始就是成功的, 但是如果任何一次迭代都没有数据沉淀下来, 从来不分析迭代结果, 那这个产品一定不会成功, 如果产品不成功, 那最终结果都会落到我们头上. 记住这一点可以绕考一些坑爹的公司和部门.
学会在评审的时候张嘴, 和产品交流的时候动脑, 是成为一个高级前端工程师的基础, 通过上述几个点的不断练习, 把每一次需求评审看成是一次增强直觉的机会, 你就不会觉得评审无聊了, 同时还能审视下自己公司的产品是否合格, 不是很有趣么?
最后聊聊用户体验
在我刚成为高级前端工程师的时候, 我会被反复的灌输, 用户体验至上的前端工作理念. 追求极致的用户体验等等.
但经过这么多年, 当我成一个专家的时候结合我在产品上的理解, 我意识到用户体验, 不是简单的用所谓的极致就可以解释的.
事实上人的体验是一个非常主观的感受, 相同的产品在不同人身上得到的体验可能是完全不同的. 甚至在不同的时刻体验都是不同的.
在这篇文章中我不会展开关于体验的讨论, 因为这个话题非常大, 这次我举几个例子简单说明下关于体验的几个核心要素
- 用户预期的体验和实际的体验
- 体验的低谷和峰值
- 体验平滑度
- 体验的传递
假设你买了一瓶吃拉肚子的药, 结果吃下去睡着了, 这就是预期和实际体验不一致, 但如果在你吃之前你发现上面的时间过期了, 这就叫体验低谷, 然后你去药店退款, 药店服务很好, 并且免费赠送了一些东西, 这时候你感觉还不错, 这就叫峰值, 如果下次你碰到了你朋友也拉肚子正好也在附近, 你会记得这件事同时推荐这个药物和药店给他, 这就叫体验的传递
但如果你买到的药没有问题, 吃了也好了, 体验很平滑, 你不会记得这件事, 这就是体验平滑度对体验的影响.
体验是件很值得研究的事情, 我们生活中工作中任何引发感情波动的事物都可以归于体验的范畴, 如果你平时注意对体验的观察, 我相信至少在产品思维上你就已经胜过很多不那么专业的产品经历了.
关于体验让我们后面再聊吧.
后话
我已经记不清自己开过多少次需求评审了, 并且我经常跟我的同事说, 需求评审的时候一定要张嘴提问, 哪怕只有一个问题, 我遇到过太多需求评审只有产品一个人在那讲, 前端工程师就像是透明了一样, 似乎所有的业务问题只和后端有关系.
但其实并不是如此, 如果你想让自己的职业生涯更进一步, 成为一名高级前端工程师, 学会在需求评审上张嘴提问, 掌握一点产品思维学会和产品有效沟通是你必须跨过去的一道坎, 而太多的同学忽视了一次次可以锻炼这项能力的机会了
