考虑价值的原则

任何产品都要有其价值（经济价值、情绪价值、精神价值、汇报价值等），其价值必须可以支付其成本。

任何一个产品，都有其存在的意义，也就是其价值。
不可以脱离开这些价值去思考对错，有时候复杂的事情回归到产品价值反而很容易判断。

比如，出现了一个新的中间件，小张快速掌握了这个中间件，并做了新旧中间件的对比，找老板游说希望进行技术推广。
第一种方式是，对比两种中间件的各项性能指标，说明新中间件的各种好。
另一种方式是，直接讲新中间件的价值，能解决哪些长期困扰产品的问题，能节约多少服务器，能将服务响应时间降低多少。
往往第二种方式更容易成功，因为讲到了中间件的价值。

再比如，如何判断两个新需求的价值。
第一种方式是，业务方甲叫的凶，催的急，所以先做业务方甲的。
第二种方式是，业务方甲和乙的需求，分别支撑了公司多大的业务，需求满足后，会给公司带来多大的收益。如果不做，有没有其他方式开展业务。如果做，投资收益比是多少。
往往第一种方式的结果是，慢慢就没有业务方和你好好说话了。第二种方式，可以屏蔽一堆没有必要的需求。

考虑人性的原则

产品的设计，必须符合人性。

需求的沟通，必须考虑人性。

比如：

1、用户抱怨一个软件产品不好用，研发同学过去一看，就一个小问题，至于吗。
更有甚者，用户十分在意按钮的位置，显示的字体要大，要用不同颜色区分。
但如果有问题的这个功能，用户一天要用几百上千遍，当然至于。

2、某部门要求业务方甲，提出一个需求：用软件把甲及其团队替代掉。
你觉得这个功能能做好吗？
不信是吧，我遇到过何止一次。没有一个是能成功的。

3、某团队工作量不饱和，公司为了提升员工绩效，强行从外部接了任务给到该团队去做。
该团队成员没有任何额外收益，但会承担工作的风险。你觉得这种调配能成功吗？

4、某公司2022年业绩不好，全员大锅饭，绩效outstanding都不调薪。更有甚者，只升职不加薪。
一方面大家做好做坏一个样，没了奋斗目标。
一方面只有更多的责任，没有更多的收入，考核要求还更高了，这也算是耍流氓吧。

产品自己用，自己产品自己满意原则

对于自己完成的产品，要做以下的事情：
1、自己试用
2、如果没发现问题，那就把自己当作最终用户试一下
3、如果没有发现问题，那就把自己当作一个不懂计算机的老年人试一下
4、如果还没有发现问题，那就把自己当作一个处女座的用户，再用一下
5、如果可能，自己的产品，自己要多使用。自己不使用的话，是发现不了问题的

对于自己完成的产品要问一下自己：
1、对这个产品的已知问题，我自己可以接受吗？
2、我自己对这个产品满意吗？
3、如果我是客户，我会使用这个产品吗？
4、客户知道怎么用吗？如何让客户更好的
5、客户用着方便吗？有什么办法让客户用着更方便吗？

无论何时，你都要对自己的产品有信心，这样别人才会对你的产品有信心。
但这些信心不是盲目的，这些信心来自于你对于产品、市场、用户、竞品的了解。

后来发现业界有句话说的很好：
Eating your own dog food.

引导用户而不是被用户引导原则

做产品的时候，最忌讳的一件事情就是“用户告诉你要怎么做，甚至是用户手把手教你如何如何设计”。这样的产品也许会满足用户当前的需求，但很难是一个好产品。（极端反例是用户做产品的经验要比你丰富的多，但即使这样，产品经理也应该有自己的想法）

很多时候，尤其是对于新入行的产品经理，用户在行业知识方面，比产品经理要丰富的多。此时，很多产品经理会被用户拖着走，用户说什么就是什么，用户说怎么做就怎么做，而没有去仔细了解，用户要这样处理的深层次原因。多数用户能看到的，是如何让自己方便，如何解决自己的问题；对于整体上是否最优，用户往往是欠缺考虑、盲目、甚至是错误的。同时，用户不懂应该如何具体实现，只能根据自己所见所想，得出一些思路，而不需要；很多时候，业内会有很多成熟的解决方案

正确的做法应该是：
1、从用户告诉你怎么做，梳理成用户希望你做什么，然后进一步去观察去理解用户为什么要这样做
2、把自己不很理解的需求，讲给用户听，确认自己理解无误
3、设计产品交互稿，与用户进一步确认
4、再多想想，然后再说开工的事情

易于实施及维护原则

产品为何要易于实施和维护

一个难以实施及维护的产品，部署时需要研发支持，联调时也需要研发支持，上线遇到问题时，还是需要研发支持。
普通实施人员根本无法自行推进任务，会否定自己存在的价值；
即使遇到简单问题，也要经验最丰富的资深实施人员来解决；
遇到稍微复杂的问题，就要研发人员介入；
长此以往，研发人员会陷入各种支持的泥潭，根本无法完成自己本职工作。
实施人员可以在这个过程中缓慢成长起来，作为研发的你和我，只是单纯的浪费自己的时间，不会有什么进步。

为了解放自己，为了不需要半夜被拉起来处理问题，我们的软件，至少要解决易于维护的问题。
遇到问题，输出准确的原因，并提供文档资料告诉实施人员要如何处理问题。

这样，普通问题就是普通实施人员处理；
资深实施人员可以处理掉大部分问题；
研发人员只需要处理诡异的问题即可。

为何要提供工具，可以快速定位及解决问题

当问题发生时，如果实施人员没有工具可以快速定位和解决问题，就要花费很多时间才能搞清楚问题出在哪个节点，然后花费很长时间来解决问题。

更糟糕的是，往往是用户发现了问题，去骂我们的实施人员。我们的实施人员，要在很大的精神压力下解决问题。

这个问题，不彻底解决，我们的产品不可能铺开去卖，因为我们没有这么多实施人员盯到现场。