翻了翻博客，好久没有写东西了。最近由于换公司也很难静下心。好在总算有了一点时间做思考。
从入行到现在，有些年头了。“新瓜蛋子”这个称谓确实也并不适合放在我身上。于是我便开始思考这个我赖以生计的职业究竟对整个互联网工业体系到底意味着什么，
可能每个产品人都是这样，从开始做产品的那一天起，便一直在思考一个问题，什么是好产品，B端产品的价值究竟在何处？这个问题就像“如何做深度的思考”这个问题一样，那么简单却又那么难以回应。
什么是工作？
首先，我们先来审视下什么是工作。工作说的更直白它的本质就是一些就是通过自己时间和技能通过公司等手段换取等价值的交换物。这里有两个维度：时间，技能。
以时间维度来看，在单位时间内获得的报酬越高，其实相对来讲收益也就越高。所以这就是为什么现在越来越多的人来追求所谓的“时薪”。
再来谈谈技能，在互联网领域的技能曲线是不会随着时间的累积增加的，这点我想大家都深有感触。Gartner 这张图或许可以适配所有场景，前期我们接触的东西越来越多，会发现很多东西都很容易实现。随着对产品的理解深入会陷入深水区，随后逐渐进入技能缓步爬坡期。
所以我认为工作最本质的诉求就是获取报酬，如果更深一点就是在获取报酬的同时实现自己的抱负，创造一些与众不同的东西。
给产品策划下个定义
我听过太多长篇大论，论证B端产品在某个阶段该如何如何，更有甚者画了一个看似高级的金字塔分门别类的排出高级产品策划，中级产品策划，低级产品策划的 Job model。每当看到这种推文我总是无奈又好笑。如果产品策划真的和考证一样具备某些技能就能跻身前列，恐怕是个人都可以直接拿着 NPDP，PMP 横着走了。我一直认为能力模型只是做好产品的基准线，就像法律是道德的基准线一个道理。这个基准线之上一定有更多可以探索的东西。
产品力我更愿意将它定义为两部分：
- 产品想象
- 产品执行
产品想象这个很好理解，我们看到一个场景，然后通过周详的分析报告，数据验证，告诉其他人我们要在此方向做投入。并且和他人达成共识。这点一般情况下问题都不是很大，只要需求点明确。
这两部分中最难的其实是产品执行，产品执行依赖的是一份非常详细的“工程手册”，也就是产品PRD。尤其当协作人数和工种众多的时候，一份好的，达成共识的“手册”可以避免很多无效沟通。这一点我非常自惭形秽。
至于两者的关系，之前偶然间在其他地方翻到乔帮主说的话，兴许可以帮助我们解答。其大致意思是“当我们拥有一个好的想法时，我们往往认为事情已经完成了90%，我们只要告诉他人这个想法，然后我们埋头在办公室就可以把想法变成真。问题在于，好的想法和好的产品之前存在着巨大的鸿沟。实现这个最初的愿景时，我们会发现我们的想法一直在变甚至面目全非，因为我们越深入，细节越多，决策点越多，我们不得不一次次权衡利弊，做出让步和调整。所以当我们想做出一个东西时，必须仔细梳理所有问题，尝试各种可能。这才是产品的魅力”
这番话我仔细读了好几遍，深感敬佩。它其实表述了产品策划中最难的部分 – 思考。
总结下来，如果给产品策划下个比较明确的定义它的本质就是发掘诉求，深度思考并通过证明或者证伪为实现某项诉求找到最短的解决路径。决定产品策划好坏的判定标准就是思考的深度和广度。
如何判定产品力？
产品力这个词儿其实很虚，一个产品的好坏其实往往不是一个或几个因素决定的。打个最简单的比方，你能说 K12 没有诉求吗？你能说他们不是好产品或者没解决客户诉求吗？
所以，这里的产品力我们单论在客观环境下的产品力。
好的产品力都遵循一定的规律，如下是《启示录》里的定义：
1.产品经理的任务是探索产品的价值、可用性、可行性。
2.探索（定义）产品需要产品经理、交互设计师、研发架构师通力合作。
3.开发人员往往不擅长用户体验设计，因为开发人员脑子里想的是实现模型，而用户看重的是产品的概念模型。
4.用户体验设计就是交互设计、视觉设计
5.功能（产品需求）和用户体验设计密不可分。
6.产品创意必须尽早地反复地接受目标用户的试用，以便获取有效的用户体验。
7.为了验证产品的价值和可用性，必须尽早地、反复地请目标用户测试产品创意。
8.采用高保真的产品原型是全体团队成员了解用户需求和用户体验最有效的途径。
9.产品经理的目标是在最短的时间内把握复杂的市场/用户需求，确定产品的基本要求——价值、可用性、可行性。
好的产品，好的产品力往往不是产品经理一个人可以决定。产品经理是一份非常吃平台的职业，他不想研发可以单打独斗，所以大的平台才是产品力的基石。举个非常简单的例子，我们现在都已经把张小龙封神，觉得他很厉害打造了可能全球范围内都屈指可数的高频软件。但是我们客观的换个角度想一想，社交软件的本质是什么？其实是关系链，因为其他人都用微信，所以我们自己才必须也用微信，微信最初的关系链是怎么建立的？其实是之前 QQ 为微信引流建立了最初的关系链。这就是平台。
所以现在在大厂获得些许成就的同学可能大部分都是平台的原因，千万不要把平台想象成自己的能力。
可见好的产品力几乎依赖全部工种的通力配合，而配合的基石是在上一章讲到的产品想象和产品执行。
附：一些 B 端产品的参考
最近也在帮项目组同学梳理一些关于B端产品的模版，这里也简单分享下。
首先，我描述一个观点，需求文档模板到底能不能套着写？
市面上的文档模板太多了，直接可以搜到的，各种教学，各种视频都在讲，这里面的水分，相信看过的人都大致了解过七七八八。
模板是可以套的，模版更多意义是帮助拓展思考，查缺补漏。比如我自己都经常忘记补充一部分重点要素内容。如果有个模版可以提醒我做思考那肯定在好不过。
还要注意一点就是模板归模板，不能死套，举个例子，比如模板上让你写了产品功能，需求描述，功能介绍，没说画流程图，时序图的事，你能不画图像写作文一样描述需求吗，这样是不行的。
以上，祝好。