产品工作基本流程

我的博客即将同步至腾讯云+社区，邀请大家一同入驻：https://cloud.tencent.com/developer/support-plan?invite_code=2p5qjwxvujms4

产品工作主要分为四个阶段：

立项阶段，包括市场调研、产品规划；（发现需求） 需求阶段，包括需求收集、需求整理、文档输出、技术讨论；（寻找解决方案） 开发阶段，包括项目跟进、项目发布； （实现解决方案） 运营阶段，包括数据统计与分析、意见收集、活动运营。（让有需求的人使用和持续改进） （注：一般性项目需求基本可从“需求阶段”开始）

整个流程中各个角色负责的基本工作如下：

立项

产品经理工作流程中的“立项”阶段主要解决产品该不该做、为什么做的问题，分为市场调研、产品规划两个部分。

所谓产品该不该做即产品与服务所对应的目标对象是否有相应的需求，提供的产品与服务是否能满足相应的需求。

当然，以上定义即使回答都是肯定的，产品与服务也不一定可以去做，这还要看目标对象或者市场是否足够大，这里的“足够大”取决于你的资源量。比如，一个小区的居民需要购买日用品，一个个体户可以提供一个小商铺（产品）满足居民的需求，同时自己能够过活，对于个体户来说这个社区的需求是足够大的，但对于一家可覆盖多个小区的超市来说，一个小区的需求则是不够的。

关于“市场调研”： 市场调研是发现潜在市场需求的过程，所做的事包括：

目标市场发展趋势调研，分为三种市场：现有市场、细分市场、新兴市场；
新技术发展趋势调研，可运营的技术至少不会被淘汰；
自身与竞争对手分析（如：SWOT分析），市场主要有那些竞争对手，他们的突出优势是什么；
注意：

对于已被淘汰的产品或者服务，要分析其相关的失败经验；
对于尚在人间的产品或者服务，可以通过什么方法超越；
现有产品或者服务是否可以改进与创新。
关于“产品规划”：
产品规划是产品定位、用户需求细分阶段，所做的事包括：

产品定位，做什么样的产品或者核心功能；
a. 面向哪些用户（目标市场）、用户特征是否具有普遍性（分类）；
b. 解决用户什么问题，这些问题是否具有普遍性。

确定产品目标，期望产品是什么样子，量化的指标是什么；
a. 产品的路标规划（大目标的拆分）；
b. 初步进行资源和时间的分配。

初步的产品运营规划，要完成相应目标采取什么运营策略；

关于输出物 输出《竞争及市场分析文档》 输出《市场需求文档》

产品满足用户的哪一个核心需求； 与同类产品相比你的独特性是什么； 分解用户。根据产品的核心价值，将用户分解成不同角色； 变成用户。每类角色回答两个问题：该角色为什么会使用此产品；该角色该怎么知晓和到达这个产品。 确定角色成就。确定产品如何满足不同角色的成就感； 确定用户需求满足过程中的关键点； 提升关键点的转化率； 形成闭环，让产品能够自我成长； 大干快上，快速迭代。

需求

产品经理工作流程中的“需求阶段”主要解决产品要做成什么样，怎么做的问题。

经历了上一阶段对需求的可行性评估，在这一阶段需要整理、细化需求，使需求成为团队成员（不仅仅只是开发）能够看懂、实现的充分依据*（也许以后还会讨论需求文档是否真有必要？）*。最后还需要与团队成员细致讨论，确定开发进度与里程碑，以在后期充分把控项目进度。

这一阶段可分为三个部分：需求收集、需求整理、需求评审。

关于“需求收集” 规划阶段对产品（服务）基本的核心需求已经有个初步的收集，但随着产品的深入思考和讨论，会源源不断产生新的需求点，在这一阶段收集的时候可以先不考虑需求是否可行、是否有意义，只要尽量收集就好。

需求的来源可以有以下方式：

现有产品优化；（用户使用时产生的不爽）
逻辑缺陷；（缺陷需要迅速解决）
用户的反馈；（用户调研，包括内部与外部用户）
竞品分析的成果；（抄袭？微创新？）
管理层提案；（可能是无法拒绝的）
合作方提案；（与外部合作，可能有个性需求）
数据分析结果；（增长黑客？）
创新。（产品差异化）

关于“需求整理” 需求整理主要是对之前收集的需求进行分析，确定优先级，并细化成文档的过程。当然，同时还涉及到运营计划的拟定，所需资源的预估。

具体工作如下：

需求条目的整理与管理，根据需求需要消耗的资源、紧急程度、重要性确定需求优先级；
由于资源的有限性，需产品小组内部讨论，确定当前版本可做需求（如果是合作平台项目，需与合作方充分沟通相关要求）；
细化需求：
需求的背景与目的，为什么要做；
具体功能点的逻辑、流程、规则等；
项目涉及（影响）的平台、渠道、功能等；
数据统计与其他非功能性（服务器、后台）需求。
与运营人员拟定初步的运营计划，开始着手准备可能的运营素材；
预计需要支持该产品的部门（团队成员）以及可能的经费、物资预算；团队成员大概分工：
项目产品经理，协调各方面资源，及时输出文档；
项目经理，协调开发进度，制定里程碑；（许多公司由产品经理兼任）
项目其他成员，评估各自任务，过程中与产品经理及时、充分沟通。

