出品：晨读堂-唱歌

欢迎大家投稿晨读班，邮箱地址：mm@.com

我从事产品管理工作一年多了，却一直饱受这样或那样的困惑。很多人想从事产品管理，或者老板创业时想自己担当产品岗位，但对产品岗位的认识很模糊。有的认为就是纯粹画原型，有的认为就是做项目管理跟踪项目进度，有的给老板做竞品分析。其实这些都不是产品经理的核心和重点。在比较成熟的公司，由于产品的增长，人员的增多，为了方便协作沟通，岗位会清晰细化，比如产品经理、交互设计师、UI设计师、用户体验分析师、数据分析师、运营等。但创业公司的产品经理往往身兼数职，创业公司追求最大效率、最小成本，没有精力把岗位划分得那么细。下面，我将以创业者或者负责一个产品项目的产品经理的角度来审视整个过程，看看一个产品经理从零开始需要做什么。

从产品概念到输出到流程

项目开始前

做任何事情之前，都要先考虑背后的用户需求、商业价值、技术难度。用户有需求你的产品才会被使用；商业价值确立了才会给公司带来利润，毕竟公司最基本的目标就是盈利；整体技术评估可行，整个项目才能落地。如今的互联网创业公司，大家都在追求“速度”，2个月融资，4月用户过百万，3年纳斯达克上市。然而，这都是别人创业成功的表象，殊不知，做任何事情的前提，都是要明白自己在做什么。当然，也不排除有些胆大包天、运气好的人，随随便便就能成功，但那只是个例，不值得深究。

1. 用户需求

1.1 产品定位

在项目执行过程中，我们经常会陷入一种情况，一堆人聚在一起，讨论的气氛很情绪化。A说这里的按钮不好，B说这个地方要像别人的APP那样做，C说你们都错了sketch windows，这个模块不能换成这个。频繁参与这样的讨论会极其耗费时间和体力，几个小时过去了，但会议一结束，就没有结果。大多数情况下，一定是产品定位有问题。执行的人要清楚明白这个产品是用来做什么的，给谁用的，才能正常讨论具体的细节。如果兴致勃勃、气势汹汹地讨论了半天，发现没有结果，会议讨论偏离了方向，那不妨回归本质，思考一下我们的产品定位是什么。

产品定义：

产品定位包括两大内容：产品定义和需求定义。产品定义要分析的内容包括产品的用户群体、主要功能、产品特色等。

比如说，如果你想创业，开发一个移动招聘APP，产品经理首先要做什么？中国每年的就业人数非常庞大，行业也是多种多样的。所以你得想清楚你的产品是服务什么样的人。如果要服务所有行业的人，那是不可能的。首先，一个小公司很难把这么多行业的招聘信息整合起来。另外，并不是每个行业的人都这么容易接受互联网。

通过数据分析和调研我们发现，现在国家鼓励创业，创业高峰期必然会产生大量的人力需求，尤其在现场，几乎所有的创业都和互联网有关，从事互联网行业的人对APP的接受度也很高，至少愿意去尝试。所以你把互联网行业从业者看成是你产品的用户。

你分析了其他招聘APP之后，发现这些APP都存在很多问题。比如我想在北京西二旗找一份工作，但是目前很多APP都没有职位筛选；虽然可以应聘国外的工作，但是得到的反馈很少；公司信息太少，无法了解；在申请成立之前，作为求职者，你很想知道这家公司的老板是谁；现在是互联网时代，电子简历完全没问题，为什么招聘人员每次招聘都要打印简历呢？你应该知道打印简历对于求职者来说不是很方便，因为随时可以改，对求职者来说非常不方便。于是你打算做这款APP，它的特别功能有1、职位支持公司所在地分类；2、招聘人员要时时给求职者反馈；3、取消纸质简历。主要功能就是招聘。现在我们将这款APP命名为飞哥招聘。

需求定义：

需求定义分析包括三个方面：目标用户、使用场景、用户目标。目标用户就是会使用你的产品的人群；主要功能是指你的产品是用来做什么的，是工具、社交还是其他；你的产品和市面上其他产品有什么不同，这就是产品特性。

刚才我明确了APP的适用人群、主要功能和产品特色，市面上有些招聘APP是猎头，专门针对想要跳槽的人群，你们APP的目标用户是谁呢？通过特色功能和用户痛点分析，分析出产品的目标用户是想要在特定地点找工作的人，比如已经落户北京后沙峪，希望到望京工作的人；当你刚刚搬到回龙观，面临工作变动，可能会倾向于到西二旗找工作。

1.2 需求分析

上面都是关于产品定位的，完成这些之后，接下来就是竞争对手分析和用户调研，一方面这是对我们的需求的一定验证，另一方面也是我们直接接触用户，看看他们有什么需求的机会。

1.3 需求筛选

