产品经理被技术总监反咬一口？我教你个办法.pdf

产品经理被技术总监反咬一口？我教你个办法 知乎上有个问题是这样的 ： 产品人员如何处理被技术总监反咬一口 ？ 产品 员将调研分析竞品对比参考方案A和B ，发邮件给项目经理研发总监 ，两日无回复 ， 面谈讨论被以实现难度大目前 手不足为由拒绝 ，遂止于此 ，一个月后被技术总监反咬一口 ，说产品不重视此重要需求 ，并拿出A和B方案指责产品 ，我们技术都想到了 ，产品 员想 不到。 没想到关于 『要养成记录的好习惯』 ，还有这么活生生的好例子。 每次跟产品新 说完主要的几条建议之后 ，我都会强行加一条 『千万千万记得 ，不管什么都要养成 记录的好习惯 ，以防扯皮』。 乔布斯说过 ，关于因为无法溯源导致的撕逼和扯皮 ，被称为产品经理的七大噩梦之一。 产品经理学会写东西、记录事情 ，不仅仅指的是需求文档 ，而是更多在沟通过程中、在各种想法中 抽离出的供未来使用的东西。 记录这些东西有很多注意事项 ，我们一条一条说。 1. 记录的事情不分大小 沟通的形式很多样 ，开会算是沟通 ，吃午饭时随口跟工程师提了一句也是沟通。但不管怎样的沟通 ，一定一定要记录。 原来的故事可能是 ： 在电梯里碰到工程师小明 ，说老板提到有个文案要改掉 ，小明说好嘞简单得很 ，然后你就没 再放心上。 过了几个月 ，老板又跟你发火 ，说看到文案没改 ，你找到小明 ，小明说 ：啊 ？你说过这事儿 ？ 老板说你办事不力扣了你半个月奖金。 改正后的故事是 ： 在电梯里碰到工程师小明 ，说老板提到有个文案要改掉 ，小明说好嘞简单得很 ，然后你就没 再放心上。 你下午回到工位 ，发了一封邮件给小明 ，抄送他的上司 ，以及老板。邮件就几句话 ，说明了 改文案的情况。 过了几个月 ，老板又跟你发火 ，说看到文案没改 ，你找到小明 ，小明说 ：啊 ？你说过这事儿 ？ 你翻出邮件来 ，白屏黑字 ，小明没得狡辩。老板扣了他半个月奖金。 2. 记录的内容要翔实可信 如果本来讨论清楚的事情 ，因为记录时随手敷衍 ，同样是没有意义的。 比如记成 『下午会议大家达成一致 ，按照老张的说法做』 ，等半个月后 ，大家都忘了老张的意见时 ，那老张就真的是说什么就是什么了 ，指当时的鹿为现在的马也没关系。 一件事情 ，不要因为追求速度就说不清楚 ，也没必要写成格式化文档 ，只需要确定 ，当你不了解当 时的任何信息时 ，还能通过你的记录得到有价值的信息 ，这样就行了。 3. 根据记录的种类做记录的格式 ，防止缺漏 有时候 ，想到的未必就是够全面的 ，所以我习惯把记录的信息进行分类 ，格式化记录。 记录有这么几种 ： 工作任务事项 ，包括翔实的工作内容、负责 和时间节点 ，比如刚才说的修改 ，『小明会在下个 版本 （3.6.2 ）修改页面的 XXX 文案 ，改成 XXX 文案』 ； 事情的记录 ，包括发生的具体场景、情况和结论 ，比如 『老张说目前数据结构的状态不适合完成 方案 XXXX ，因为会导致 XXX 的错误 ，所以暂时停止』 ； 意见 ，包括谁表达了什么观点 ，认可还是否决 ，比如 『老张说目前数据结构的状态不适合完成 方案 XXXX ，因为 手不足 ，所以暂时停止 ，但老板表示去你妈的赶快给我实现 ，最后结论是老张 配合 HR 尽快招 』 ； 备 录 ，包括各种头脑风暴的想法 ，使用各种 A PP 的体验等等。这些是对自己很有帮助的。之 前我接触的优秀的产品经理 ，都会有自己的点子备忘录 ，经常记录 ，也经常翻出来整理 ，有时候会 有奇效。 最近我让我们团队的实习生小伙子做会议记录 ，他处理得很好 ，供大家参考 ： Dear all ， 这是今天的会议记录 ，如果发现内容有遗漏 ，请及时联系我。 地点 ：旧金山 时间 ：16:30 Q 1 ，地图导航问题。 A 1 ，地图展示模式 分两种模式 ：热力图引导和订单位置 （包括导航 ）。修改接单区域放入 【地图】中 ，【+】、 【- 】号按钮默认隐藏 ，新增 【设置】按钮 ，点击显现出原有隐藏的 【+】 【- 】按钮。 地图导航 ，在小旗上显示数字 （按照接单顺序 ），点击小旗显示 【开始导航】。导航直接引 用高德地图。 负责 ：Z L 截止时间 ：下个版本前 Q2 ，需求问题。 A 2 ，去掉 PBS 的限制 区域半径的限制 Q C0.5- 1.5 Q S1.5 负责 ：