注意：

有限的资源包括技术资源（前端、后端、测试）、设计（界面、交互）、编辑（文案）以及推广资源等；

交互设计和界面设计工作要尽早开始，以便有时间空间调整；
内容资源主要是内容运营人员所产生的文案内容；
推广资源也需要及早收集汇总；
较大项目发布需保留旧版本入口，避免因新旧版本反差较大造成用户投诉。

关于需求评审 需求评审一定程度上决定了产品工作能不能愉快的进行下去，就好比战时出征前的誓师大会，搞得好士气将大增，搞得不好那…需求评审需要达到几个目的：让团队认同产品、说明产品功能点、明确分歧点、确定时间点。表面上的工作如下：

通过邮件召集项目需求评审，邀请项目相关人员进行评审讨论：
由产品经理讲解需求，技术同学评估；
针对分歧点进行讨论，确定解决方案；
项目经理确定各部分负责人与相关排期。
会后根据讨论点对需求进行迭代优化（同时更新文件存档）；
项目经理确定项目相关里程碑与时间点
项目计划须由项目经理最终确认，并最好通过可记录的方式（比如邮件）通知相关人员；
里程碑是指诸如“技术预研结束”、“架构设计完成”、“测试、发布完成”等项目关键点的完成时间；
开发计划一旦发布，就必须按照里程碑去定时检查是否完成；
如果开发进度有变动，无论提前还是推迟，都必须在开发计划邮件中进行补充说明。

为什么说以上是表面上的工作？因为要让团队认可产品不仅需要产品本身确实是可以满足用户需求的，在内在方面则要求产品经理本身的个人说服力也能潜在影响团队成员对产品的认同度。

关于输出物 包括以下文档输出（部分文档可能部分项目暂不需要，输出的文档最后进行共享、备份）：

★★★《产品需求文档》，把功能分类进行详述，需分版本； 《UI/交互设计文档》，主要涉及原型图和交互稿； 《统计需求文档》，项目涉及的数据统计需求； ★★★《需求评审会议纪要》，主要涉及会议决议、项目计划、团队成员等信息； 培训材料（内部交流所需，ppt）。 --------------------------------------正文分割线----------------------------------------

关于产品部/个人文档存储、共享规范，下面有一个简单的案例分享：

文档存储文件夹结构图

文档存储文件夹结构如图所示； 使用员工分类是避免各自负责的项目相互影响，同时便于个人管理，若出现人员离职情况，可直接将该人文件夹中的文档移至“历史文档”； 共用资源可放一些工作会用到的文档，比如预算、运营流程、产品流程、公司规章等； 每个人下面会有n个项目和一个公共资源（包括每个项目可能用到的数据等内容）； 如果是大项目可能还包含若干小项目以及需求、原型、运营资源、设计稿、交互稿以及其他文档； 文档名称规范建议： 项目（作为项目文件夹名）：[类别]项目名 需求文档（或其文档）：[项目名]需求名_时间版本（或标准版本号）（如：[豆瓣主站]豆瓣市集项目需求文档_v20150630） （付）图片：[项目名]需求名_尺寸。（如：[豆瓣主站]豆瓣市集首页宣传用图_360*200）

开发

产品经理工作流程中的“开发阶段”主要为产品实现阶段，产品经理在这一阶段需要进行进度把控、资源协调，并最终完成产品的发布。

这一阶段，将其称之为**“产品经理黑盒”**，因为对于产品经理来说，并不用关心也无法清楚的知道产品实现的具体开发细节、测试细节等，而只需要关注最终的输出物在功能、界面、逻辑上是否符合预期与要求。

这一阶段可分为两个部分：项目把控、产品发布。

关于“项目把控” 产品经理在这一过程中虽然主要工作是跟进、协调，但也还有一些额外的工作需要准备。

产品Q&A文档，主要用于对应产品后期的培训或者客服解答用户疑问需要；
产品与竞争对手同类产品的对比（性能、效率等），提炼产品优势，把握后期推广点；
以前期准备的初步运营计划为基础，与运营同学细化运营工作内容。

项目跟进、协调工作部分：

这一部分工作主要考验产品经理的沟通和协调能力。

设计稿、交互稿跟进与确认，设计输出物需要及时确认与评估，快速修改、完善；
开发进度跟进与确认，对评审确定的时间点要及时梳理；
跟进开发进度，与开发同学沟通功能细节；
协助项目经理对里程碑进行检查；
协调各方资源的合作与沟通，做好桥梁。
测试跟进，对主要流程和可能出现的问题进行体验，结合需求：
在测试环境对整体项目稳定性进行体验、测试；
对可能影响到的功能、后台进行体验、测试；
对统计数据进行体验、测试；
对于客户端需对旧版本兼容性、升级后数据稳定性进行体验、测试；
对涉及平台、渠道进行体验、测试。

注意：

在这个过程中可能出现需求变更（应尽量少）以及未考虑到的问题（当然，这要求在需求整理阶段尽量想全），应做到

