价值维思考模型在技术性需求中的应用

真正的产品是满足用户需求的痛点，为用户创造乐趣或节省成本。 这种感觉可以被直接感知或不能被直接感知。

的真正产品是满足用户需求的痛点，为用户创造乐趣或节省成本。 这种感觉可以被直接感知或不能被直接感知。

产品经理是否了解技术？ 具有技术背景的产品经理有更多优势吗？

用于讨论此问题，我相信您可以在各种产品论坛中看到它，并且许多产品经理可能都参与了辩论。 我有技术背景，刚从全栈开发毕业几年，也有技术架构经验，所以对于产品经理了解开发，我认为总比不了解要好，但是在产品团队之前 许多人不了解技术，但是非常好的产品经理。 作者认为，不管您是否了解开发，总会有不知道的新技术或领域，对于产品经理来说，最重要的不是开发功能，而是开发功能。 需求价值，不断挖掘产品最有价值的能力，并服务于用户，这是产品经理的“业务”。 因此，当产品经理满足一些技术性很高的产品要求，并且很难根据他过去的经验来控制它们时，他又如何制定这些要求？

无论是技术要求还是业务要求，对于产品经理来说，当他们获得不知道或没有接触过的产品或模块时，不要惊慌，也不要认为技术要求纯粹是架构师的 业务，与自己无关。 任何技术都为产品服务，是产品价值的输出。

假设我们需要开发系统服务运行状况监视功能，对于许多从事2C产品的学生来说，这是一个非常陌生的领域。 当我们收到这样的要求时，我们可能会暂时不知道该怎么做，甚至直接将要求提交给架构师或研发经理，让他们根据自己的想法来制定，然后慢慢地理解它，并 然后更改它。 如果以这种方式向前推动

，将不可避免地导致最终开发的功能难以使用或浪费大量成本。 我们一直说产品经理应该具有成本意识，因此他们不能容忍以上情况。 本文主要希望所有产品经理都可以根据价值维度的思维模型来对待任何需求??点，无论是业务需求还是技术需求。

如何理解值尺寸？

“真正的产品是要满足用户需求的痛点，为用户创造乐趣或节省成本。这种感觉可以被感知或不被直接感知。”这是作者认可的“产品定义” ，其中所写的感觉实际上就是产品的价值。

在设计任何产品功能时，产品经理必须将价值作为功能设计的驱动力，以使设计的功能“有效”。 同时，对于我们的用户而言，他们在使用产品时首先想到的是产品的价值是否符合他们的实际需求。 因此，在使用产品时，我们的用户下意识地使用了由价值驱动的产品功能。

让我们回到本文的主题。 当产品经理获得技术要求时，它仍然符合上述价值维思维模型。 那么，我们从哪些方面可以把握价值维度，或者很好地处理价值维度，实现需求下降呢？

这个问题，我认为从以下几个方面，我们可以更好地满足价值实现。

（1）听取用户意图

根据值维度思考模型，我们应该找到使用该功能的“用户”以了解用户为何需要此功能以及它可以带来什么功能，尽管在 开始，我们得到了部分技术需求。 如果与用户的沟通有效，则产品经理可以轻松地概述功能价值，甚至您可以找到更有效的方法来帮助研发部门沿着价值维度找到技术实现路径。

将通过概述功能价值来帮助您了解“技术”背后的业务意义。 此时，您会发现还可以从用户角度，业务角度，交互角度分析原始技术要求，甚至可以挖掘出具有商业价值的更多功能点。

（2）竞争产品

的研究和分析除了与用户进行有效沟通外，产品经理还必须记住要找到相应的竞争产品。 经常进行竞争性产品分析的学生应该知道，有时候他们想打破常规，可以轻松地获得竞争性产品的解决方案。 更有趣的是，他们已经为您设计了交互，功能逻辑等方面的解决方案，这相当于有人在帮助您制定解决方案。 作为出色的产品经理，

绝对不是实用主义者，而作者鄙视这种方法，但是作为帮助我们更好地设计自己的需求的参考，没有问题。 如果很难找到类似的竞争产品，我们该怎么办？ 还有一些方法。 通过在Internet上搜索论文和文章，我们可以从不同的角度帮助我们理解和分析当前的案件。 最终目的是帮助我们分析功能的价值。

（3）通过与用户沟通，研究和分析竞争性产品来构建PRTD文档

，我相信您作为一名出色的产品经理，将能够建立自己的实施思路，甚至编写相应的PRD。 但我想提醒您，如果这是技术要求，并且您以常规功能要求的方式编写PRD，则很容易出现问题。 如果这是一次很好的着陆，则仅表明这不是技术要求，或者您的产品开发团队中有顶尖的产品和架构师。

我们还能做什么来确保需求的软着陆？ 作者认为，完成价值分析后，产品经理应与架构师讨论，将您的分析结果毫无保留地传递给架构师和核心开发人员，与他们一起构建功能设计，并输出PRTD文档， 其中t指技术。

prtd文件应包括价值，用例，功能设计，原型设计，体系结构分析，技术方案等。输出后，项目团队应能够根据该文件开发功能。 一方面，它可以有效地控制技术风险（一般技术要求会对技术路线产生一定影响）。 另一方面，这种完整的输出可以有效避免后续的返工。

也许您会说它不像瀑布那样敏捷。 作者的经验告诉您，该方法已死，人们还活着。 李云龙的战争是现实与虚拟的结合，不是按照常规进行的，因此他可以取得意想不到的收益。 我们想要的是有效而迅速地降落，而不是因敏捷而纠结。

写在最后：

价值维度思维模型是作者多年遵循的思维方案。 它不仅用于特定的产品需求管理中，而且还用于其他交易处理中。 在瞬息万变的商业环境中，只有价值是永恒的。 本文的输出来自价值维度，以便将来我们可以拥有更多的思维方式并开发出优质的产品。

本文最初由@ jingoogle发布。 每个人都是产品经理。 未经允许，禁止基于cc0协议重印

题词。