原创文章，转载请联系作者
自从C端流量红利开始强烈震荡衰减，越来越多的C端公司转头看向了还在中国一片大蓝海的B端市场，产品经理作为“很聪明”的一波人，也快速掉头，瞄准了B端的广阔天地，但是从C到B，不仅是一个字母的变化，无论市场，客户，价值体现都截然不同。
在工作中我也发现，B端复杂的市场环境和冗长的决策链，经常让产品经理摸不到线索，找不到目标，常常出现“懵圈”状态，迷雾拨也拨不开。更可怕的是，如果把C端产品比喻做信息战，那么现在国内的B端产品基本就是肉搏战，短期来看，惨烈至极，而B端的试错成本非常高，当产品一直在“摸着石头”，时间一长，机会成本会指数倍放大，产品的失败很可能带来的是业务线甚至公司的垮下。
为了解决这个问题，在公司内我尝试过很多的方法，希望能够找到一个适合团队的，从产品规划到实现的思维框架，能够梳理清楚我们应该以什么心态，做什么事情，达到什么目标。
GASID算是第一次迭代的产物，我借用Lean Startup的思维，来实现B端产品经理能够有手感、可执行的一个产品开发Pipeline，帮助大家厘清思路，足够敏捷、有信心地带领自己的产品走向市场。
下面，我来解释每一个模块（之后的文章，我将独立解释每一个模块的内容和执行方案）：
产品目标（G，Goals）
产品目标是这个框架的起点，也就是说，我们必须先形成一个目标，明确地指出我们到底做的是什么事情，有什么价值（我坚信，想不清楚永远做不好）
交付物：一句话的描述，直截了当，这句话的结构如下：
向（用户）提供传递（价值）的（产品）
在这里，三个要素都要清晰地表述：
to whom：我们向谁提供服务，这里一定要是一个实体（公司，组织），不是一个行业（农业用户不是正确的表述），也不是某一类人（B端产品的whom不可能是个人）；
Value：我们提供的价值是什么，这里价值的表述一定是一个差异化的表达，很烂的表达诸如最佳、最好、顶尖、标杆等，价值表述是能够用户一眼能够高亮打入用户脑中的价值点，而不是正确而无效的形容词堆砌‘
What：我们提供的是什么，是设备？系统？解决方案？服务？当你们无法下笔将自己的产品分到这四类的时候，就要好好想想，到底什么形态能够满足上面的Value。
市场分析（A，Analysis）
市场分析是我们在面对市场之前的情报图，一份有逻辑并且逻辑能够自洽的市场分析，就是难能可贵的“备战指南”。
交付物：市场分析报告（1-2页Word文档）
有几点需要在市场分析内体现：
TAM（Total Addressable Market）：看过了太多的产品经理市场分析报告（当然，不做市场分析的产品经理，100%是不配做产品经理的）都在画大饼，市场低于1000亿都不好意思写在报告里面。TAM是一个极其重要的概念，要识别出这个产品所在的细分市场，即可触达市场，举个例子来讲，中国社会零售消费总额30多万亿，你做个零售CRM系统，如果你的市场是30多万亿就很滑稽了。
市场细分：如上所说，找到你的细分市场，脚踩在马尔代夫的沙滩上，不代表印度洋是你的市场；
客户识别：在定位了细分市场后，很自然地找到你的客户是谁，同样，这些客户一定是一个实体（公司，组织）；
竞争对手识别：逻辑相同，找到了客户，按图索骥，找到现在的竞争对手，这里一个小提示，竞争对手一定不要忽略间接竞争对手，比如做一部电影，千万别忘记了你旁边上映的话剧可能是竞争对手（你们竞争的是时间消费）；
市场规模及增长：字面意义，找到细分市场后，快速确定市场规模，强调，这个市场的增长也同等重要，我个人非常反对产品经理依赖于行业报告来判断市场规模（通常我会认为这个产品市场嗅觉和信息探索能力很弱），小的技巧比如看上市公司财报，看新闻甚至看绯闻都可能有高价值信息，并且再强调，市场规模和增长的输出，逻辑是最重要的，数字没有人会猜得对，但逻辑对是可能的。
产品策略（S，Strategy）
知道了你的战场，有了简明战场介绍，有必要输出战法了，这里我特意不称为战略，策略的称呼能够让我们更落地一些。
交付物：Bullet Points（策略点，每一点一句话描述）
我把策略分为两种，一种是资源获取（对外），一种是自身能力（对内）：
资源获取：需要外部的依赖和对外输出的渠道选择，包括商业模式，GTM（Go to Market）策略、红利支持；
自身能力：想清楚自己的长处（底层基础技术？应用技术开发？技术集成？）和匹配的团队组成（清楚描述人数、角色和职责）。
产品迭代（I，Iteration）
如我所说，B端产品的试错成本极高，降低这种风险的“看起来的”唯一办法就是打散这种风险，也就是用敏捷的方式快速迭代。
交付物：一张路线图
迭代图：写清楚在（1年or3年）每一个版本的重要功能迭代，保证你的大里程碑，打印出来放在自己的电脑旁。
产品实现（D，Development）
好了，现在我们落下来做一些实地的工作，把第一迭代的功能拿出来，开始写闻（chou）名（ming）遐（zhao）迩（zhu）的产品需求文档（PRD）。
交付物：产品需求文档（PRD）
产品需求文档：我会放在后面的文章中详述，到底GASID的PRD有什么不一样（当然，也有可能一样）。
快速反馈
所有好的系统，一定是一个有反馈的闭环系统，GASID也不能旁落，当我们输出了第一个版本的产品需求文档后，就着手打磨和细化我们的前四个步骤。市场在变，产品经理的认知在变，产品的目标作为起点，也一定会需要微调。小建议：把产品目标写在白板上，每天花10分钟盯着琢磨，你会发现文字的推敲能够帮助梳理更清晰的产品目标。
关于GASID的一些Tips：
* 不执行不知道规划是否有效，所以我觉得规划也没用：这是一个特别好的“懒政”推辞，所有的规划都有风险（在这里再次diss有以上心态的产品），产品经理一定要有勇气做规划，并且勇敢地在不确定中寻找机会，调整规划；
* 产品目标的调整：产品目标制定在框架内是基石，如果在很短时间内轻易把目标推倒重来，只能说产品经理的判断力真的是太差了……
* GASID与之前框架的区别：在文章开头，我说了希望它是一个能够让产品经理有手感、可执行的思维框架，而不是不落地的产品战略或者太简单的文档撰写（BRD，MRD，PRD，我很讨厌产品经理变成书记员），当然我会继续迭代GASID，也希望能够有牛逼的产品经理加入讨论；
*GASID的执行：用GASID指导自己的思维过程，用GASID的交付物把思维落到纸面，用纸面的交付物说服所有人，用开发迭代实现GASID的设计。
每一模块的解释，我会后续更新，如有意讨论，请联系tongchao@ainnovation.com
