可可总结了这个项目的经验。
1. Ruthless Prioritization & Organizational Buy-in
成熟的产品经理和入门级的选手的区别就是独当一面的能力，而这种能力最赤裸的体现是对于product roadmap的把握。刚入门的产品经理通常专注于执行、而资深的产品经理更加偏重于取舍和决策。现实中，在一个产品飞速成长的阶段，从四面八方铺面而来的需求一定是远远大于我们可分配的开发、设计、分析、运营、销售资源的。舍得、舍得、有舍才有得。
那么我们要如何取舍、又是如何与关键人物们就取舍达成一致（drive alignment)呢？
1）根据产品的阶段、公司和部门的策略，定制你的优先级原则（prioritization principles)。有的产品正在寻找product market fit 的阶段，这个时候time-to-market以及core user value 更加重要，比如这个鸿蒙3.0产品切入市场的时间点以及核心用户社群的组建都是让产品变得更优秀更强大的关键步骤。optimize for bussiness value，同时把用户体验、运营成本、开发成本作为sytisfying metrics。
2）站在利益相关方的角度理解他们的原则和诉求，适当利用escalation path。大公司里讲究alignment，如果基层协调无果，便向上escalate.明白最终决策权在谁手上，以及这些MR、MRS的决策原则，便能不战而屈人之兵、无往不胜。
可可问了下在硅谷工作的雨欣姐，请教了下硅谷的工作模式。在成熟的大公司里有专门的design 的部门，产品经理是那个frame the program 的人，而不是provide ux wireframe 的人；同样的，硅谷的设计师并不仅仅是比照着产品经理的原型图画出high fidelity mock 的角色，而更多的用它们的交互设计经验参与ux solution 讨论和决策。换句话说，我们要有效的pick on designer's brain，借由它们丰富的设计经验来共同寻找出最合适的解决方案。
借此鸿蒙3.0产品的外观来看，便是多名设计师共同讨论出来的。然而，产品设计师并不是一份容易的工作。设计的优劣在一定程度上是比较主观的，一千个设计师能给出一千种风格和方案一千个人也可以有一千种喜欢和不喜欢的理由。哪怕最终产品的体验有多好，其中的好又有多少来自于贴心的设计，也不总是能通过A/B test 来估算和归因。
其次，设计师的美好构想都离现实有不小的一段距离，所以我们定稿的过程也是不断调整设计的过程，有时候因为技术的可行性不得不settle on optimal design，更有时候因为time to market 的紧迫性不得不削减到一个short-term solution。优秀的设计师必须能理性地面对质疑，清晰地阐释设计思路，在坚持原则的同时又being flexible and realistic.
可可总结了项目中合作过的十名设计师，每一个都个性迥异，但也都有一定的共性。根据我以往的经验，和设计师建立深厚的革命友谊需要注意以下几点：
1）尊重专业，给予发挥的空间：对于设计师来说，自主性是成就感的最重要来源。如果我们仅仅把设计师当作调整pixel和color的人，未免大材小用，也会瞬间让设计师失去合作的热情。相反，当我们以一种谦逊的姿态，frame user problem， lay out current usage data and user research results，和设计师一起分析用户的功能性需求以及情感需求，优秀的设计师一定会不负众望地一鼓作气提供好几个可能的方案来回馈我们的信任。
2）兼听则明，借力打力：在设计方案存在明显的局限性的时候，我们必须有条理地提出来，说服设计师换一个思路。其实这种不同的声音不一定要来自产品经理。如果是开发的局限性（比如scope太大，数据不到位，或者tech stack太老旧支持不了新的UI Components），由开发人员提出来更加准确且有说服力。如果是对于用户流程和交互本身的讨论，则多听听user research团队的意见。适当地借力打力反而能得到更好的效果。所以我们在组成tiger team的时候，最好囊括各个方面的代表，兼听则明的同时，还能更加有效地说服其他成员达成一致方案。
3）掌控节奏，快速迭代：通常情况下产品经理是掌握各方面信息最全面的人，我们既了解公司的长短期策略是什么，用户的痛点有多痛，开发的难度有多大，也知道time-to-market的紧迫性有多强，leadership层层传递的压力有多大。然而设计师的视角里却更多的是用户的痛点，和自上而下口耳相传的vision and strategy。所以，他们设计的时候很容易会忘记时间的边界，忽略实施的成本，花了不相称的时间来把每个细节做到完美无缺，或者由设计一个快速迭代的功能变成一个设计一个全新的系统（revamp the entire experience）。在这个时候，产品经理就要合理地设置design scope（哪些需要改变／添加，哪些不需要改变），清楚地列出产品的迭代秩序，并且砍掉现阶段不必要的功能。尽管这么做要顶着say no的心理压力，也与表面的“精益求精”看似背道而驰，但确实是值得的，因为最终我们善用了每个人的时间，stay focused， move faster， and improve faster。
