编者按：用户在表达对某个新功能的需求时，他们的建议很容易被忽视或者被搁置在一边。Phil Freo 在本文中介绍了能更好地捕捉客户需求的方法。
典型的方式真的管用吗？
最常用的记录功能需求方式非常简单：“john@example.com需要功能A… [@产品和研发团队相关人员名单]”。
假设我们确实要开发A功能，上述做法提供了需要给到通知的人员列表，但这种操作既不能给研发有用的帮助又不能切实满足用户的需求。原因在于：
不同的人对这个功能的具体概念可能有不同的理解。
功能有多种不同的实现方式，上述方式并不能说明哪种方式最好。
可能存在一种不同的、更好的方式可以满足用户的基本需求。
以这种简单的格式记录即便通知到了相关人员，但并没有很好地给到他们的核心要点。
仅用邮箱地址来记录功能请求肯定要比不留任何用户信息要好，至少这样我们在后期可以联系到更多人。高度概括的通知也看似给我们提供了一个投票系统，以便我们围绕产品功能做出优先考虑。但实际上这个系统并没有足够的细节，未必能使多数人受益。
更好的方法
功能请求的记录格式应该包含更多细节信息。例如：
用户是谁？他/她所在的公司是什么？该用户在公司内扮演什么角色？
用户在什么情况下想要使用这个功能？ （什么时候开始有想法？）
用他/她自己的话来说，“功能A”的定义是怎么样的？
具体来说，他们将如何使用此功能？
增加此功能之后，他们希望实现怎样的业务价值？
简言之，多问几个“为什么？”，然后让用户用他自己的话，尽可能详细地表达想法。
“用户自己的话”是非常重要的，因为我们很容易依据自己的思考先入为主的定义用户的想法，反而无法理解他们的目标和期望。
“用户的话”有什么作用
在基于需求的产品开发过程中，当我们试图验证某个产品建议是否有向前推进的意义时，简明而详细的用例有助于指导我们看清楚问题。它们可以回答“是否真的存在足够重要的一致用例模式？”、“关于解决方案的具体构想是否最优？”的问题。
在记录功能请求时，假定在缺省情况下，存在一系列具体使用案例，而且这些案例能说明为什么该功能对于客户很重要以及他们将如何使用该功能时，该功能才能进行开发。
从产品开发的角度来看，重要的是挖掘潜在的需求，而不是强调用户的想法或强调特定功能的实现。
设计决策
很多时候我们可能看到了某个状况下的明确需求，或者用户针对特定功能的提出了大量请求，然而还有另一个因素需要重视，那就是该功能怎么发货作用。
通常情况下，一个功能可以以多种不同的方式运行，但是如果不能准确理解用户想要实现的效果，就很难确定哪种方式更好。
而深入UI / UX或技术设计环节的话，大多数表面上看起来清晰明了的功能可能会朝不同的方向发展。 忠于用户反馈的核心使用案例可以帮助我们快速且更确信地选择一个方向。
谁来完成
产品团队负责完善客户使用案例并与客户沟通解决方案。
然而，任何与客户接触的人都有独特价值的，沟通的过程中可发现很多客户的遇到的问题和功能请求。 如果这些带有使用场景的功能请求被记录下来，可以很大程度推动产品走向正确的方向。 我们总说公司要尊重用户的想法，这就是最好的方法。
