普通情况下被别人问起产品经理是做什么的？通常的回答都是：打杂的。产品经理的工作繁杂且精细，许多任务都需要站在不同角度思考，去打磨，所以看似是打杂的，然而我们自己心里非常清楚产品经理具体的工作要务有哪些。这取决于企业的职能分配。产品经理的方向定义也会不一样，分为策略产品、运营产品、功能产品等等。策略产品通常由产品总监、产品专家兼任。大部分产品经理的工作范围在运营、功能产品之间。我们这次主要就运营、功能产品的工作方式做一些介绍。
上图所描述的产品经理职责相信大家都非常熟悉，就算这样还是要再次说明一下，虽然心知肚明，但置身于混乱繁杂的工作任务当中未必就能人人都能做到每一点甚至将其做好。接下来我们就图中每一步骤做一下说明。
沟通分析需求
需求收集
需求收集顾名思义就是收集来自各方与产品相关的需求，根据产品职能不一，收集需求的方式也不一样。
toB产品经理因为有固定的客户，直接与客户沟通对接或通过商务对接需求即可，对接时不可客户说要什么，产品功能就真的规划什么。我们需要不断的向客户确认，如客户要求需要1，那么我们需要思考的客户真的需要的是1吗，或许其实1不是客户的根本需求，客户是否在产品上遇到什么痛点所衍生的1的需求。这就需要产品经理在沟通过程中多做向客户挖掘其根本的需求，从根源解决客户的痛点。否则我们将会遇到以下情况：
产品经常被客户指责功能不完善不好用、体验差，与需求沟通时不一样。（我们常看到的一个图片，客户要求是一座华丽的大桥、产品经理规划出了一座普通的大桥、最终落地则是一座破烂的大桥）这虽然与成本有关，不过产品经理要做的，还是在现有的成本与客户沟通制定出中和的方案是否结果会更好呢。
toC产品经理不像toB产品经理能直接与客户沟通，toC的产品面向于广大的用户群体，向这么庞大的人群确认需求当然是不可能的，一般的手段则是产品经理想象自己作为一个用户在使用产品，YY出一大堆认为对于用户来说真是在完美不过的功能。然而采用这种方式推动产品落地后，有明显的效果也有相反的效果。因为有些产品经理YY出来的功能并没有对用户带来实际的帮助。毕竟产品的使用场景对于产品经理来说是十分有限的。
那么toC产品该怎么做呢，传统做法则是建立种子用户。与“种子用户”直接沟通产品使用的痛点，了解使用场景，甚至一些优质的“种子用户”还会针对产品提出建议。看到个性价比较高的例子：
腾讯动漫的反馈QQ群，腾讯动漫在App的反馈模块下标注添加反馈QQ群号，用户在想要反馈问题的时候可以添加QQ群将问题反馈到客服并且获得最快速的回复；而Q群里抽取较为热心的用户作为兼职客服，帮助用户解决常见问题。
这里大大的提升了反馈模块的功能。毕竟产品经理也知道C端用户较少反馈问题，因为反馈问题通常是没有回应的。所以实在觉得App不好用了，直接将其卸载即可。
竞品分析
大家非常熟悉，一般在产品初期产品经理都需要针对规划的产品搜索出同类产品进行分析，分析其市场份额、战略规划、产品功能、用户数据等等。当然这只是狭隘的理解。我们不止可以针对某个产品做竞品分析，同样在规划产品功能时也可以竞品分析。搜索出同类产品或者同类功能进行分析。主要的目的只有一个，更好的帮助自己规划好一个产品或一个功能。
不管在什么时候，多么着急的情况下，尽量不要省略该步骤。这是为了避免产品经理情急之下自己犯下闭门造车的错误。
技术可行性
记住，在规划功能的同时，如果产品经理自己判断不了功能的可行性，一定主动并谦虚的求教于技术人员。最好能做技术预研（当然是与技术人员沟通出技术方案）。千万不能自顾自规划，等到输出给技术人员时才发现功能不可实现，此时再找出解决方案会非常被动，且容易留坑。更影响产品与技术之间的和谐发展。
可行方案策划
在与技术确认功能不可实现时，应重新规划出新的替补功能。一旦发现重新规划的功能与需求方当初确认的不一致（此类现象常发生在toB产品），需要及时与需求方沟通，获得对方的认同与理解。以便在产品发布时带来不必要的矛盾。
功能脑图
建议产品人员在做产品或任何功能规划前期，借助功能脑图做分析和记录。将功能点列出，尽量详细。有了功能脑图在与需求方确认功能时会稍微直观一些。如果规划的功能不能在一个版本周期内完成需要分类，可在脑图中标明。这样既可以明确项目版本功能，自己也可以为接下来的规划做合理安排。
确认有无歧义
原型评审（需求方）
完成沟通分析的需求之后，接下来将脑图中的功能项细化到原型中（记得加上字段、功能说明），文档一定要详细，包含交互、功能说明、功能限制、异常处理等；都是不能偷懒漏掉的。因为原型文档将作为一次版本功能的记录，并且是提供给技术人员参照开发功能的文档，必须重视。
原型文档完成需要拿去与需求方确认（toC产品可利用AB测试替代），确认需求方在交互、细节处没有问题，则可以将原型输出给技术人员。
原型评审（技术方）
与需求方确认原型细节没有问题之后，接下来将原型输出到技术，并确认其可行性与技术实现是否存在问题。上面提到的在需求分析阶段已经与技术人员确认过部分功能的技术实现方案，这一步才得以顺利进行。没有问题那么技术就可以根据项目组进度按照当前版本的原型进行功能的开发。
条件允许的情况下，原型评审可组织需求方、技术方的人员一起参与评审会议，省去重复评审原型的步骤。
主动跟进负责
项目期间产品逻辑衍生的开发问题确认
就算不作为项目经理，但每天还需抽个时间主动找技术人员确认产品开发期间遇到的问题。通常极少遇到主动沟通问题的技术人员，大部分技术人员在发现问题时会根据自己的经验调整产品逻辑，如果产品人员不及时跟进确认，那么这类问题将延至测试、产品验收时才被发现，那个时候再来确认或根据需求调整实现方案已经晚了，此时由于项目接近尾声，产品经理将会非常被动，要么被迫接受技术实现的方案。
所以产品人员必须掌握主动权，与相关技术人员确认开发期间是否遇到产品功能或逻辑上的问题，并将沟通后的方案同步到原型文档和相关（测试）人员。
项目进度确认
同样的就算不作为项目经理，产品人员也应该每天确认此时的项目进度，及时掌握项目期间的产品问题并快速解决；项目会因为什么问题延期，此类信息必须掌握。以便在项目延期时，及时与相关人员沟通出解决方案，并提前通知需求方项目将因为什么原因而延期，不必等到需求方或上司主动问责时才予以解释，因为这时候锅已经扔过来了。
验收产品并提交验收问题报告/跟进项目修改
产品人员介入项目进行产品验收的时间点都会不一样，有些在项目开发接近尾声，冒烟测试期间；有些则是测试了一两个版本之后。但不管在什么期间产品验收。都需要将验收到的问题一并记录下来，提交给相关测试人员与技术人员。自己也将在下一次验收时针对这些记录下来的问题重新验收一遍。
项目上线邮件通知相关人员（第一时间通知需求方）
项目上线之后，通常由项目经理发出邮件告知大家（如果产品人员作为项目经理，则由产品人员发出邮件）。此时产品经理应发布邮件告知需求方项目已经上线，待需求方验收。
培训或确认需求方使用时遇到的问题
如需培训的功能，记得完成培训文档或PPT，主动为使用对象进行培训。项目上线后toB产品第一时间确认需求方使用功能后的反馈，toC产品需及时查看发布版本后的用户数据、用户反馈，收集问题做下次更新优化。
必须主动确认，第一时间掌握产品遇到的问题与动态。记住产品人员是长期跟踪产品问题与走向的，不该在项目上线后就撒手不管，事务再繁多也要抽时间确认。
归根到底作为产品经理，更多的还需具备责任心、上进心、好奇心、耐心、主动性和不可被磨灭的激情。