产品本身自带很多属性，一个好的产品需要通过层层属性筛选，在这里我们主要介绍三个属性：

可消费属性

在要求客户部署一个发行版并提供反馈之前，开发团队应该知道一些问题的答案:“安装有多容易?配置呢?系统的使用有多直观?新发行版上线后，运营团队会接到多少凌晨3点的支持请求电话?支持有多容易?查找问题呢?系统需要多长时间才能交付价值?”

这常不是开发团队能够回答的问题，但重要的是要找出答案。我们曾讨论过如何利用族群研究方法来获得有用的反馈信息。你要寻找的第一类反馈信息就是“产品的可消费性如何?”下一步就是让它具有足够的可消费性，让你的客户愿意接受频繁发布的产品，并且有兴趣帮助你，提供更多的反馈。

新的发版可能不是为所有人服务的，所以最好不要同时向所有客户推行一个版本，要发布给最渴望新发行版的客户。为了使你的长期支持成本最小化，要在客户需要支持或新特征时，鼓励他们取得最新的发行版，这样你就不必因为需要支持多个发行版而忙不过来。

缺陷属性

你多么努力，总会有一些缺陷进入到生产环境中。理想情况下，这是小概率事件。如果发生这种情况，缺陷可能是很隐蔽的问题，导致其他系统中发生奇怪的事情，而你在开发的时候不知道。因为在开发和生产环境之间存在巨大的安全屏障，你不太可能听到这些缺陷的许多细节，更不必说追踪它们并发现问题的根源。当然，并非所有的运营问题都是因为软件而导致的，但许多问题确实是软件导致的。当问题存在时，开发团队应该非常关心，弄清楚它的设计和测试实践如何导致了这个缺陷，但并没有检查出来。根据我们的经验，这种反馈通常不会追究，一般也不受欢迎。这是错误的。防止将来缺陷遗漏的唯一方法就是检查目前发生的缺陷，从方法上找到它的根源，然后一个一个地消除掉。

客户属性

在开团队看到他们的工作对客户的成果产生的影响之前，这个循环还没有结束。新的业务过程花了多少天取代老的订单实现过程?新的产品卖得如何?新的支付系统是否满足PCI标准?因为新发行版中的特征，多签了多少客户?如此等等。如果开发的目标是驱动这些测量指标，决定的制定是基于对这些指标的贡献，那么结果就必须可见，这样团队才能知道他们的决定的结果。

通常的反应是:“于你的客户成果测量指标的建议，我们没有太当回事。很难决定这些测量指标应该是什么，我们的客户不希望被锁定，而且，这些测量指标时效性差。同时，我们不希望让开发团队对他们不能控制的事情负责。所以我们将这类决定留给产品拥有者。”

这是错误的回答。样的借口意味着那些非常聪明的开发者只能做一些吩咐下来的事情，而不是要求他们去创造性地解决真实问题。开发人员不应该对他们不能控制的事情负责，这种想法注定了(字里行间表明)系统的失败。因为如果系统成功，开发人员也没有功劳。如果开发者不知道他们的工作是否最终获得成功，他们就不能学习如何改进，而且可能不再关心。如果你想知道为什么你们最好的人才在白天毫无激情，而在晚上却爱好开发开源项目，那么答案很简单，因为开源项目提供了持续的、有用的反馈，也因他们的长期工作而提供了荣誉。反馈帮助他们变得更好，荣誉让他们保持对工作的热情。