有关产品经理工作的许多文章和书籍都考虑了战略思考和创新问题。 当然，这是基础。 我喜欢注意日常工作。 其中一项工作是处理用户请求和产品要求。
公理是，用户对功能的要求不是产品要求。 一个请求可以轻松地划分为多个需求，反之亦然，一个需求包含来自用户的多个请求。
让我们看一个简单的示例-计算器应用程序。 您已收到一个请求：添加对二进制数字系统的支持。 它会引起几种产品要求。
- 支持算术运算。
- 转换支持。 顺便说一句，这将影响现有的十进制系统。 至少需要在界面上进行按钮。
- 支持逻辑运算。
如您所见，最初，用户并没有要求仅支持逻辑操作。 整个数字系统的要求，但其中包含一些要求。
也许这一切都是显而易见的。 但是，如果您不重视请求的处理过程，则会增加问题。 第一个陷阱是将记录保存在跟踪器中。
显然，拥有一个用于满足用户要求和产品要求的系统要好于两个。 好吧，至少您只会打开一个窗口。 重要的是要有不同类型的记录对象。 以我的经验为例。 每个工作日，我平均收到两个到四个用户请求。 您可以想象音量。 产品待办事项列表中的列表非常庞大。 拥有两种类型的条目“ requirement”和“ request for功能”使您可以配置过滤器，收集特定版本的待办事项以及在需求和请求之间建立链接以跟踪历史记录。 此外，在考虑了请求之后，可以用“计划发布”或“将不执行”注释将其关闭。
工作的第二个方面是直接收集需求。 一种方法是让他们获得技术支持。 这是一个很好的过程，因此，您将获得包含基本内容的筛选请求。 另一方面，它对您的用户是不透明的。 许多人可能看不到这样的请求，因此被反复访问。
因此，供应商，尤其是那些提供云解决方案的供应商，可以使用门户来接收反馈。
Zendesk反馈论坛此方法提高了可见性。 由于系统不同，因此将请求与需求分开。 但是，现在您的工作增加了一倍。 您需要快速查看新帖子，发表评论，回答问题。 沉默，特别是在公共传播中，是不能接受的。
但是最困难的是，现在您必须以某种方式跟踪和标记请求，以标记计划实施的请求，反之亦然。 回到计算器示例。 与在门户网站上一样，如果您打算仅实现算术运算和转换而没有逻辑运算，则需要标记对二进制支持的请求。
每个产品经理都选择自己的解决方案。 没有通用的方法。 但是，您应该始终记住，即使是一个很小的过程，例如收集和处理来自用户的请求，也可能包含许多隐藏的主题，并且很容易使工作加倍。