产品到底是什么？
我对这个问题的理解其实一直是处于迭代的状态，所以不太敢给出一个明确的回答。
但就在最近，有了一个更新的答案，估计短时间内不会太大的修改，那就是：
基于当前的业务状态与市场状态，使用恰当的产品策略组合开发出能突出重围的产品的一系列动作，被我定义为产品。
也就是在我眼中的‘产品’不只是你看到的最终用户使用的那些东西，一个app、一个手机一个冰箱等。
而是包含了市场策略、产品策略、运营策略等综合技巧的东西。
因为产品之于用户，与人之于江湖一样，并不是孤立的。
必然是基于当前市场与社会的形态与情况、目标用户群的状态等因素综合为形成的，这样才能撬动市场与用户，不然孤立的自high的结果必然是失败。
当然也有苹果这种因为自high的目标恰巧与用户群体演化方向一致，最终引发了诺基亚的崩溃与苹果公司本身巨大成功的案例。
但现在为止，市场上使用如此策略而成功的案例据我所知也只有这一例，
老罗的锤子也败了，当然我其实还是很欣赏老罗的态度，不过可能也就因为老罗并没有经历过乔布斯败走苹果的经历，所以公司经营能力不够成熟，也可能就是因为他自high的方向没有像苹果那样匹配用户的演化方向，但反正结论是他也失败了，即使我不愿看到这个结果。
老罗欣赏的索尼现在的2c产品基本上也在慢慢衰落，不出意外也会走上诺基亚的老路。
当然也或许可能我孤陋寡闻，但即使再多几例成功案例也不影响后面我给出的思考与结论。
换句话说，产品其实是一个权衡的产物，也就是基于产品经理对于当前用户群现在的状态or未来发展演化方向的判断，以及市场已有产品的形态，以及公司的资金能力、资源调配支持力度等的限制，做出最佳的产品决策的一个过程，被我称为‘产品’
我最开始做过架构师，后来做算法又做算法架构，
什么叫架构？
架构其实也是一个权衡的游戏。因为任何一个架构都不会只有单一的设计目标。
首先利益方经常就会有很多，
例如一个简单的2c业务的架构，例如论坛、新闻阅读等业务，就包含至少下面几种利益方：
最终用户：在架构设计与开发期间，代表用户的是产品经理(PM)、
系统开发者、系统维护者(可能与开发方重迭)、公司高管、系统后台使用方(与开发方不同)。
最终还有架构师自己的利益，因为架构往往不是一次性的，需要后期的迭代与维护，以及后续资源调动难度等问题，所以都需要考虑到，不然多则1～2年，少则半年整体的架构可能就会被推倒重来，这样的架构设计则是失败的。
不同的利益方有不同的利益需求，例如最终用户(PM)代表的是整体系统的体验、功能等。
而开发维护方的利益就是工作量的降低与维护难度的降低等。
公司高管的需求则是：开发周期的缩短、开发人员的减少、还得能支持业务的快速发展。
系统后台使用方则希望系统可以即易用，又功能强大。
这只是利益方的显性需求，还有架构本身的隐性需求，例如健壮性、性能、可读性、可维护性、安全性等。都是需要考虑的要素。
但这么多的需求其实很多都是互相冲突的，不可能完全满足，这样最终的决策就只能是基于当前的时间、开发人力+能力、系统侧重(例如有关支付的肯定安全性、稳定性第一，而性能和可维护性等要求稍弱)等因素权衡出一个平衡方案。
产品同样如此。
没有完美的产品，只有此时此刻，当前环境下，最匹配用户和市场的产品。
但现在市场上所有关于产品的经验分享和书籍貌似全部在讲一件事，就是如何把产品本身做到最好。
通过产品的超预期而产生口碑效应、通过产品的极致而引爆用户的自发推广、
通过产品的不同而吸引核心用户的关注和使用、通过产品的更好而pk掉以往的竞争产品等等。
这些其实都没错，
只是这些策略都只是产品策略的一部分，都有其适应的场景与环境，甚至时代。并不是任何产品拿来做到极致就可以成功的。
我后面会基于产品这样的理解展开一些文章讲述我对一些具体问题的思考。
