在PM世界中，生活总是很有趣。 有时候，成为下一任超人就像一生的学徒。 当然超人没有缺点。 另一方面，我们凡人有很多偏见和沟通失误要提防。 这是我经历过的一些。
生存偏见：您或某个利益相关者常常如此急切地相信解决方案的优点，甚至迫切希望解决此特定问题，这是前进的道路，您可以完全排除许多无法解决问题的原因。 这种特殊的偏差很难用数据消除，因为它会使您过度关注成功的数据点，而不是所有负面数据。 不管您是否继续执行此解决方案，失败的案例都不应该对您不可见。 使用它们来设计故障安全解决方案，或在其中插入图钉，以便日后与您的工程师重新访问。
在逻辑的基础上讨论某个功能失效：换句话说，假设您的客户在使用产品时会逻辑思考，则尝试设计功能。 如果这是真的，那么我们的用户流量将更长。 告诉我，您是否想在iTunes或Spotify上搜索曲目，然后寻找控件并按“播放”按钮？ 还是您想轻按轨道上的曲目进行播放？ 尽管前者是更合乎逻辑的方法，但如果我们想创造大量客户满意的东西，我们经常需要创新。
接受不低于100％的完美解决方案：产品经理致力于确定要解决的最大用户问题或即将完成的工作。 但是，当范围界定和模型制作完成并且您正在努力从利益相关者那里购买时，该提案可能会被拒绝，因为它错过了一个（或两个）用例。 看它发生了。 项目的时间紧迫，有很多人需要及时了解，每个人都有自己的见解-仅是他们想在您的功能中加入的一件事，还是他们认为您忽略了的另一项指标。 但是，如果您完成了家庭作业，那么您已经知道要解决的最大问题。 这是在KPI上移动最多的针头。 其他一切都是肉汁。
关注解决方案而不是问题：对此有不同的意见。 我的地雷绝对没有混在一起。 作为产品经理，您最重要的工作是定义和确定问题的范围。 这是工程师能够正确完成工作的一件事。 我了解到，这比看起来要难得多。 也许这就是为什么早期职业经理人（包括我本人）或那些从工程学潜水员转而首先进入解决方案模式的原因。 这就像看着慢动作中的车祸。 您可能会认为这样做可以帮助加快工程团队的工作速度。 很多时候，它不会，并且会花一些时间来处理只有您才能完成的更重要的任务。 我的工程经理曾经告诉我
我们（工程师）对系统非常熟悉，我们可以睁开双眼，并直观地看到结合在一起的体系结构和解决方案。 但是，当我们没有从产品经理那里得到适当的用例时，我们就觉得我们必须求助于治疗师，迫使他们揭露他们真正的问题所在。 那不是我们签约的目的。
因此，也许下次您想选择使用支撑杆的决定时，除非有确定的理由，否则不要这样做。
拒绝一个好主意，因为技术实施需要一些好的技巧：该技巧与第3点类似，不同之处在于它更可能来自您的工程或设计团队。 可以理解，他们担心技术债务。 为了赶上上市的最后期限或尽快获得反馈，花太多时间开发完美的解决方案并不总是明智的。 当然这是相对的，并且在很大程度上取决于您要构建的产品类型，开发节奏和规模。 例如，如果我正在开发针对数百万用户的平台产品，并且急忙更改，那么我可能会更多地关注能够处理高负载/响应率低于xx ms / had的正确解决方案正确的用户流等，而不是加快上市速度。 但是，如果这是测试用户对签约个性化导游的兴趣的功能，那么可能就不对了，因为我的目的是评估兴趣并收集反馈。 通常，可以通过向工程/设计团队提前解释目的和范围，并使他们团结在您要完成的目标之后，来解决此问题。 我知道，我只是说这是最简单的事情！ 但是，您猜怎么着，这比在发布前两天和您的工程团队停止所有工作之前进行辩论要好。
产品会议停滞不前，因为它与利益相关者的优先事项相冲突：您想为客户建立“价格比较”功能，但是您需要其他团队的帮助，他们更加专注于为用户重建结帐体验。 您想建立一个聊天功能，但是法律和金融部门说他们对您更感兴趣，以找出该公司为什么要增加收购成本并获得C级支持。 在第一个示例中，这两个任务可能同等重要，但没有优先级。 第二个例子是公司层面的战略没有正确传达给团队的情况。
您还经历了哪些其他的事？
