产品经理核心价值:价值产生于合，能量释放于分(2)
D战略性产品：很多互联网企业从大众市场纷纷开始进入细分市场，这就要求企业敢于创新，在创新的过程中往往伴随着很多改革，企业会从新定义市场、制定新的目标，推出新的产品，希望改变现有的盈利模式和业务框架、市场格局。这便有了所谓的战略性产品，例如腾讯的拍拍、百度的有啊、新浪的博客、阿里的支付宝，其中有的成功、有的还不明朗，这也正是此类产品的特性。创新和改革的路上异常艰难，很可能这个产品与现有的很多业务冲突、与现有的部门利益不协调。而且企业不会像中央政府那样搞十一五计划给你5年时间，也许你只有半年，所以这要求产品经理要具有很强的把控能力和坚强的毅力。
作为产品经理只有去了解这些才能预想到今后的工作中可能遇到的问题、可能争取到在资源、可能投入的精力、可能组建的团队规模、可能遇到的瓶颈和坎坷，未雨绸缪才成为可能。
所以，不建议一开始就埋头设计精美的PPT、华丽的demo，应该去了解公司做这个产品的目的和动机。
2、了解市场需求
这里也有个误区，很多产品经理通过所谓专业的分析方法例如swot和大量的百度搜出来的数据做出来一个东西，就算交差了。而很少去考虑为什么要去做市场分析，如果我们每天把很多时间花在应付那些不知道为什么做而做的事情上，将很容易被淘汰。
我认为的目的有三个：
A、试探自己的思路与公司的思路是否有偏差，适当的在公司原有的想法上做扩展，加大公司对产品的兴趣。
B、给相关部门吹风，特别是业务团队和运营团队，他们手上正在卖或者正在推的产品可能有很多，你的产品市场优势在哪里？也许不能让他们马上兴奋起来，但是至少应该让他们关注或者积极的反馈意见。
C、自我梳理，写的过程就是想的过程，想的过程就是辩证的过程，很多思路会在写的过程中迸发出来。
所以，市场分析可以包含以下内容：产品对于行业的价值、在市场发展的环境下产品可能的生存空间、产品在市场价值链中所处的环节、预期的市场回报。
关于用户需求这里就不多说了，有很多这方面的文章。
到这里，需求分析阶段算是尾声了，总的来说，产品经理在这个阶段最大的意义就是给产品建立意识形态，有点类似军队出征前的誓师大会，虽然很虚，但是对将来的工作很有帮助。
二、设计规划阶段
在这个阶段，开始有越来越多实在的交付物出来，例如：产品规划方案、产品demo、需求文档等等。
1、产品规划方案
无论这个方案是不是由产品经理本人来做，产品经理都应该要求这个规划方案中说明白几个问题：
（为什么做）产品背景和需求说明
（做成怎样）功能说明
（如何实施）里程碑和时间计划
（回报）投入和产出比
（如何经营）运营策略
这是产品从虚到实一个很重要的过渡，把之前天花乱坠的产品思路通过这个方案告诉大家如何实现，并且是有计划有里程碑式的实施。
如果把产品经理比喻为一枚陀螺，这个方案BOSS拍板的一刹那将成为陀螺的分水岭，在这之前鞭子缠绕着陀螺在蓄力，拍板声一响鞭子猛的抽开，产品经理就开始疯狂的忙开了。
2、产品demo
有了需求，自然就有了功能，各种功能组合生产了功能模块，功能模块就搭建起一个产品的框架，在这个产品框架下有哪些系统提供支持，最终画出产品大概的样子。于是功能模块、产品框架、系统架构、低保真原形打包起来就生成了一个产品demo。
产品经理可以拿着产品demo去评审验证了。听取交互设计师的意见、听取视觉设计师的意见、听取前端工程师的意见、听取开发工程师的意见、听取业务和市场的意见、听取用户的意见，陀螺陀螺疯狂转吧！
如果你发现这群鸟人，之前鸦雀无声，现在忽然噼里啪啦的开始拍砖，不要觉得奇怪。眼见为实，大家只有看到你产品的样子才能发表各种意见，而且这些意见还多数是在抠细节。听取意见的过程中，产品经理不会忙于辩解，思维像陀螺似的转起来，意见是否采纳，更多的决定权还在于产品经理，所以你要能够识别各种意见的出发点。有的人会从专业角度、有的人会用改变功能实现方法减少自己的工作量、有的人会站的自身利益的角度、有的人会站在伪用户的角度。如果你应付不来，可以把大家的意见记下来，回去好好的考虑。如果一些问题非得会上就定结果，先明确轻重缓急，实在不行就中场休息借机场外求助。陀螺陀螺效率的转起来吧！
关于需求文档，这个就不用说了吧！
在这个阶段，产品经理除了协调各方，还应该想办法建立一种沟通机制，让团队高效的工作。在很多互联网企业，产品是没有独立团队的，都是线条式的贯彻在各部门。
三、开发阶段
这里的开发是广义的，包括UI设计、前端制作、程序编写、运维支持。
这阶段提几个建议：
做设计和开发的都不是好惹的鸟，要么极具个性、要么孤傲、要么执拗。其实这和他们的工作性质有关，创意是需要时间和空间的，建议产品经理们能尽量的满足他们，也许时间是公司敲定的，但是一个良好的发挥空间还是可以提供的。在上面说的广义开发过程中，产品经理往往会遇到很多新的需求，要么是BOSS直接发话、要么是市场部门临时兴起、要么是产品经理自己遗漏。怎么办？要不要加进去？衡量一下吧，如果是影响到核心功能的可以加，如果是边缘化的东西建议放在第二版再加，否则有新的需求就加，这个产品很难在原定计划上线，而且干扰了开发人员的发挥空间，好不容易安下心来思考，又忽然来了新的需求要做，谁都不乐意的，何必呢？相互多一点理解，就少很多抱怨的。
人无完人，没有哪个产品经理能把产品的方方面面想到100%的程度，所以开发过程中，开发人员会有很多问题需要确认，这些问题需求文档里面被遗漏了，所以产品经理需要留有足够的时间给开发人员，如果自己很忙也需要安排一个专人负责协调。
此时沟通的事情占用产品经理的时间不多，所以可以开始花时间考虑产品相关的文案了，这部分我在之前的文章《构建完善的互联网产品文案体系》中有讲到。这个体系的内容如下：
产品上线之后再做就耽误了，也许这些文案不用产品经理本人来做，但是需要把你的想法和对产品的理解灌输给做事的人。不是所有产品都需要这些文案，相信大家能区分。