从零到一，toB端的产品的MVP阶段结束，总结记录一下其中的得失和思考。小团队，没有很多的方法论，以对具体事情做的思考，做总结了。
1.产品开始前，产品部门一定要里了解产品的商业模式，规划清楚主线功能。能以流程图表示的，一定要做出流程图提供给团队。
2.有改动的时候，一定要先产品内部思考、研究，捋清可能会关联到的所有流程、页面、字段，再去找其他部门的同事讨论。首先保证沟通高效性，另外能让产品部门能对相关改动，做整体规划、资源协调。
3.做减法。产品摸索期，把握业务主线，保证核心业务功能完整的基础上，做减法。快速开发试错。重功能，少花精力在界面、交互细节。
4.产品初期，原型图或者需求评审后，及时与研发确认技术时间节点，列出需要哪些资源协助。初期，出文档要慎重，效率慢且改动可能性大。口述更高效，且便于团队磨合。当然，仅限团队初期。
5.定规矩的文档一定要出。比如统一字段命名，跨部门沟通的东西，一定要出文档，开发有据可依，也防止扯皮。
6.能具体到人的工作，沟通好后，具体指派到某个人负责。一是赋能给别人，二是事情有负责的主心骨后，参与这件事的其他人，就知道可以往哪儿凝聚。
7.产品部门提前练习，怎么把业务流程清晰、准确的讲给别的同事。像要去参加TED演讲一样认真准备，这很重要。
UI
1.出图前：
产品部门也要给UI同事讲业务和背景，便于他们对产品色调定位。
产品要参与UI与研发人员关于出保真图的沟通，帮助确认哪些界面是需要出图的。减少出同类型重复图。提高效率。
2.出图后：
UI出图，产品一定要先把关，确认界面风格不跑偏，确认重要位置处图片的质量和防止遗漏。
面对决断性不强的UI同事，产品部门需及时跟进，首要做鼓励和赋能，告诉他们会尊重他们在专业领域的判断，实在不行，产品部门再参与确定图片样式。
1.很多时候研发拿着草图就开始写代码了，边开发、边催要图的情况比较多。这样开发是高效，但是容易埋下天坑。所以，一开始，产品部门逮着沟通机会了，就要给研发多讲业务流程。确保研发的主线不跑偏。
2.抓异常。研发同事大都逻辑严谨，很容易在实现业务中找出问题。
这儿产品部门就得注意，不可深入掉入到异常处理中。凡是不影响主线业务的异常，都做简单处理。非常规操作引发的问题，不处理。 一定要时刻围绕业务主线做事。
关于问题，建立bug池，排出优先级。让提问题的同事知道已被记录——任何同事的参与感和被尊重感一定要有。同时还要给他们讲主线业务是做什么，优先处理影响业务主线的问题。
3.提供给研发部门的文档。
有时花两小时出需求文档，还不如拿凳子坐研发跟前，告诉他要修改的需求。文档只是表达形式，我们要的是效果和效率。而且从平时聊天就知道，大多数研发是不乐意看需求文档的。原因不做分析了。
开发文档处理方法：记录事件节点、定规矩、容易出现扯皮的文档，一定要出。
界面交互处理方法：a在草图上加注释进行处理，b原型上加入交互效果，c面对面讲。
数据库表单处理方法：（掉过得坑）拿出来说一下。这儿产品要做的是——整理新增或者功能改动时，可能会出现的牵连性改动（产品自己心里没谱的也算），讲给开发听。能让数据库这边分析、先行准备。要是真有数据库改动的话，这块提前沟预知过，就能为后面技术开发，提高巨大的效率。
一些想法
目前对产品岗位的一些理解：
要兼听则明，从各个角度、角色去分析问题。会做取舍，这很重要。工作重心一定要落在产品核心业务流程上。
对产品，对事情，有担当，负责任。规划总是很好，但回归现实，大多是要做落地性事情。出现错误了，自己的锅就主动背，别人的锅，合理范围内，尽量减少别人的尴尬。不要逃避责任，做产品岗，一定要有责任心和肚量。
关于沟通：能把别人话里的意思，快速、准确的提炼出来。能把自己的想法流畅、准确的表达出来。沟通、交流事情的同时，也能照顾着别人的面子。达到这三点就够了，不要把沟通能力想的太玄乎。
作为产品经理来说，一定要学着赋能。二八定律在哪儿都适用。但如果懂得协调、调动队友。有时候他们迸发出的能力，也很惊人！！！~
生活就像盒子里的巧克力，你永远不知道下一颗你拿的是什么。产品也一样，what we can do is keep moving.
