如何设计优秀产品

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