تسجيل الدخول الآن 2017 年 5 月 12 日，我第一次翻译了这篇文章。后来在工作中，我会时不时翻出来重读一遍。很奇怪，每次重读都有新的感受——大概是因为手头正在做的项目不一样了，之前没留意的细节突然跳出来，给了我非常具体的启发。后来我干脆把这篇链接加进了公司 wiki 的 PRD 默认模板里，让团队里每个产品经理在写需求文档之前都先看一遍。再后来，公司发起了产品协会，我也有幸加入。作为成员的任务之一，我们决定翻译一些高质量的海外内容。从那以后，大家的英语技能总算不再只停留在给变量命名（比如 login_switch）的程度了，这算是一个不小的收获。
这篇文章的原名是“Building Products”，作者是 Facebook 产品设计副总裁 Julie Zhuo，发在 Medium 上。她结合自己的工作经验，从准备、执行、衡量结果和团队建设四个角度，梳理了一套她认为有效的产品设计原则。读完之后，我发觉有一些地方跟我过去的经历非常吻合，也有不少恰好击中了当前遇到的困惑。如果你英语还行，强烈建议直接去 Medium 搜 Julie Zhuo 看原文。
Julie 最近在 TNW Europe 的一场讨论中，聊到了 Facebook 产品设计方法论的应用。这场交流让她重新想起过去打造成功产品的一些经验。下面这份产品设计清单，并不是什么完备的宝典，也不绝对——如果世界上真有一本完美指南，告诉你第一步获得灵感，第二步……，第三步就能赚钱，那我们直接买一本，拍拍同事肩膀，然后等着神奇的新产品自动冒出来就行了。它只是经验的一小部分，更多的探索和学习，永远在路上。
关于产品筹备，她认为最重要的起点是：一个产品能成功，归根结底是因为它帮人解决了一个问题。这听起来像句正确的废话，但却是理解优秀产品设计唯一最关键的事。所以，开始设计新产品时，第一步不是打开画图软件，而是非常清晰地回答：你在为谁，解决什么问题？在动手构思任何方案之前，这个答案必须钉得死死的。紧接着，你要问自己第二个问题：为什么这个特定问题值得去解决？如果你的目标用户群定义得非常窄，你或许可以更多依赖自己的直觉来指导产品决策；但如果用户群很宽泛，你就必须借助调研和数据来支撑判断。而从 0 到 1 做产品时，把目标用户群收得更窄一点，路往往会走得更顺——先让一小群核心用户真正用起来，在获得初步关注后，再慢慢扩大范围。最后，你所解决的问题，应该能用一两句话就向目标用户解释清楚。如果做不到，那就是一盏大大的红灯。
在执行层面，Julie 对“好执行”的定义非常直白：在最短的时间内，得出最可信的结论。相对应的，“坏执行”则是：尝试了一件事，失败了，但要么你根本不知道失败的原因，没法从中学到任何东西；要么你花了一年时间，却发现三个月前就有一个更聪明的方案。判断一个团队是否成功，不是看他们做的事有没有失败，而是看他们能在多大程度上持续保持好的执行力。当你试图解决一个问题时，先发散，再收敛。在做出决定之前，去头脑风暴出 10 个、20 个甚至 50 个方案。前 5 个方案通常都比较明显，创造力往往从第 11 个、第 20 个或第 50 个方案才开始真正涌现。如果在演示方案时，有人问你“有没有想过某某方案”，而你的回答是“没有”，那就意味着你对解决方案的探索还远远不够。这时候，可以借助实证分析来帮你缩小选项范围，比如挑出几个大家公认较好的方案，做出高保真原型，直接放到用户面前看实际效果。一旦你选定了要执行的方向，就要明确表达你的期望：如果真这么做了，预期会发生什么？比如，你想解决的问题是确保每个居民都能了解本地周末活动，那么你的预期可能就是“通过邮件列表触达 X% 的居民”。接下来，你应该持续寻找验证假设的方法。你可以直接在街上拉住一个人，看看对方能不能理解你的方案；可以做一份调查，看看是否有足够多的人对你的想法感兴趣；也可以先做一个不完美的原型，快速获取明确的结论。上线后哪怕收到了一些积极信号，也别急着立刻全面铺开。在优化方案时，需要不断调整扩展的标准，并且测试和扩展的标准应该是不同的。如果你的项目范围很大，涉及很多变动，试着把它拆解成更小、更独立的里程碑。千万别掉进那种陷阱：吭哧吭哧改了五个地方，结果数据不好，却完全搞不清楚到底是哪个改动出了问题。每个项目结束后，无论成败，都要做一次小组回顾。你个人从中学到了什么？团队学到了什么？今后会做出哪些改变？然后把这些经验分享给整个公司。
怎样衡量成功，对团队的长期产出影响极大，因为衡量什么，团队就会关注什么。所以，务必在定义成功标准这件事上，投入足够多的时间和注意力，甚至可以比思考解决方案本身花的时间更长。在产品发布之前，你就要把成功的定义定好。否则，事后拿着结果去解释，很容易陷入确认偏误，做出不客观的解读。Julie 推荐了一种“魔法球”的办法：问问自己，如果我知道有人在用我的产品，我最想听到什么样的描述，才能确信产品是成功的？通常，你得到的答案不会是一个按钮的点击率，而是更抽象的东西，比如“有多少人从我的产品中真正受益了”。然后，你再从这个答案出发，倒推你能衡量的成功指标应该是什么。你的目标应该始终基于当时最新的有效信息来设定。如果你正朝着某个既定目标前进，中途却获得了一些足以改变想法的新信息，那就应该认真考虑是否要据此调整目标。如果你发现团队无法理解或形成一致的成功衡量方式，要把这个问题直接摆到台面上。尽早暴露这类根本分歧，对提升效率和最终产出都很有帮助。同样，如果你经常和团队就产品方向争论不休，根源很可能就是大家对“成功”的理解和衡量方式不同。这时候，可以试着提出另一种衡量团队成功的方式，看看能不能把大家拉回同一频道。如果你想了解产品是否真正契合市场，比起新增用户量，更应该死死盯住留存率——有多少用户愿意成为回头客。
最后，从团队角度看，如果一个人只盯着自己的角色该做什么（产品经理该干什么？程序员该干什么？），只会限制自己的影响力。不如换个角度想：我能做些什么，来帮助这个团队成功？一个喜欢挑战问题的团队，会比一个执着于某套特定解决方案的团队走得更远。因为，一个值得解决的问题，即便经历了多次失败，也能鼓励团队继续走下去。要善待团队成员。我的意思是，发自内心地相信每个人都想把事情做好。偶尔也许不会有好的回报，但这样做能省去大量不必要的麻烦。你需要清楚自己擅长什么，也清楚团队成员各自擅长什么，然后把最合适的人安排在最合适的位置上。良好的沟通是保持团队健康最关键的保障。任何成员都应该觉得，自己可以自由表达观点，哪怕有些观点还不够成熟。多样化的想法能帮助团队取得好结果。所以，别怕说出你的想法；当别人可能没听到或没理解你的意思时，也别怕重复，同时尽力为团队里的其他人维护这种心理安全感。