前期需求筛选是一件非常困难的事情，如果产品经理自己就是老板，头脑清醒的话还好。但是讨论的时候很容易卡在海量的需求中，跑题。讨论完之后觉得什么功能都需要，这个功能有用，必须加；那个功能好玩，用户一定觉得有意思。这些话永远是基于个人主观臆断的sketch windows，往往当时听起来很有道理，但事后推敲起来却经不起推敲。所以，我们需要时刻把握自己的产品定位和优先级，千万不要盲目地在这个方面做出很多无畏的牺牲和挣扎（少做不假思索、仓促决定、不假思索的决定）。

需求记录表：

在前期需求筛选的时候，会出现很多需求，有些需求我们并不能立刻判断为好的，这些想法可能会成为我们以后产品迭代的灵感，给产品的开发带来更广阔的思路。做好管理，尊重大家的想法，有歧义的地方及时记录下载，对会议的推进和进展会有很大的帮助。

2.商业价值

市场需求文档和业务需求文档一般在大公司比较成熟，小公司大部分决策都是老板自己做的，老板可能不会做这个那个文档，但是一定会做基础了解，或者自己对某个行业非常了解。这两个文档既不冗余也不累赘，在项目开始前花点时间深入理解行业和用户是非常有必要的。具体的文档细节这里就不细说了，网上有很多参考资料。

3. 技术评估

作为一个非技术出身的人，我就不多说了，尊重开发者，和开发者搞好关系，对产品的推广很有帮助。

项目正在进行中

前面我已经讲过，一个项目开始前，需要关注的三大方面：1.需求；2.业务；3.技术。这些准备工作做好之后，接下来就是执行。执行的过程没有之前那么宏观，但需要你足够细心和耐心。

1. 产品层面

需求生成后，产品人员就可以立即制作需求文档了。需求文档对后续的交互设计（在创业公司往往由产品经理承担）、UI 设计等都起到了关键作用。当然，在生成需求文档的过程中，如果有专职的交互设计师，最好在需求阶段就与产品人员讨论需求文档的细节。这样有助于交互设计师了解整体需求，对其制作原型、编写交互说明也会有很大帮助。

需求文档一般包括以下几个方面：

背景描述：为什么要上线这个项目？能为用户解决什么问题？能带来多大的价值？这是对项目上线前所做工作的总结，一定要简洁明了。

用户画像：提供用户特征的虚拟描述，明确用户情况。

项目时间规划：什么时候出原型？什么时候出真正的设计？什么时候开始开发？什么时候开始测试？什么时候提交应用商店？这些都需要明确。否则，如果没有时间观念，一切都会拖拖拉拉，没有紧迫感。

信息结构图：APP的内容组织结构。下面以微信为例，简单给出微信的基本结构。

任务流程图：对于APP中的主要功能，从头到尾梳理用户整个流程，把各种可能都考虑进去。不然后面开发者遇到问题问你，你就得重新考虑了。更要命的是，开发者没问你，就开发了，结果还不是你想要的。我们以一个简单的登录为例：

需求描述：清楚的说明每个操作的条件和结果。能用文字说明的就用文字。如果不清楚，最好用图片。有人可能会说，这时候没有线框图，怎么解释呢。这个不矛盾。早期的需求文档是用来做交互的（再次强调，创业公司的产品也可能是需要交互的）。交互设计师会根据你的功能结构和流程梳理，设计线框图和高保真原型。

数据跟踪：把后期需要检查的数据列出来，比如这个按钮的点击率，这个页面的打开率等等。这时候就需要跟运营多沟通，明确需要跟踪的地方。这对产品上线后的数据分析很有帮助，数据也能辅助产品功能的迭代。

2.交互设计

需求梳理好之后，接下来就是设计并制作线框图、页面流程、高保真原型、交互说明等。高保真原型是根据具体情况来定的，有的公司有要求，有的公司没有。

2.2 线框：

尽量把每个页面的视觉效果表达的简洁、清晰。这里最好不要加交互，也不要弄得花花绿绿的，黑灰色最好。每种情况都是一个页面。用一个页面表达每种情况，一方面你会更清楚APP整体的界面数量，设计师也知道你想要什么。否则，你加交互，设计师不知道怎么点，你还要解释半天。

2.2 页面流程图：

和前面的信息结构图类似，页面流图也是利用各个页面来做连接，使得各个环节的衔接和跳转在视觉上更加清晰。

2.3 高保真原型：

对于交互的要求会更高，需要把各个功能之间的交互展现的比较完整，尽量在视觉上还原真实产品的面貌。（关于Axure，可以学习金吾的课程，很不错，很多人觉得太罗嗦，但是认真看完还是会收获不少的。）

2.4 交互说明：

我个人觉得交互描述和高保真原型是有重合的，如果你做了高保真，那么大部分交互动作基本都能展示出来，但是有一些交互效果是软件无法处理的，这时候就需要用到交互描述了。

如果不需要文字或者图片的解释，直接用纸来模拟就行，不要小看这个方法哦。

