这篇文章我翻译于17年5月12日，但是在工作中，我还是常常会把它再读一遍，每次总有新的收获，对手头在做的一些项目起到指导意义。后来，我索性把它的链接加入到了公司wiki的PRD的默认模版中，让团队中每位产品经理写下PRD前都看一遍。
最近公司内部发起了一个产品社团，有幸加入其中，作为成员任务的一部分，我们决定翻译一些外网优质的内容。从此自己的英文技能点也不再局限于给开关命名（诸如：login_switch），算是一大幸事。
本篇原名“Building Products”由Julie Zhuo（Product design VP @ Facebook）撰写于Meduim，主要根据她的工作经验，从“筹备阶段、执行阶段、衡量成果、团队建设”四个角度，总结了一些她认为行之有效的产品设计原则。
我读后，觉得有的和我过往的经验很契合，有的有助于目前我遇到的一些问题。希望也可以给各位带来一些收获。
有一定英文基础的同学，建议直接在Medium上搜Julie Zhuo。
点击查看原文
最近，我参与了一场TNW Europe的访谈，探讨我们在Facebook应用的产品设计方法论。参与这次访谈，让我回想起以往在打造成功产品时所沉淀下的经验。
以下这份产品设计check list，既不完整，也不绝对。如果世上能有一份完美的指引手册（第一步：获取灵感；第二步：？？？；第三步：赚钱了！），那我们早可以花钱把它买下，然后一边拍着同伴的背，一边看着神奇新颖的产品如雨后春笋般冒出。
这里列出的仅仅是很小的一部分经验，我们需要更多的探索和学习。
筹备阶段
1. 一个产品能成功，是因为它为人们解决了一个问题。这听起来非常基础，但这是理解设计优秀产品唯一最重要的事情。
2. 设计新产品的第一步是去理解：你为谁，解决什么问题。这一点，在你开始着手设计任何方案前，必须非常清晰。
3. 你问自己的第二个问题，应该是：“为什么这个特殊的问题值得被解决？”。
4. 如果你的目标用户群体的定义是非常窄的，那么你可以尝试依靠自己的直觉去引导产品设计决策。如果不是，那么你需要依赖调查和数据来支撑你的决策；
5. 如果你是0到1创建一个产品，把目标用户群定位得更加狭窄，会让你的路走得更顺一些。等产品吸引到一些注意之后，再尝试扩大你的目标用户群体。
6. 你解决的问题，应该很容易用一两句话解释给你的目标用户。如果不能做到，预示着一盏大红灯亮起。
执行阶段
7. 好的执行的定义：在最短的时间里得到最可信的结论。
8. 坏的执行的定义：尝试某件事情，失败了，但是：a)从失败的结果里无法得出经验教训（因为你不清楚到底为什么失败了）或者b）它耗费了你一年的时间，但其实有一条更聪明的办法可以在三个月内解决。
9. 辨别团队是否成功，并不是它们做的事情是否失败了，而是他们在多大程度上能持续地保持好的执行力。
10. 当你尝试解决一个问题时，先发散，再聚焦。在作出决定前，先头脑风暴10个、20个、50个方案。前5个方案，会是比较明显的能想到的。创造力开始在第11个、第20个或第50个方案。
11. 如果你在演示一个方案的时候，别人问到：“你有想过X方案吗？”，如果你的答案是“没有”，意味着你的对解决方案的探索远远不够。
12. 使用实证分析方法（empirical evidence）帮助你缩减头脑风暴得出的方案。（例如，选择前N个大家认为最好的方案，做出高保真的原型，放在用户面前看实际效果）。
13. 一旦你决定了你想执行下去的方案，把它表达成一种预期：如果你真的把它做出来了，预期会发生什么结果？（比如：我希望解决的问题是确保每个居民都能知道本地的周末活动信息。我们的预期是：通过邮件列表，可以触达X%的居民。）
14. 你应该持续寻找方法来检验你的假设。你可以尝试在街上随便问一个人，看你的方案是否能被理解。你可以尝试做一份调查，看是否有足够的人对你的想法感兴趣。你可以创建一个并非尽善尽美的原型，尝试快速得到一个明确的结论。
15. 一旦你的方案上线后获得一些积极的信号，不要想着需要马上铺开全量（扩大用户范围）。做方案优化时，全量铺开的标准需要不断调整。测试和全量的检验标准应该有所不同。
16. 如果你的项目范围非常大，涉及到非常多的改动，尝试是否能把它拆解成更小的、可独立测试的里程碑。不要陷入这种陷阱：改了5个地方，得到不好的结果，却不知道哪一个改动出了问题。
17. 每个项目结束后，不管成功与否，都做一个组内回顾。从这个项目你个人学习到了什么？团队学习到什么？将来你会做出什么改变？然后把这样的经验分享给全公司。
衡量成功
18. 你如何衡量成功对团队的长期产出非常重要，因为这是大家关注的核心。要确保给这件事情足够的时间和关注。（甚至，大于你在思考解决方案的时间）。
19. 你需要在产品发布前，定义成功。否则，如果在产品发布后，你试图从结果进行解释，证实性偏见（confirmation bias）会造成不客观的解读。
20. 使用“魔法球方法“帮助你找到衡量成功的正确方式：问自己“如果我能知道任何人使用我的产品，我希望听到什么”，来告诉我我的产品是否成功？”（通常你获得的回答不会是“某个按钮的点击率”，而是更为抽象的，比如“多少人通过使用我的产品，从中获益”）。然后，从你获得的答案，反过来想你可衡量的成功矩阵应该是怎样的。
21. 你的目标应永远建立在最新的有效信息之上。如果你在朝着一个早已定义好的目标前进，途中获取了一些改变你想法的新的信息，你应该考虑是否根据这些信息来调整你的目标。
22. 如果你发现你的团队无法理解或认同衡量团队成功的方式，你应该点出这个问题。更早地暴露这种问题，可以从根本上提高效率和创造好的成果。
23. 如果你发现自己经常跟团队对于产品方向产生争论，根源的问题很可能是各自认为的理解衡量成功的方式不同。你可以尝试提出建议以其他的方式来衡量团队的成功。
24. 如果你想弄明白你的产品是否符合市场需求，最好留意产品的用户留存率（有多少用户愿意当回头客），而不是盯着获取更多的用户。
团队角度
25. 仅按照自己的角色（产品经理应该做什么？程序员应该做什么？）来思考，会限制你的影响力。而应该换一种角度，以“我能做什么来帮助自己的团队成功”来思考自己在团队中的角色。
26. “喜欢挑战问题”的团队，会比“喜欢特定解决方案”的团队获得更多的成功。这是因为，即使失败了很多次，值得被解决的问题仍会持续地激励着团队继续走下去。
27. 对待团队成员，要永远怀揣善意。我的意思是，其实任何人都想做一些伟大的事情。也许这样做，偶尔不会有好的回报，但你还是会因此省去很多不必要的麻烦。
28. 你需要知道自己擅长的是什么，还有你的团队成员各自擅长什么。然后把最合适的人安排在最合适的位置。
29. 良好的沟通是保持团队健康的关键保证。任何成员都应该觉得可以很自由地发表自己的观点（尽管有的观点可能存在局限）。有多样化的想法才能帮助团队获得好成果。所以，不要害怕表达你的想法，不要害怕当别人可能没有听清或理解你的想法时进行复述，还有，要尽最大努力为其他团队成员维护这种安全感的氛围。
