最近面试产品经理时最苦恼的就是大多数PM拿画原型当自己的看家本领。绝大多数PM对于原型的使用都是错误的，直接导致无效的团队推动力。造成这个现象的最根本原因是自己本身缺少目标感——不去深思产品成功后应有的模样，而过于追求过程中的自我认可，寻求自嗨。
关于产品原型，你要记住两点真相：
1.产品原型只是产品成功路上的垫脚石，就是要吸引大家来踩，踩过去了团队才能往前走。
2.通过一份文档来解决问题的想法是幼稚的，文档最大的价值是信息沉淀以方便日后回顾。但更多时候是因为大多数人都不愿承担责任，才抬升了它的重要性。
所以你在设计和使用这块“垫脚石”时，一定要首先注意：
1. 当前团队处于什么阶段?目标是什么？接收对象是谁？
2. 不要拿产品原型或文档去说事儿，要开放，要就事儿论事儿!
3. 千万不要爱上自己的原型和文档，你爱的是用户，而且要让团队知道。
分享一下我作为产品新人时自己的一些技巧吧。应该是十年前的样子，我第一次加入到一个人数不多的互联创业团队中。没有人告诉我产品原型和文档应该怎么写，在实际的推进中我产生了这几方面的困惑：
1.不知道要写多细。到现在都清晰记得我问身边的技术大牛要不要标清字号时他甩来到白眼。
2.无法用一份原型来统一回答技术与设计伙伴的问题。比如Axure很适合做页面逻辑的表达，但无法表达出数据以及接口结构。现在很多原型工具也有这个问题，虽然能让你低成本拿到demo，但无法对数据结构进行讨论，影响PM对于成本以及未来可能性的把控。
3.总会有人产生疑问。会上定会下改，今天定明天改。
那是一个黑暗的时期，不仅工作量大还非常没有效率——所有的改动都好像很急很重要，但并没有对产品最终的效果起到明显的推进作用。感觉自己就像一个整天到处救火队的消防员，成天被点火的人愚弄。那时真的很讨厌那些点火的人，可又不知道这些人是谁。是同事？老板？难道在可以刁难我？但我们私下还真的挺开心的。而且大家还给了我很多建议，最多的一句就是“再多想想”。
当时我有一个习惯，就是回复完所有当天邮箱里的产品反馈再下班。记得有天晚上，公司剩我一个人，很疲惫地看着反馈列表时，发现了一条夸我们产品好用的评价。我不知道那条评价被我反复看了多少遍，一个原因是确实激动，另一个原因是用户并没有写出到底是哪个功能做的好，他只说目前只有我们能够帮助他随时找到身边的商家。我突然明白了眼下最重要的事情是什么——回复邮件表示感谢之后，继续问他还有什么不方便之处。
那晚上，我的脑海里出现了一幅图：左边是一个用户，右边是他想要的苹果，中间是一个迷宫。我要最快地带他走出迷宫，拿到他渴望的那个苹果。
我突然发现之前我的做法都是错的。我把团队伙伴和老板当成了我的服务目标——他们本应是站在我身边一同为用户服务的人。我们如何才能一起行动呢？其实很简单，我们要一起面对用户的问题。换句话说，我们面对的问题必须是来自用户的。
后来我主动找公司进行如下改动——
1. 搭建redmine, 建立用户问题库（现在的工具很多，推荐confluence）
2. 仅针对问题进行讨论。如果建议来自同事或老板，我也当做用户一样对待。
3. 针对每个问题进行原型提案，大家直接抛砖，甚至工程师也可以一起提原型。
4. 最终由我来主持会议确定优先级，并按顺序打包成版本计划——路线图出来了！
这个带来的直接效果是，团队与我站在同一战壕，都对如何更高效地解决问题产生兴趣。除此之外还有几个非常棒的效果：
1.我不用再写繁冗的产品文档，仅根据问题进行提案，组织讨论。
2.我开始使用手绘来表达原型，因为足够了，更多的细节设计师会跟进。或者他的主意更好。
3.团队非常清楚眼下的重点，知道要做什么，大家关系更加融洽了。
我终于品尝到了作为一名产品经理的成就和愉悦感。在多年之后，我才从《每个伟大的产品背后》这篇文章中再次确认产品经理无授权管理的深意：
1.不要追求成为团队最厉害的人，要做最会发现问题的人。
2.不要在意文档的质量，要关注团队使用文档的动机。
3.产品经理是管理岗，要让团队中的专业成员得到参与感，并发挥长处。
确实，完美的文档并不存在！从此之后，我永远只是最快抛砖的人。抛得越快，团队跑得越快！
