Building Products【Part 1】
原文信息：
作者：Julie Zhuo[Product design VP @Facebook]
原文链接：https://medium.com/the-year-of-the-looking-glass/building-products-91aa93bea4bb#.pupxzxhb0
翻译内容：
我最近在TNW Europe 发表了一篇关于在Facebook一套专注于产品开发流程框架的演讲 。在准备演讲的过程中我想起了这些年在构建一个伟大产品过程中学到的其它东西。
这个列表并不完全或者确定。如果有一个一步一步的指导手册（第一步：开始于灵感.步骤二：？？？步骤三：利润），那么我们会支付一大笔钱买下他，然后我们退居幕后看着伟大的新产品迸发在我们周围如五月的花田
关于架构（On Framing）
1. 一个产品成功因为他为人们解决了问题.这听起来非常的基本，但是这是理解如何构建一个成功产品的最为重要的一件事情
2. 构建一个东西最关键的一步是想清楚你要解决一个什么问题，为谁解决这个问题.这个在你想其他解决办法之前一定要想的非常清楚
3. 第二个要问你自己的问题是“为什么就特定是这个问题值得解决”
4. 如果你的用户是定义在很小范围内的（如果你刚好是他们中的一员），那么你也许可以靠自己的直觉去引导你做产品决策.如果你不是的话，你应该依赖于研究和数据去指引你做决策
5. 如果你是一家创业公司的创始人，去做一个较为细分用户群的点子会很简单，有了最初的积累你可以去面对更为多样的用户
6. 你尝试去解决的问题应该能用一两句话说清楚，并且能让你的目标用户产生共鸣.如果不是的话那你的产品构思很有可能有问题
执行（Execution）
1. 好的执行力是在能获取的最短的时间内得到一个可以信赖的结论
2. 不好的执行力是当你尝试了一个想法，并且失败了 a)你无法从这个失败中吸取教训，而这些教训是可以在以后的项目中使用的，（因为你无法知道失败的原因）或者是b)你花了一年的时间去学习一个特定的教训，然而一个更智慧一些的道路可能让你三个月就学会这个教训了
3. 区分一个成功和失败团队的经典标准并不是他们怎样处理失败的事情而是他们执行的一致性
4. 当探索一个特定问题的答案时候，先追求宽度而不是深度.避免在过于陷入一个思维定式的正确答案，而应该去头脑风暴10，20，50个解决方案
5. 如果你展示一个产品计划有人问你“你考虑过替代方案X么？”如果你说没有，那就说明你的探索程序不够严谨.
6. 根据以往经验从你的头脑风暴中筛选出一些方案（比如，选出N个团队最喜欢的方案，设计或制作一部分高保真原型，然后将他们放到人们面前，看他们的反应）
7. 一旦你决定执行的解决方案，根据这个原则去构建他——如果你构建了这个产品你预期会发生什么？（例子：“我们想解决的问题是确保城市居民在周末能知道当地的事件，我们的假设是通过邮件推送的方式能让X%的居民获得该产品）
8. 你必须想尽办法去缩短审核你的假说.你能去街上向路人阐述你的观点并且让他们理解么？你能面向你的目标用户进行一个调查，并且评估出是否有足够多的人对你的想法感兴趣.你能快速构建一个版本来验证你的想法么？即使那个版本没有你头脑里的完善
9. 一旦你的假设有一个明确的利好消息，不要假定你需要马上把你测试的东西上线（因为可能你为了获得一个信号抄近路了）取而代之的，做一个单独的有目的的关于完全上线后添加完善和附加功能时会遇到的各种问题的决策. 什么是值得测试的，什么是可以上线的应该有一个大体的标准
10. 如果你要开始一个包含各种不同改变的项目，看看你是否可以把改变切分为更小，独立可测试的里程碑.不要掉进这样的陷阱，你做了五个改变，得到一个不好的结果，所以你要弄清楚到底哪个改变负责
11. 每个项目结束后团队都要做事后分析，不管成功失败.你学到了什么产品经验？团队学到了什么？未来你会做哪些改变？然后分在公司分享这些学习成果
