硅谷产品实战学习感触

---

写在之前

        今年年初给自己安排了一个任务，每个月写一遍感悟性的文章。促使自己沉淀并思考。 回望自己在软件行业的经历，总是感叹如果早知道某某事情多好。这篇文章主要写一些建议，如果这边文章有幸被你看到， 希望对你有帮助。

       最近在“极客时间”看一些文章， 刚看完的课程叫硅谷产品实战， 主要写作者在硅谷工作时的感受， 有兴趣的朋友可以去集客时间看看文章 ，共36讲。其中有一些片段我比较有感触，增加一些思考记录下来。

---

1.最小化可行产品

---

       精益创业代表了一种不断形成创新的新方法，它源于“精益生产”的理念，提倡企业进行“验证性学习”，先向市场推出极简的原型产品，然后在不断地试验和学习中，以最小的成本和有效的方式验证产品是否符合用户需求，灵活调整方向。如果产品不符合市场需求，最好能“快速地失败、廉价地失败”，而不要“昂贵地失败”；如果产品被用户认可也应该不断学习，挖掘用户需求，迭代优化产品。

        “最小化”在这里的意思就是，没有任何一个功能是“加上去也挺好的”，但是少了任何一个功能都无法解决用户最基本的需求。最小化 = 降低试错成本，速度 > 完美

       “最小化”的概念我觉得是这个行业从业人员都应该具备的。开发人员的“最小化”概念可能体现在某个功能上，在设计上做到功能可以最小化提交， 后续扩展可以不影响已实现的功能，也就是常说的开闭原则，项目经理的“最小化”概念可能体现在项目任务上如何取拆分，迭代提交都是完整可用的功能

---

2.产品经理权衡取舍

---

       产品经理每天做得最多的事情就是砍功能：

• 删减产品需求文档上的功能，只保留最重要的功能；
• 已经决定了要加功能，但出现了突发情况，需要临时决定到底要不要砍功能。

      在项目中很少有产品经理能做到筛选砍功能，时不时还会增加任务。  要么是客户要求必须完成；要么是领导要求必须完成。 整个项目就发生了变化， 发布时间是固定的，项目内容是增长的。项目成员都有挫败感

• 开发人员在抱怨任务超出预期，加班也完不成任务
• 项目经理在抱怨项目超出可控范围。无法预估关键节点
• 客户和领导抱怨怎么项目又延期

      这种情况下，沟通变得愈发重要，需要有人站出来沟通，组织大家取舍。  我记得第一任项目经理叫宋春勇，他曾经跟我说过一句话：项目是谈出来的，不是做出来的

---

3.制定产品的成功指标

---

        约翰 · 道尔（John Doerr）是硅谷最牛的风险投资人，是谷歌、亚马逊、网景、升阳电脑等公司的早期投资人，更在  1999 年投资谷歌时，教给了创始人成功指标（OKR）的概念，帮助谷歌达到了今天的高度。

         2018 年 4 月， 约翰 · 道尔出了一本叫作《以你在乎的作为衡量指标》（Measure What Matters）的书，专门讲成功指标这件事。他在书中指出：指标是为了定义你想要完成的目标，需要表达清楚在什么期限之内、要达到什么具体的、可衡量的结果。 换句话来说，一个好的指标应该是像“2018 年底之前实现 100 万日活”这样的，而“让用户多花时间在 APP 上”、“争取用户规模达到 100 万”都因为缺少了关键信息不能算是一个好指标。

        “OKR（Objectives and Key Results）即目标与关键成果法，是一套明确和跟踪目标及其完成情况的管理工具和方法，由英特尔公司创始人安迪·葛洛夫（AndyGrove）发明，2015年后，百度、华为、字节跳动等企业陆续推广

---

4.产品经理和设计师沟通

---

        同样一份产品需求文档，有的设计师认为功能描述太具体，限制了他们发挥的空间；有的设计师却认为不够具体。这是我刚做产品经理时感觉非常苦恼的一个问题，在和设计师打了多次交道后，我才明白了“众口难调”的原因，以及怎么处理这种情况。在我看来，处理这种问题最直接、最高效的方式是，和你的设计师搞好关系，问问他们是喜欢文档中功能描述写得清楚些，还是只要给出策略性的建议就可以了。你可以在每个项目的文档中先写策略性的内容，然后对设计师说：“这是咱们产品的策略和大致想法，你先看看有哪些部分不够清晰，我来写得更具体一些。”只有多沟通，才能更高效

     我觉得文章对设计师特点总结很到位，尤其是第三点

• 设计师是完美型人格，艺术家
• 设计师多数是没有产品设计能力的，他们的关注点在功能实现上而非功能使用上
• 设计师预估工期的能力比较差，并且多数是乐观预估

---