您总是可以指望产品经理的战略技能，例如创新思维，蓝海方法等。 但是每天我们都会使用更多实用的工具和方法。 本文是关于使用功能请求和产品要求的。
管理请求的主要原则是来自客户，合作伙伴和内部团队的功能请求不是产品的要求。 这是因为每个请求都可以拆分为多个需求，否则，可以将多个请求组合为一个需求。
让我们使用一个示例-计算器应用程序。 您已收到将二进制数值系统添加到应用程序的请求。 此特定功能提出了以下主题，每个主题都可以转换为需求。
- 支持算术运算。
- 支持从/到的转换。 这将影响十进制系统的功能。 例如，您需要支持从十进制转换。
- 支持逻辑运算。
如果没有这样的系统支持，您会看到没人要求对二进制进行逻辑运算。 特征请求是关于特定的数值系统的，但是它具有一些基本要求。
也许这是如此明显。 隐藏了两个陷阱。 首先是在跟踪器中管理功能请求和产品要求。
绝对有一个用于跟踪和规划的单一系统要好于拥有两个。 至少您只需要打开一个选项卡或应用程序窗口。 请考虑使用单独的记录类型来管理请求和需求，而不要使用单个记录。 以我的经验为例。 每个工作日，我都会收到支持团队提交的两到四个新功能请求。 您可以轻松想象记录的许多项目。 产品的项目列表看起来很长。 具有“需求”记录类型和“功能请求”使审核和计划变得更加容易。 如果几个请求是单个需求的起源，那么我将创建一个参考链接。 在查看后，我可以使用“已计划”或“已拒绝”标签关闭功能请求
第二个陷阱可能是请求收集。 一种方法是通过支持渠道获取它们。 当您收到经过过滤和清理的物品时，这是一种不错的方法。 另一方面，这对于您的客户而言不是可见的过程。
因此，供应商（尤其是云软件供应商）可能会使用门户来获取反馈。
Zendesk反馈门户这种方法增加了可见性，将请求与需求分开。 现在，您的工作增加了一倍。 您需要快速对其进行评论和评论-客户不喜欢沉默，而您是在公开交流。
最糟糕的是跟踪和标记列表中的项目是否按计划完成，而不是按计划完成。 请记住，功能要求不是您必须牢记依赖关系的要求。 回到在计算器应用程序中支持二进制的情况。 如果仅实现算术和转换而没有逻辑运算，则应如何在公共门户中跟踪此请求。
每个产品经理都选择自己的解决方案，没有通用的方法。 但是，我们应该永远记住，许多重要的细节可能隐藏在一个简单的主题中。