作为产品经理，我应该了解多少？最近一位刚刚成为产品经理的朋友问我。她接手了一个技术产品，研发工程师已经有了产品方向和交付需求。产品开为不同的研发阶段，每个阶段的跨度都很大，并且涉及到一些不确定的情况。 在产品规划研讨会期间，工程师们提到了很多她不熟悉的工具，方法，流程和概念。 我的这位朋友 Lizzie 阅读了很多详细的技术资料，并想知道她究竟真正需要了解多少，作为产品经理，她在团队中的角色应该是怎样的？ 如何最大化产品经理的价值？ 在这种情况下，产品经理很容易觉得自己是个冒牌货。觉得自己没有价值，随时可能被拆穿。这是众所周知的被称为冒名顶替综合症（imposter syndrome），怀疑自己不够好，随时会露出马脚，即使是登月第一人阿姆斯特朗也经历过。
不要害怕问问题保持一点无知的好处在于，能够让你提出问题以及怀疑各种假定的前提，这可以帮助产品经理避开陷阱结论，找到解决方案，给予产品经理充分探索问题的能力，知名产品经理 Dave Wascha 建议尽早养成提出问题的习惯： “你是一个新人，利用好这一点，去提出各种烦人的问题。” 详细了解产品当然是一件好事，保持好奇的心态。 有了经验之后，你就知道什么时候最适合提出问题，什么时候最适合让团队深入细节，同时始终关注产品的目标。 在产品规划会上的关键是让每个人都专注于目标，并明确责任范围。 而不是询问技术细节，提出问题来指导工程师，比如“我们为什么需要这样做？”，“我们能否提供价值？”，“这能使我们实现什么？”，“如果我们有一半的时间，我们是否可以不做？“等等。 提有关组件价值的问题（而不是关于功能），这让你可以帮助你建立产品的整体愿景。你也可以了解到最大的一块价值在哪里。这个时候，如果你觉得需要稍微改变方向或减少第一个交付产品的范围，你可以与团队一起进行5W分析(five-whys)，这不仅可以帮助你解决问题，而且可以让整个团队与你一起协同工作，这样每个人都可以了解原因（如果项目已经在进行中，这一点尤为重要）。 目的是要分析每一个组件，为什么需要它。 然后，对于每一个答案，再问“为什么”，直到你获得根本的动机。 找出最低的、独立的可交付成果。 他们需要按照特定的顺序完成，还是同时进行？ 哪些部分是增量增值（哪些需要一起交付）？ 一旦 Lizzie 的团队把所有事情都分解成不同的价值体系，并确定需要首先解决的问题，那么她的技术主管就会问：“ CTO 是否会觉得满意？”。 每个人都喜欢一个大的戏剧性的表现，但是大爆炸是有风险的。 任何事都可能阻止你完成大爆炸式的产品开发，即使完成了产品它也不能保证它会成功。 需要问的问题是“如果我们发布这个更小的改变的版本，我们将提供价值（或学习到任何有价值的东西）”吗？ 只要你专注于这一点，你就能改进产品，把你的产品推向用户，从中学习，随时随地适应。 不要忘记，这只是第一步，如果未来的优先事项发生变化，团队仍然可以感受到发布了对用户有用的产品。 从马斯洛的需求层次来看产品，可能是有帮助的。专注于最基本的可交付成果对于实现产品愿景至关重要。 一旦你有了这个基础层次的价值，就可以开始在金字塔建立下一层价值。 随着你从核心问题的基本解决方案转变为优化和前沿功能，每层都增加了越来越多的复杂性。 这一切都是从几个简单的问题开始。 |
