时间: 2021-08-03 08:55:27 人气: 15 评论: 0
真正的产品，是满足用户需求痛点、给用户创造快感，或者成本节约带来的感受。这种感受既可感知，也有可能不可直接感知。
产品经理到底要不要懂技术，是否技术出身的产品经理一定更有优势呢？
对于这个问题的探讨，相信各位都能在各个产品论坛上看到，不少产品经理估计也参与争辩过。笔者自己曾是技术出身，且刚毕业时做全栈开发若干年，也有过技术架构经验，所以对于产品经理要不要懂开发，笔者认为懂总比不懂的好，不过之前所带过的产品团队中也有不少不怎么懂技术，但却挺优秀的产品经理。
笔者认为，无论是否懂开发，总**有你不懂的新技术或未接触过的领域，而对于产品经理而言，最关键的不是把功能开发出来，而是要把需求价值开发出来，要把产品最有价值的能力不断挖掘，服务于用户，才是产品经理的“正事”。
那么，当一个产品经理遇到一些技术性很强的产品需求，而靠自己过往的经验又很难把控的时候，又该怎么将这些需求开发出来呢？
无论是技术型需求还是业务型需求，对产品经理而言，在拿到一个自己不懂或未接触过领域的产品或模块时，先不要慌，也不要认为技术性需求纯粹是架构师们的事，跟自己无关。任何技术都是服务于产品，是为产品价值的输出。
假设我们现在需要开发一个系统服务运行健康监控功能，这对于很多一直从事2C产品的同学来说，基本上都是很陌生的领域。当我们拿到这样的需求后，很可能一时间不知道该怎么办，甚至**把这种需求直接踢给架构师，或者研发经理，让他们先按自己的想法做一个出来，然后再慢慢理解后改吧改吧。
如果按此方式推进，那必然**造成最后开发出来的功能很难用，或者浪费很多的成本。我们一直讲，产品经理要有成本意识，所以是绝不能容忍上述情况的发生。
本文主要是希望所有的产品经理都能按价值维的思考模型去对待任何一个需求点，不管是业务型还是技术型需求。
如何理解价值维呢？
“真正的产品，是满足用户需求痛点、给用户创造快感，或者成本节约带来的感受。这种感受既可感知，也有可能不可直接感知。”这是笔者比较认可的“产品定义”，其中写的感受，其实就是产品的价值。
产品经理在设计任何产品功能时，一定要以价值作为功能设计的驱动力，这样所设计出来的功能才是“活”的。同时，对于我们的用户而言，使用产品时首先想到的是产品价值到底符不符合自己的真实所需，所以我们的用户在使用产品时，潜意识里也是由价值来驱动对产品功能的使用。
我们再回到本文的主题，对于产品经理拿到技术性需求时，照样符合上面所讲的价值维思考模型。那么我们从哪些方面来把握住这个价值维，或者说来处理好这个价值维，并实现需求落地呢？
对这个问题，笔者认为从以下几方面，就可以比较好地去满足价值实现。
（1）聆听用户意图
按照价值维思考模型，我们应该找到使用该功能的“用户”，去了解分析用户为什么需要这个，能带来什么能力，尽管一开始我们拿到的是一个偏技术的需求。如果与用户的沟通是有效的，那么产品经理就可以从很容易地勾勒出功能价值，甚至你还可以沿着价值维，寻找更有效的帮助研发找到技术实现路径。
通过对功能价值的勾勒，将非常有助你去了解“技术”背后所隐藏的商业意义，这时候你**发现，原来这么技术性的需求，也可以通过用户视角、业务视角、交互视角去分析，甚至还可以挖掘出更多具有商业价值的功能点。
（2）竞品调研分析
除了去跟你的用户进行有效沟通外，产品经理一定要记得去寻找对应的竞品。经常做竞品分析的同学应该知道，有时自己想破脑袋的问题，竟然可以在竞品那里很容易地get到方案，更有趣的是从交互、功能逻辑等方面都帮你设计好了，相当于有人帮你做了一套解决方案。
不过作为一名优秀的产品经理，绝对不**是拿来主义者，笔者对这样的做法也很不屑，但作为一种参考，帮助我们更好地去设计自己的需求，这还是没任何问题的。
如果你发现很难去找到类似的竞品时，那我们又该怎么办呢？办法还是有的，我们可以在网络中通过寻找论文、寻找文章的方式，帮助我们从不同的视角去理解、去分析手头的case，最终的目标还是在帮助我们分析功能的价值。
（3）构建PRTD文档
通过与用户的沟通、竞品的调研分析，相信作为优秀产品经理的你，一定已经能很好地构建出自己的实现思路了，甚至可以写好了对应的PRD。但笔者这里要友情提醒一下，如果是偏技术性的需求，如果按照一般功能需求的方式，编写完PRD就去推进的话，很容易出问题。假设这样就能很好地落地，这只能说明这个并不是什么技术性需求，要么就是你们产品开发团队中有顶级产品和架构师。
那我们还要做什么事，才能确保需求的软着陆呢？
笔者认为，产品经理在完成价值分析后，就要跟架构师一同探讨，把你分析的结果毫无保留地传递给架构师和核心开发人员，与他们一起构建功能的设计，并输出PRTD文档，这里面的T就是指技术。
PRTD文档应该包括价值、用例、功能设计、原型设计、架构分析、技术方案等内容。输出后，项目组应该可以根据该文档进行功能开发，一方面可以有效控制技术风险（一般技术性需求**对技术路线有一定影响），另一方面这样完整的输出，可有效避免后续的返工。
或许你**说，那这样就不敏捷了，像瀑布。笔者的经历告诉你，方法是死的，人是活的，李云龙打仗就是虚实结合，不按套路，这样才能有意外收获。我们要的是有效、快速地落地，而不是纠结敏捷不敏捷。
写在最后：
价值维思考模型是笔者多年来一直遵从的思考方案，不光用在具体的产品需求管理，在其他事务的处理上也是屡试不爽。在瞬息万变的商业环境下，只有价值是永恒不变，本文的输出就是从价值维来考虑，让大家以后可以有更多的思考模式，开发出优秀的产品。
本文由 @jiongoogle 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Unsplash ，基于 CC0 协议
