最近一位刚刚成为产品经理的朋友问我。她接手了一个技术产品，研发工程师已经有了产品方向和交付需求。产品开为不同的研发阶段，每个阶段的跨度都很大，并且涉及到一些不确定的情况。

在产品规划研讨会期间，工程师们提到了很多她不熟悉的工具、方法、流程和概念。我的这位朋友 Lizzie 阅读了很多详细的技术资料，并想知道，她究竟真正需要了解多少？作为产品经理，她在团队中的角色应该是怎样的？ 如何最大化产品经理的价值？

在这种情况下，产品经理很容易觉得自己是个冒牌货。觉得自己没有价值，随时可能被拆穿。这是众所周知的被称为「冒名顶替综合症」（imposter syndrome），怀疑自己不够好，随时会露出马脚，即使是登月第一人阿姆斯特朗也经历过。

产品经理不是“全知全能”，要允许自己当“小白”事实上，作为一个产品经理，你不需要什么都知道。你就像是指挥家，不需掌握每种乐器，你的工作是感受音乐的整体感，并帮助音乐家演绎音乐。 然后和他们一起生活和呼吸每一个音符。我认为，无论产品经理有多资深，一个好的标志是，能够正确的面对这种冒名顶替综合症。

二、不要害怕问问题

保持一点无知的好处在于，能够让你提出问题，以及怀疑各种假定的前提。这可以帮助产品经理避开陷阱结论，找到解决方案，给予产品经理充分探索问题的能力，知名产品经理 Dave Wascha 建议尽早养成提出问题的习惯：

“你是一个新人，利用好这一点，去提出各种烦人的问题。”

详细了解产品当然是一件好事，保持好奇的心态。有了经验之后，你就知道什么时候最适合提出问题，什么时候最适合让团队深入细节，同时始终关注产品的目标。

在产品规划会上的关键，是让每个人都专注于目标，并明确责任范围；而不是询问技术细节，提出问题来指导工程师，比如“我们为什么需要这样做？”“我们能否提供价值？”“这能使我们实现什么？”“如果我们有一半的时间，我们是否可以不做？“等等。

提有关组件价值的问题（而不是关于功能），这让你可以帮助你建立产品的整体愿景。你也可以了解到最大的一块价值在哪里。这个时候，如果你觉得需要稍微改变方向，或减少第一个交付产品的范围，你可以与团队一起进行5W分析(five-whys)。这不仅可以帮助你解决问题，而且可以让整个团队与你一起协同工作，这样每个人都可以了解原因（如果项目已经在进行中，这一点尤为重要）。

目的是要分析每一个组件，为什么需要它。然后，对于每一个答案，再问“为什么”，直到你获得根本的动机。找出最低的、独立的可交付成果。他们需要按照特定的顺序完成，还是同时进行？ 哪些部分是增量增值（哪些需要一起交付）？

三、大爆炸有风险

一旦 Lizzie 的团队，把所有事情都分解成不同的价值体系，并确定需要首先解决的问题，那么她的技术主管就会问：“ CTO 是否会觉得满意？”每个人都喜欢一个大的戏剧性的表现，但是大爆炸是有风险的。任何事都可能阻止你完成大爆炸式的产品开发，即使完成了产品它也不能保证它会成功。

需要问的问题是：“如果我们发布这个更小的改变的版本，我们将提供价值（或学习到任何有价值的东西）吗？”只要你专注于这一点，你就能改进产品，把你的产品推向用户，从中学习，随时随地适应。不要忘记，这只是第一步，如果未来的优先事项发生变化，团队仍然可以感受到发布了对用户有用的产品。

从马斯洛的需求层次来看产品，可能是有帮助的。专注于最基本的可交付成果，对于实现产品愿景至关重要。 一旦你有了这个基础层次的价值，就可以开始在金字塔建立下一层价值。 随着你从核心问题的基本解决方案，转变为优化和前沿功能，每层都增加了越来越多的复杂性。

这一切都是从几个简单的问题开始。