文章内容多半是给自己回顾和总结的。欢迎品尝，褒贬不讳。
毕业一年多，能参与一个产品0-1的过程是很幸运的事情，也是收获非常的经验之旅。
看过我之前文章的同学会知道我是从研发工程师转产品的，转产品的过程并不容易，面试过程磕磕碰碰，最终相上了现在的公司，属于智能领域的。离上一篇总结的笔记已经过去大半年了，一直想说写一篇比较“深”层次的文章，是检验和锻炼自己的一个方法。文章内容多半是给自己回顾和总结的。欢迎品尝，褒贬不讳。
以下将从以下几点进行总结：
如何获得这次机会
产品经理的必备技能：调研、战略及定位、立项、开发进度与需求管理
产品经理的推力：市场与销售的支持
重新认识产品经理
1. 如何获得这次机会
作为一个刚入职不久的产品新人，刚进入公司后负责的第一个比较完整的产品是对公司官网的重新改造。为了更好地完成这次迭代，多次跨部门与市场和销售部门对接需求，通过阅读《增长黑客》让自己在设计网站的过程中思路更加清晰，结构也更加流畅，同时对埋点也更为重视。为了让站点的文案效果更佳（把官网的产品咨询量提上去），加班回家后依然炳烛夜读了《文案训练手册》。
项目上线后各方面反馈都不错，在日常的工作中勇于负责，自我驱动力强。我想应该是基于这些表现，为自己把握住了负责新产品的机会。整个过程下来感觉自己对产品的基础流程算是走通了。但第二个完整的0-1项目才让我对产品经理有了更多的锻炼和感触。
2. 产品经理的必备技能
2.1 调研
产品在决定要不要做以及如何做，都需要通过调研。当然还有一类是领导决定要做这个项目。无论怎么样，产品经理依然需要进行调研和需求处理。
前期的调研首先要进行市场划分，确定主要调研对象再进行需求调研。市场细分是需求调研的前提，需求调研的主要目的是为了避免闭门造车。进行市场细分时，可以请教市场部和销售的同事一起讨论，看现有的客户中是否有与新项目客户群重叠，关联度高的则可列入调研群体，可以省去很多工作。
调研的过程要十分注意一点：客户不能帮我们设计产品。很多时候他们会跟你描述为遇到了什么问题，他们是如何解决的，导致最终我们获取到则是关于“解决方法”的描述，而需求调研者经常陷入这个蜜糖陷阱中。成功的方法可以作为参考，但更多的是要多问几个为什么，追溯更深层的需求动机。调研的方法如何选择则不在此作为讨论。
我们的项目是平台的产品，1.0版本主要是合同客户。前期先通过市场的需求分析得到了需求框架，而后再跟合同客户进行需求的细化对接。由于地域上的问题，更多时候是在即时通讯上与用户对接。大家都了解b端的项目，很多时候产品的使用者其实不是决策者。这不仅会影响到需求调研的结果，还会影响到产品定位以及后续的市场文案、销售等环节。
调研决策者可以了解她们为什么购买，期待达到什么目的。调研使用者可以了解产品哪些方面好用不好用，哪些方面不足等等。决策者通常会偏向关注产品能帮助他们的企业提升哪些效益，而使用者会更偏重于产品功能与体验上的描述。
2.2 产品战略与定位
产品定位是产品经理在大量的市场调研的基础上逐步加深对市场和用户需求的理解，最后在用户需求和市场趋势中找到契合度最高点的过程。产品定位如果是产品经理坐在办公室拍脑袋想出来的，那都是“床前明月光”。准确的产品定位是产品成功的核心。
产品定位不仅是要找到自身的优势，还是寻找论据的过程，同时也是给竞争对手定位，而非一味地互相模仿。产品定位和战略有部分重叠，但战略会融合市场和公司战略，产品定位偏向于产品核心功能和技术。
2.3 产品立项
产品立项要更留意的是关于开发进度，里程碑，技术壁垒以及是否需要第三方平台审核。看似短短的一句话，如果没有处理好，后续可能得花10倍以上的工作量作为代价。这点在我刚负责的项目里，已深有体会。特别是平台审核的坑。
2.4 开发进度与需求管理
开发进度控制
产品在立项时就该定好各个阶段该做什么事情，进入研发后要跟踪好开发的节奏。研发的过程还要考虑人员离职带来的影响，系统bug以及返工等不确定因素。
需求管理
产品是一个需求的集合体，需求管理是产品全周期需要慎重处理的一件事情。建立需求池的其一的初衷是帮助产品经理和开发以及所有相关团队成员来确认产品工作任务的，另外一个是来做版本控制。
可以通过需求卡片或者需求池来存档。需求卡片可以帮助产品经理自身更好的理顺这个需求的来龙去脉，同时也方便产品经理自身快速地“转译”成需求文档给开发团队，需求池是一个集合。需求管理建立起来后，更重要的是对需求的跟踪。如果某个需求被停止或者暂缓等情况，需要及时地备注说明并且邮件通知所有相关人员，确保需求跟进流程都有一个输出结果（验收标准等）。有时候还可以参考“用户故事（user story）”的形式来描述。
3 产品经理的推力
3.1 市场支持
产品在进入开发阶段时，产品经理还得配合市场部进行产品前期（导入期）的产品推广工作，这时候可以简要说明该产品要上市、定位产品等先引起市场关注。到了成长期产品开发也到了尾声，这时候可以进行产品特点的介绍，让更多的用户对产品产生兴趣。产品经理需要提供与产品相关的产品介绍、功能卖点等详情给市场部的同事，在文案定下来过程中还得进行反复修订。
这个过程会涉及到文案的一些要点，但始终要记得使用用户的语言来描述，建议多用数据来说明。数据是从需求文档和测试报告中来的也不是胡编乱造的。如果实在没有，可以结合自身产品定位，参考下竞品。关于产品资料的描述，有一句话说的特别好“试着把产品名称换成竞争对手的名称看看是否行得通，如果同样适用，那么这则文案就是失败的”。站在用户的角度去思考，告诉他们我们的产品能帮他们解决什么，而非我们能做什么。产品资料是给用户看的，是要让用户看完后购买我们的产品，而非炫耀技术、自我满足和陶醉。
产品成熟期则可以更多介绍一些成功案例，迭代期可以多一些品牌上的宣传培养用户对产品的忠诚度。
关于文案的更多干货推荐大家看一本《文案训练手册》，看完一定会有超出惊喜的收获。
3.2 售前支持
对于销售部而言，销售人员关心的是如何帮他们完成销售任务。但销售并不是销售同事自身的目标，准确的说是产品的目标。产品经理有义务协助销售同事更好地销售我们的产品。在产品培训时，可以准备一份ppt等文档或者必要时可以准备一套考题。
售前支持在产品1.0发布后，产品经理需要支持的工作量也是最大的。产品经理可以针对不同的对象准备不同的资料，针对销售的话也可以准备一份《产品介绍》文档以及成功案例。发给销售人员的产品介绍文档可以通过类似这种标签描述“key：用户需求，value：产品功能”适配地告诉销售人员。同时产品经理在与不同对象沟通时，需要用不同的方式和方法，也可借助不同的工具和文档等。后续的许多需求和市场反馈都得跟客服人员和销售以及市场部的同事进行跟进。
4. 写在最后
4.1 重新认识产品经理
项目从0-1的过程，产品经理是有许多工作要参与的。从销售、客服、客户那里了解市场需求和趋势，综合分析产品需求，明确产品的发展方向立项开发。负责产品营销的整个过程，保证产品的市场成功，具体表现在销售支持、市场营销等方面。这个过程，产品经理就像一个齿轮或者中间件，需要通过切合的角度来保证产品从研发到交付使用的过程中没有障碍。
4.2 产品经理务虚能力
“务虚”不等于“忽悠”。
务虚与忽悠的区别在于他是可以通过务实的工作能最终实现的事情。
我们在日常的产品工作做成中会时常遇到这么一种情况：竞争对手在市场宣传过程中会提出一些比较新颖的概念，我们销售人员会经常直接拿来套用到自己的产品上，免费帮竞品宣传，接着还不断地跟产品抱怨或质疑我们的产品。我们的产品经理虽然都指着解释道这些都是概念的东西，但内心也是很焦急如何结合公司和产品的定位提出一个与我们更贴切和相关的概念，反馈给销售人员，进而宣传我们自己的概念。
有务虚的能力也一定要匹配务实的干劲。务虚是相对于决策的环节而言，对事物发展规律与走势的宏观把控，而务实则是将决策执行为现实可行的过程。正确地务虚不应是东施效颦，应该明确出发点并根据自己的能力和立场去设定。写到这里不经又想起了乔布斯老前辈。
产品经理做到一定的程度，其实已经掌握了一种内在的感觉和逻辑即务虚能力。这是一种综合能力的体现，他综合了人性心理和行为以及市场趋势的洞察力、对技术趋势的判断力。通俗地说，就是一种画大饼的能力。但然会务虚也一定要懂得如何务实，从而达成产品战略目标。这是一种心有猛虎细求蔷薇的个人魅力。
4.3 b端产品认知
c端用户是上帝，b端客户不等于用户；
c端的用户群体可以进行各类人性需求／画像琢磨，心理描述。而b端则更注重业务流，工作效率等等（业务流程整合，提高工作效率等）；
b端产品最终目的是帮助企业去完成“生产”，他的成功不仅仅取决于用户体验上，更重要还是在于能否帮助企业“成功”；
b端产品只是买卖的第一步，服务才是这笔交易的核心。产品还需要关注公司内部销售团队、客户方的营销团队，还需要站在完整的产品生态中不断汲取时势更好的服务客户方；
c端围绕着用户迭代产品，b 端产品还需要站在管理层的角度来驱动产品（员工工作量／工作效率等）；
b端，产品业绩上不去，过程做的再好，也无法得到认可，不可能在公司内部产生威信，而产品经理是非常需要威信的；
做b端项目，同样要以用户为中心，以市场为导向。对客户要尊重，对市场要敬畏。
最后摘抄一段话来结束本次的复盘总结：
“产品的灵魂是故事。这个故事在各个层面的含义是不一样的。在需求层面，故事就是客户要解决的问题；在开发层面，故事就是研发设计、调研的故事；在推广层面，故事就是拿下一个个重要的单子，与竞争对手的竞争，以及写文章、策划广告；在销售支持层面，故事是与销售人员一起跑客户，一起并肩作战。所有层面的故事串起来，就是一个产品经理的故事。”
附日常整理的干货：
1.那如果在开发过程中“想”改个设计，怎么办？
（1）学会评估【需求迫切度】
对于目前版本来说是是否需要马上做，还是可以放到下个版本。
（2）怎么判断呢？
如果这个功能不改，是否会使当前版本出现不可控的断点和风险。比如1.0其实还不需要用到验证码，如果在1.0（用户量较少）忘了设计时，其实可以放到2.0再实现的。
（3）非要改的情况下怎么办呢？
1.评估研发难度（plan a,b），再进行分解需求，分拆设计，拆成若干个简单的功能，最后先实现最重要的，把暂缓的放入下个版本（节约工期）。
2.其他需要做的：
有责任感和使命感。勇于承担责任，甩锅是对项目的不负责，甩掉的也是别人对你的信任
明确地分析本次修改的原因。可从需求产生、解决了什么问题、产品经理通过努力已经将影响降到了最低，有何意义等方面，让自己明确该需求的同时也需要让大家都明白，事情是团队而非产品一个人在进行，大家都是驱动者。同时降低大家对本次修改的排斥心理。
总结。总结本次问题，才能不断的驱动自己的成长，减少下次掉坑的风险。
2.如何判断增加一个功能的必要性：
这个功能解决了什么问题，解决之后达到的效果？（功能价值）
此功能主要使用的场景是什么？（用户场景）
竞争对手那里是否有这个功能？（竞品分析）
没有这个功能的时候，用户是怎么去解决问题的？（可替代度）
新增此功能是否增加盈利模式？（盈利模式）
若新增功能的风险点，若发生风险后的相关预备方案？（风险措施）
当前是否有阻碍此功能实现的矛盾？（主要矛盾）
如果新增了功能，到达什么样的数据指标才算合格？（数据指标）
功能的复杂度，如果功能复杂是否需要分期迭代进行？（版本规划）
