真正的产物，是满意用户需求痛点、给用户缔造 *** ，可能本钱节省带来的感觉。这种感觉既可感知，也有大概不行直接感知。

产物司理到底要不要懂技能，是否技能身世的产物司理必然更有优势呢？

对付这个问题的探讨，相信列位都能在各个产物论坛上看到，不少产物司理预计也参加争辩过。笔者本身曾是技能身世，且刚结业时做全栈开拓若干年，也有过技能架构履历，所以对付产物司理要不要懂开拓，笔者认为懂总比不懂的好，不外之前所带过的产物团队中也有不少不怎么懂技能，但却挺优秀的产物司理。

笔者认为，无论是否懂开拓，总会有你不懂的新技能或未打仗过的规模，而对付产物司理而言，最要害的不是把成果开拓出来，而是要把需求代价开拓出来，要把产物最有代价的本领不绝挖掘，处事于用户，才是产物司理的“正事”。

那么，当一个产物司理碰着一些技能性很强的产物需求，而靠本身过往的履历又很难把控的时候，又该怎么将这些需求开拓出来呢？

无论是技能型需求照旧业务型需求，对产物司理而言，在拿到一个本身不懂或未打仗过规模的产物或模块时，先不要慌，也不要认为技能性需求纯粹是架构师们的事，跟本身无关。任何技能都是处事于产物，是为产物代价的输出。

假设我们此刻需要开拓一个系统处事运行康健监控成果，这对付许多一直从事2C产物的同学来说，根基上都是很生疏的规模。当我们拿到这样的需求后，很大概一时间不知道该怎么办，甚至会把这种需求直接踢给架构师，可能研发司理，让他们先按本身的想法做一个出来，然后再逐步领略后改吧改吧。

假如按此 *** 推进，那一定会造成最后开拓出来的成果很难用，可能挥霍许多的本钱。我们一直讲，产物司理要有本钱意识，所以是毫不能容忍上述环境的产生。

本文主要是但愿所有的产物司理都能按代价维的思考模子去看待任何一个需求点，不管是业务型照旧技能型需求。

如何领略代价维呢？

“真正的产物，是满意用户需求痛点、给用户缔造 *** ，可能本钱节省带来的感觉。这种感觉既可感知，也有大概不行直接感知。”这是笔者较量承认的“产物界说”，个中写的感觉，其实就是产物的代价。

产物司理在设计任何产物成果时，必然要以代价作为成果设计的驱动力，这样所设计出来的成果才是“活”的。同时，对付我们的用户而言，利用产物时首先想到的是产物代价到底符不切合本身的真实所需，所以我们的用户在利用产物时，潜意识里也是由代价来驱动对产物成果的利用。

我们再回到本文的主题，对付产物司理拿到技能性需求时，照样切合上面所讲的代价维思考模子。那么我们从哪些方面来掌握住这个代价维，可能说来处理惩罚好这个代价维，并实现需求落地呢？

对这个问题，笔者认为从以下几方面，就可以较量好地去满意代价实现。

（1）凝听用户意图

凭据代价维思考模子，我们应该找到利用该成果的“用户”，去相识阐明用户为什么需要这个，能带来什么本领，尽量一开始我们拿到的是一个偏技能的需求。假如与用户的相同是有效的，那么产物司理就可以从很容易地勾勒出成果代价，甚至你还可以沿着代价维，寻找更有效的辅佐研发找到技能实现路径。

通过对成果代价的勾勒，将很是有助你去相识“技能”背后所埋没的贸易意义，这时候你会发明，本来这么技能性的需求，也可以通过用户视角、业务视角、交互视角去阐明，甚至还可以挖掘出更多具有贸易代价的成果点。

（2）竞品调研阐明

除了去跟你的用户举办有效相同外，产物司理必然要记得去寻找对应的竞品。常常做竞品阐明的同学应该知道，有时本身想破脑壳的问题，竟然可以在竞品哪里很容易地get到方案，更有趣的是从交互、成果逻辑等方面都帮你设计好了，相当于有人帮你做了一套办理方案。

不外作为一名优秀的产物司理，绝对不会是拿来主义者，笔者对这样的做法也很不屑，但作为一种参考，辅佐我们更好地去设计本身的需求，这照旧没任何问题的。

假如你发明很难去找到雷同的竞品时，那我们又该怎么办呢？步伐照旧有的，我们可以在 *** 中通过寻找论文、寻找文章的 *** ，辅佐我们从差异的视角去领略、去阐明手头的case，最终的方针照旧在辅佐我们阐明成果的代价。

（3）构建PRTD文档