针对可解决问题与变更，适当调整功能流程；
针对不可解决问题，应及早反馈与沟通，并及时调整产品策略；
如果可能尽早发给业务、客服部门提前体验（特别是活动项目）。

关于“产品发布” 产品发布意味着产品正式与用户见面，需慎重、慎重、慎重！

产品发布前需与运营同学确定推广方案与计划，细节：
广告图，需提前一周提设计需求；
用户触达应根据计划提前作规划；
需要的文案根据产品优势提前准备好；
新闻稿也需与编辑提前准备。
产品发布之前（最好提前三天）应周知各相关部门，特别是对客服同学的培训与通知；
周知需求提出方；
周知项目改动可能影响到的功能负责人；
周知业务部门。
对于合作项目涉及到联调时间，在规划上应予以考虑；
确定产品发布的用户范围：
部分发布需确定发布规则，可针对用户地理位置或者条件是否满足进行发布；
全量发布，针对所有用户范围。
注意：
	发布时应关注用户反馈，简单反馈应及时迭代；
	检查数据，发现异常应及时分析原因并解决；
	较大项目发布需同时保留新旧版本，避免因新旧版本反差较大造成用户投诉。

关于输出物 包括以下文档输出：

《产品体验文档》，描述体验环境、问题、修改建议；
《产品Q&A文档》，描述产品功能、使用帮助。

运营

产品经理工作流程的“运营阶段”所要做的主要是配合与总结，并为下一个产品循环做准备，当然这个前提是你所在的公司将产品策划与产品运营做了明确的区分，如果没有，你可能还要关注“产品运营的工作流程”。

所谓“配合和总结”：即配合好运营同学做好运营工作，同时需要通过各种数据和各渠道的反馈来了解这个上线的产品到底对用户有没有用处，用户究竟有没有去用。如果用户用了，那么要考虑如何让这个产品更好用；如果用户不用，那么要搞清楚为什么不用，产品是否有问题。

这一阶段可分为三个部分：运营、意见收集、数据统计与分析。

关于“运营” 运营的工作本身已经足够写很多篇长文进行介绍了，在这里笔者只是简单介绍一下基本的概念与工作内容。

所谓互联网产品运营简单来说就是“找到产品的目标用户，通过各种有节操无节操的方式将用户吸引来使用产品，然后维护与留住用户，同时时不时愉悦一下用户促进其进行消费（消费型产品）或者创造价值（UCG产品），并对沉默用户进行激活。”

从以上概念可以看出运营的基本工作内容可以分为五个部分：

找到产品的目标用户；
吸引目标用户使用产品；
维护与留住用户；
保持用户的活跃度；
沉默用户激活。

不同的产品类型在每个部分都对应了不同的衡量指标，而评估运营工作质量的好坏，则是看在不同阶段对应的指标是不是达到了相应的预期目标。

粗看产品策划主要跟产品玩，产品运营主要跟用户玩，但其实产品策划与产品运营的工作是相铺相成的。没有好产品再好的运营也没人用，没有好运营在好的产品也无人问津*（写这句话时有点虚，要知道神一样的产品和运营都是有的！）*，同时作为策划和运营都需要“了解产品、了解用户、了解市场“，并为统一的公司目标共同努力。

关于”意见收集“ ”意见收集"是产品需求的一个重要来源，可能包括用户槽点（需要改进）与用户创意（新功能），需注意以下几个方面：

用户并不知道自己需要什么，他所说的并不一定是他想要的；
用户的个性想法很多，但你面对的是用户整体；
可以迅速解决的问题，需要马上解决。

意见的来源，可见：

产品本身具有意见收集功能，可进行意见收集；
通过合作渠道、公司内部人员进行意见收集；
通过社交网站、社区论坛进行意见收集；
通过客服、运营以及市场同学进行意见收集；
通过数据分析结论进行收集。

关于“数据统计与分析” “数据统计与分析”从产品设计开端时就应该作为重点考虑的“功能”，为了让产品有据可循，而不是头脑发热的产物必须做好产品关键流程与产品目标数据的统计与收集。产品发布后，所有的数据都将是验证产品好坏的直接证据，通过分析这些数据及时作出总结与下一步规划是一个出色的产品经理必备的素质（重要！这里自行脑补3遍）。

做好这一步的大目的：

明白产品的缺陷，为下一步改进做准备（工作上的，重点）；
扩大自己在团队中的影响力，为后期工作铺路（团队上的，请意会）；
让领导知道你做了什么，个人工作评估为数不多的依据（个人上的，请意会）。

小目的：

在产品各个时期发现产品问题，及时改进；
为后期迭代产品积累原始需求；
快速配合运营工作，提高短板数据。

数据统计与分析本身也属于一个大的工作项，这里不做详细描述，只是建议产品经理需要有数据思维，把看数据作为每日的工作习惯，及时从数据中发现问题，并跟进解决问题。

关于输出物 包括以下文档输出：

《运营计划》，描述产品的主要运营规划；
《意见收集资料》，简单罗列用户意见与初步分析；
《产品数据分析》，通过一段时间的运营，分析数据得出结论与后期计划。