这里介绍几个可以进行交互式标记的工具：Mac 绝对是其中之一，有，圆圈，和，而且 viso 也可以进行标记。

3. UI 设计

一般来说，交互设计师会把线框图交给设计师，设计师就可以开始工作了。在这个过程中，交互设计师应该多和设计师沟通，毕竟UI设计师会有自己的专长和设计见解，这很正常。

四、项目实施情况

设计完成，交互工作完成后，就要交给项目经理去执行了。目前这个角色只存在于大公司，一般由产品经理担任。这里要注意的是，在执行之前，必须建立各种相关规范。例如：

4.1 apk和api文件的命名规范及不同类型安装包的管理：

这些都是我的亲身经历，做好这些对以后安装包的管理会有很大的帮助，我们当时搭建了一个开发者环境，这个环境里的APK和API文件只能在局域网内使用，在这个环境里你可以任意折腾、测试，不会影响已经启动的应用。

开发者环境打包出来的安装包图标和名字应该和线上环境的应用不一样，以后继续测试的时候就不会因为版本不同而手忙脚乱了。

4.2APK及API文件管理

4.2.1 开发版本：供个人开发或者产品使用，其他无关人员不会接触此版本。 网络环境：只在特定网络环境下使用（需技术人员搭建环境）。

4.2.2 公测版本：经过产品和测试人员的详细测试，基本没有bug，可以供公司人员使用，也算是上线前的稳定性测试。 网络环境：只能在特定环境下使用（需技术环境搭建）。

4.2.3 商店版本：准备提交到市场的APK和API文件。开发版本和公测版本经过全面测试，所有不稳定的Bug都消除了。此时打包好的商店版本仍然需要经过测试人员的检查。最后一定要确保准备上线的APK和API文件已经经过测试人员的检查。否则，如果开发者在没有通知测试人员和产品人员的情况下进行更改，上线后再更改就来不及了。

5.APP测试及版本号管理

版本号的管理一定要在前期就搞清楚，不然产品上线之后，出现需要改进的 Bug，或者新增功能对旧版本造成影响，这时候好的版本号管理就会发挥很大的作用，一方面可以随时找到之前上线过的 apk 和 API 文件，另一方面面对不断修改的打包文件也不会手忙脚乱。

以下为个人观点，如果有哪位高手有好的方法，欢迎分享。版本号永远是唯一的，是迭代进步的，不要为了上线好看而刻意干扰版本号，严禁有多套版本号。

测试说明：

在UI、交互、产品开发阶段，要多和技术人员沟通，最好把大功能分解成小的功能模块，每完成一部分就通知相关人员检查，避免问题积累太多，最后修改太多。UI负责看开发是否按照你自己的设计实现，交互负责关注交互效果是否符合你的标准，产品负责关注每个功能的实现是否正确。

测试用例：好的测试用例可以有效推进测试进程。好的测试用例就是用人类的语言尽可能清晰的描述APP中需要测试的各种情况。这个就看你的文笔能力了。写好的测试用例会交给测试人员去测试，这也是他们评判APP是否符合标准的标准。

Bug 管理工具：市面上有很多，大部分都是免费的，就算是付费的也不要介意钱，借助 Bug 管理工具可以有效提高测试人员和技术员的协作效率。

项目上线后

项目上线之后，产品需要关注的几个方面，一是APP数据，二是用户反馈，三是需求提取。

1. APP数据

新用户：首次启动应用的用户；

新增独立用户数：所有应用新增用户数总和（去重）

活跃用户：当天启动游戏一次的用户算作活跃用户，包括新用户、老用户；

活跃独立用户数：应用当天的活跃用户总数（去重复）

MAU：MAU（用户）是每月活跃用户数。

DAU：DAU（Daily User）即每日活跃用户数，常用于反映网站、互联网应用或网络游戏的运行状况。

用户留存率：在互联网行业中，在一定时间内开始使用一款应用，并在一段时间后继续使用该应用的用户被视为留存用户，这部分用户占当时新增用户的比例就是留存率，会按1个时间单位（例如，天、周、月）进行统计。

用户留存的40-20-10原则：如果你希望你的游戏或应用拥有超过100万的DAU，那么日留存率应该大于40%，周留存率和月留存率分别应该大于20%和10%。

次日留存率：（当天新增且首日仍活跃的用户数）/首日新增用户总数；

第二天留存率：（第一天新增用户在第二天依然活跃的数量）/第一天新增用户总数；

第 7 天留存率：（第 1 天新增用户数，且第 7 天仍活跃的用户数）/第 1 天新增用户总数；

30天留存率：（首日新增且30天依然活跃的用户数）/首日新增用户总数。

另外就是APP的数据，这个功能的点击率是多少？有多少人打开了这个功能，有多少人使用？有多少人经常使用这个功能？等等。这些数据要经常关注。结合数据变化，反思功能设计的问题，优化产品。

如有侵权请联系删除！