实战：B2B端产品经理工作指南

作为产品经理，你是产品的主导者，但所有的市场行为、迭代行为一定是所有人都认可的，投入是有价值的。比如你是为了PK对手而增加的功能，还是为了提升市场竞争力，还是为了满足售后服务需求，当然你得组织评审讨论下。当然，小团队敏捷开发的话，以实际客户需求和行业需求为主。

我自身的工作指南如下：

• 初步评估和记录产品原始需求点。占比25%。

• 讨论产品原始需求，定义产品需求池、产品迭代、产品开发、产品商业。占比35%。

• 对原始需求讨论，归类优先级，还有投入产出价值比。占比25%。

• 输出产品设计需求，归档。占比15%。

2.3 根据产品需求，定义产品原型

原型这个词就不陌生，需求定义清楚，就要开始原型化设计。大多数的原型都包括低保真设计、有高保真设计，甚至还需要需求文档一说。大都只归结于一点，能够很好的描述你的需求。

现在，行业有个怪现象，产品经理过度执着于原型的设计，过度执着于文档的书写编制，求职者也过度执着自己对原型软件的技能。产品原型可以是有纸质手画的、有直接口述的、有PPT编制的、有专业软件制作的（诸如Axure、mocplus之类）、有播放视频的方式、有对手的上线版、有行业的测试原型等等。我个人觉得，输出的方式有很多种，选择适合你的需求展示，以及开发同事认可的方式。

我自身的工作指南如下：

1. 设计产品的输入输出，形成产品概要原型。占比35%。

2. 思考原型设计的方式，最符合当前需求的原型展示。占比25%。

3. 借鉴竞品或行业同类产品的交互界面。占比10%。

4. 初始原型讨论，定义和完善。占比25%。

5. 最终原型确认。占比15%。

2.4 进行产品概要和详细设计

这是谁的活一直都有争议，有说是产品经理的工作，有说是开发人员的工作。我个人觉得各占一半均衡一点，也不完全偏向哪一边。产品经理最好是要主导产品的概要和详细设计工作，细节内容可以由开发人员、产品经理、测试人员等共同商讨确定细节设计方案。

我个人就会偏向于功能、架构侧方面的参与：一是我的需求点的明细，二是我对产品迭代的要求。

我自身的工作指南如下：

1. 拟写产品需求功能书或规格书。占比30%。

2. 给开发、测试人员详细介绍产品需求点。占比25%。

3. 对核心功能加深商业场景设计（目的是让开发了解功能的延展性和商业性）。占比10%。

4. 主导需求功能侧的概要、详细设计评审。占比20%。

5. 参与开发、测试人员评审会（包括概要设计、详细设计、测试计划等评审）。占比15%。

3. 产品开发管理

产品的开发管控有时候是项目经理或研发经理在负责，但绝大部分都是由产品经理进行主导把控的。所以我觉得，产品经理要有参与到开发过程中的耐心，要有跟开发人员、测试人员互动的过程，这就很重要了。过程的开发把控，实际开发情况的风险把控，以及需求完成的把控，这些对产品按时上线都是至关重要的。

这一块我的工作指南一般会按照以下几个内容来完成：

3.1 梳理产品Roadmap，明确迭代开发范围

有很多人或许会问，定义产品Roadmap的价值点是为什么，作为产品经理只需顾好当前的需求就行。但是，很多坑就是这样被产品经理埋下的，当然后面还得你自己去填坑。一个好的产品经理，首先站的角度一定是企业，其次才是用户，想歪了你就不是一个合格的产品经理。这种话不是废话官话，而是在跟你阐述你给自己在企业的定位，跟着企业发展走，你的产品才能走的更远。过度沉溺在自己的产品世界里，早晚会吃亏。

我自身的工作指南如下：

1. 梳理产品Roadmap计划。占比15%。

2. 将产品需求录入需求Backlog，定义Sprint。占比25%

3. 对开发需求进行优先级排序。占比15%。

4. 讨论任务细分、人员分工（不超过两天）。占比15%。

5. 确定迭代计划功能，启动sprint。占比10%。

6. 甘特图追踪任务进度，关键时间节点区分。占比10%。

7. 明确化迭代开发内容，时间安排及发布时间。占比10%。

3.2 负责迭代开发的过程管理

整体开发的过程管理包括启动过程、计划过程、执行过程、监控过程、收尾过程等诸多方面，作为产品经理，要能在每个环节融入到开发团队去，做好开发、测试、运营的配合，才是一个合格的有产品心的团队。

但是，或疏于自己工作职责划分的缘故，也有产品经理会置之这一块内容。现在网上有很多人在讨论开发与产品的矛盾，还有偏激的看法，但实际你是不参与实际的开发工作，而是你的角色从主导者变成了配合者，你参与的只是开发过程中的过程管理。还有，这个过程不等同于任务进度管理，也不同等于产品开发管理。

我自身的工作指南如下：

1. 每1周或2周按Sprint更新任务进度。占比20%

2. 组织每日晨会：昨天的工作，今天的工作，遇到的问题。占比35%。

3. 检查任务迭代情况。占比20%。

4. 控制迭代范围的变更。占比20%。

5. 其他事项管理。占比5%。

3.3 验收需求的实现情况

产品经理有验收需求的标准，是有助于大家对目标需求的一致理解、对目标需求的最终确认、对目标需求的实现验证。当然，需求实现的验证是通过测试来实现的，产品经理要最终根据预先需求定义以及给测试传递的预期结果进行划分和充分结合，验证和确认需求的完成度。必要时，还需要上线试运行，或者由客户来试运行测试和验收需求。

我自身的工作指南如下：

1. All tasks closed。占比20%。

2. 功能演示，核对产品功能。占比40%。

3. 确认功能符合预期。占比20%。

4. 迭代回顾会议，总结存在的问题。占比10%。

5. 下一步需求验证计划。占比10%。

4. 产品发布管理

（编辑：青岛站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!