1.自行为产品挑选技术
可能会有很大的诱惑力来挑选和设置技术 - 语言，框架，库，工具 - 用于自己构建产品。
也许你有一些以前的产品构建经验。也许你最近听说过一些趋势技术。也许已经有一些用特定技术编写的产品代码，并且不想浪费它。
动机可以是不同的，但应该考虑许多其他事情，例如正在解决/解决的问题/痛苦，产品的功能，开发人员的经验，截止日期和预期的开发速度等。
在最简单的情况下，可能不了解最适合您项目的替代工具。
一句话：在选择构建产品的最佳技术时，请咨询开发人员并考虑您的业务目标和限制。
2.尝试为整个项目设置固定的最终价格
从一开始就知道您最终需要为开发团队支付多少费用来构建想要的产品总是更加舒适。
遗憾的是，只有在您作为产品所有者知道并且能够提供产品实施的所有详细信息（例如其设计特性和功能实施路线图）的极少数情况下，才有可能实现这一点。甚至对初始路线图的一些更新也是不可避免的，因此也需要明智的变更管理方法。
在大多数其他情况下，最佳合作模式似乎是时间和材料（当您支付开发人员花在您产品上的时间）和专用开发团队（当您以月费聘请团队专家时）。
一句话：由于市场的不确定性，任何预算假设都将成为大概数字。
3.对业务优先级的错误理解
每种产品都能解决特定的任务。有时候，CEO们想要的产品能够解决与他们打算解决的任务不同的任务。提供的功能无法帮助用户实现所需的目标，应重新定义整个方法。
例如，有时用户最好不使用移动应用，而是使用具有强大后端的移动网站。
想要首先解决的问题的理解基于您的业务优先级。为了确保它们是正确的，请检查是否完全了解独特价值，目标受众和预期收入流。
例如，货币化模型对于了解哪些功能具有最大的商业价值至关重要，因此首先需要我们的关注。目标受众还将帮助我们设计他们认为最适合使用的产品。
底线：揭示业务目标，而不是指示实现细节。
4.开发人员立即开始处理项目
许多产品在构建之前需要从开发方面进行研究。类似产品已经做出了哪些设计决策？为什么？您的开发人员可以使用哪些工具和开发技术来加速产品发布？在当前限制下解决设定目标的最佳方法是什么？等等。
问题是我们的许多客户认为这样的研究是免费的。虽然我们确实免费进行初始工作量估算，但进一步的功能分析和研究是一项付费功能，包含在合作伙伴关系的第一个发现阶段。
除此之外，有时一个优秀的团队可能没有最适合您的产品的开发人员。大多数顶尖公司都会在几周甚至几个月内将他们的专家分配给他们的下一个项目，所以不要指望一周内首次使用原型。
底线：考虑研究和建立团队所需的时间。
5.微观管理项目
有时您可能有充分的理由决定您将管理产品开发过程，了解并解决任何问题并做出所有必要的决定。
这种方法的问题在于您的假设可能仍然存在问题，因为您永远不会知道您的决策可能产生的所有后果，例如，最终用户在发布后对您的应用程序的反应。但是一旦出现任何问题，很容易确定其所犯的开发人员（或者没有及时发出警告的项目经理）。
当我们看到产品所有者的意见可能过于偏颇或没有根据时，我们通常会谈论它，看看我们是否能够做出更明智的决定。否则，我们被迫遵循他们所说的，但显然，这不是构建成功产品的最佳方式。
完美的情况是开发过程由开发团队的项目经理领导。我们希望，如果客户选择我们，他们相信我们的专业知识，依靠我们的建议和决策，而不需要管理开发过程。
底线：相信团队的专业知识（如果有足够的理由）。
6.从一开始就期待质量保证估算
在整个预期功能准备好之前，在所有屏幕的最终数量和可能的转换已知之前，不可能理解将会有多少测试场景以及执行它们需要多长时间。
这就是为什么开发团队通常只估计开发工作和丢弃测试工作的原因。
在极少数情况下，您可以为开发人员提供需要实施的所有必要功能的完整文档，从而可以开始进行质量保证评估。从我们的实践来看，只有大型项目的记录足以评估测试工作。
在测试阶段估计测试工作。测试会话是在单个设备上运行所有可能的测试用例的过程。创建此类案例列表也是一种付费服务，它还需要已知的应用程序结构和设计。
不幸的是，客户很少考虑它，甚至更多，很少在开始时询问测试。相反，他们认为测试是开发工作的一部分，当他们发现自己的方法是产品创建阶段时，会感到惊讶。
还有一个常见的假设是可以开发一个没有错误的应用程序。它不能。并且避免任何测试都会使您的应用无法获得数百万观众的成功机会。
是的，开发人员使用各种方法来避免测试驱动设计等错误，但是他们只测试应该以预期方式工作的功能，以及QA专家分析然后检查的数百个其他可能的用户场景。
底线：测试与开发分离，只有在产品的第一个版本完成后才能进行估算和执行。
7.不承诺产品开发过程足以满足最后期限
有效产品开发的一个重要方面是产品所有者和开发团队之间的沟通。您花在做出必要决定（或批准开发人员的决定）上的时间越多，截止日期推迟的可能性就越大。
在许多情况下，决策过程需要太长时间，因为客户的公司有一些决策者。当少数人批准新的功能，方法或设计决策时，这种讨论通常是痛苦的; 它们需要大量时间，从而减慢了开发速度。
部分地，通过允许项目经理做出一些（例如，技术）决策可以解决问题，但在大多数情况下，最好的策略是简单地快速做出决策并尽快传达它们以帮助团队继续前进。
底线：确定项目的有效决策方法。
或许不会知道所有这些陷阱，解决这些陷阱可能需要您的额外努力。通常，首席执行官们太忙了，而且大多数开发团队都认为最好的方法是当他们指派一个专注，充分和负责任的代表时，他们将成为他们和开发团队之间始终可用的调解员。
温馨提示：答案为网友推荐，仅供参考