产品设计是与时俱进的，而产品设计的准则也是如此。
我目前的团队自去年底组建以来，经历过多次的团队协作迭代，逐渐找到适合自己开发模式。每个开发团队的项目性质不同，或是因为项目初始成员的特质影响，会逐渐形成自己团队的特殊文化与适合产品设计的标准。
在 Medium 上有一篇产品经理写的文章，作者根据自己多年的经验，将产品开发团队分成了下列六种：
用户中心团队：例如 medium
增长型团队：例如 booking.com
功能型团队：例如 Atlassian
设计中心团队：例如 Apple
技术中心团队：例如 Google AI
初始团队：原文指的是具有满腔热血但还没有明确 KPI 的团队，常见于新创团队或是黑客马拉松项目（Hackathon Project)
虽然每个团队专注的焦点不同，产品设计的标准也有可能不同，不过产品设计的通用性「准则」，应该是可以应用到多元的团队上。
虽然这几年开发团队不断朝著扁平化发展，一个产品的好坏不再是产品经理的全权责任，但产品经理在产品设计的整个阶段，仍扮演了十分关键的角色。也因此，产品设计的通用准则，对产品经理而言，不仅要熟记于心，更要灵活运用这些准则，培养使其成为一种直觉。
探索问题阶段
1. 想解决人们的什么问题？
这是一个一开始也是最后的问题，这个问题的关键角色，永远不会是问题本身，而是使用产品的「人」。
2. 为什么这个问题值得被解决？
听起来有点玄，但实际上并不是所有问题都值得「被解决」。
跟大家分享个小故事：我们现在使用的键盘叫做 “QWERTY 键盘”， “QWERTY” 就是键盘左上边数来的字母排列顺序。你可能会想，这个键盘的排列方式是希望能帮助打字更快、更有效率，很抱歉，刚好恰恰相反。
QWERTY 键盘推出时，还是 1800 年打字机的年代。当时技术发展有限，打字机的响应速度比不上人类打字的速度，因此常常出现打字机故障的情况。 QWERTY 键盘的设计，其实是为了降低打字效率，特意将最常用的几个字母分开，在当时也成功解决了打字机卡死的问题。
随著技术不断进步，许多人想解决 QWERTY 键盘降低打字效率的问题，也的确推出了更符合人体工学、能提高打字效率的键盘，但一推出到市面上，最终都是以失败收场。因为人们早已习惯 QWERTY 键盘，甚至有除了键盘输入以外的信息输入方式。也因此，「QWERTY 键盘降低打字效率的问题」，就不是那么值得需要被解决了。
我们团队曾遇过一个真实的案例：业务主管跟你说他想要做一个实时监控业务员定位的功能，如果 IT 团队将这个功能实现了，会发现实时监控不但对于数据传输量的要求相当高，也非常耗费业务员的网路流量，而且业务主管平时工作忙碌，几乎不可能「实时」监控。
其实业务主管提出这个需求的背后，是想了解业务员是否确实执行工作，而实时监控，只是业务主管基于这个本质的问题所提出的一个可能的解决方案，但却不一定是个合适的解决方案。
4. 这个问题是否简单、清晰，足够被其他人理解？
换句话说，如果一开始就无法清楚定义问题，那又怎能产出具体有效的解决方案呢？
执行阶段
（1）全局在前，细节在后
深入一个解决方案之前，确保已经尝试过其他的方案。最快的验证方式，就是当团队其他成员提出「怎么不试试 XXX」建议的时候，就代表想的还不够全面。
（2）原型图快速验证方案
如果产品已有明确的目标使用者，在进入开发之前，可以通过简单的原型图先让这群使用者进行测试（可用性测试 Usability Testing），藉此快速验证方案。
（3）设定产品的预期结果
包括任何质化或量化指标，比方说减少 20% 的操作时间、提升整体使用满意度……等等。
（4）排序功能开发优先级
一个完整的功能里，一定有最重要、次重要以及较不重要的排序（MoSCoW 优先级）。过去强调全面、完整功能的瀑布式开发流程，在现代快速迭代的数字世界里已逐渐被敏捷思维所取代。
举个例子：当 A 团队还在为那从 90 分进步到 95 分的功能苦恼而迟迟无法推上线时，竞争对手 B 团队早已将 80 分的产品推上线，虽然 80 分的产品让终端使用者不是很满意，也有不少抱怨，但 B 团队收集到了真实使用者提出的问题，并进行改版。
当 A 好不容易将 100 分的产品推上线，却发现市场早已被 B 占据，而且 B 的产品经历多次改版，更符合使用者的需求，当初 A 团队坚持的 100 分产品也不是当今市场的 100 分了。
（5）快速试错，迅速调整
以更包容的心态来面对错误的发生，检视个人或是团队在面对错误发生时，是否有足够快速的应变能力，能迅速调整方向，并且记录问题、总结归纳，不再犯同样的错误。
（6）阶段性反思总结
无论产品成功或失败，团队反思是整个执行阶段中最重要的一个环节。团队反思，绝不是互相抱怨的批斗大会，而是一个阶段性任务完成时，让团队彼此都能够沈淀思考，调整步骤继续迈步向前的机会。
尤其在跨功能的团队里（cross-functional team），可以更好了解各个团队成员在协作中遇到的挑战、当下的解决方式，以及未来可以如何调整合作的方式。
团队反思的时间可以是在一个大的开发版本上线前后发起，通过 1-2 小时的会议，有明确的主持人、会议记录者，分别感性与理性的两个时间段。感性的时间里，让大家说说过去的开发过程中看见好的、不好的以及要感谢的地方；理性的时间里，明确的提出问题点，让团队一同来思考解决方案。
验证阶段
（1）设定验证指标
在产品上线之前，就必须将验证指标设定好，并确保团队每一位成员认同各项指标。
（2）设定反效指标
这个验证方式是 Facebook 产品设计副总监（Product design VP）Julie Zhou 提出的，验证一个指标是否成功，就把不成功的指标条列出来。
（3）找出问题比调整方向更重要
产品上线后，如果发现偏离指标的情况，无论是好的或是坏的方向，首先厘清问题发生缘由，再来调整策略。
