编辑导语：产品经理在日常工作中需要对APP的迭代更新进行管理，在面对需求时，需要有判断和执行的能力，进行有效的评估，在进行最后的执行优化；本文作者分享了关于产品新人在面对用户需求收集与版本升级推送机制设计时的经验思考，我们一起来了解一下。

最近面试了很多产品新人，每当问到需求来源、收集方式与版本迭代计划依据时，发现很少有人能够回答出满意的答案。

其实，在产品从Idea到落地开发，到线上运营，再到优化升级的产品迭代管理过程中，产品经理势必会遇到来自各种用户各种角色不同的业务需求；尤其是很多创业型公司可能最初的需求是来源于团队创始人在偶然间迸发出的一个的完美想法，但是综合团队能力、用户场景、政策法规、用户核心痛点、问题解决方案，并不是每一个Idea都具有可行性。

那么如何对需求进行有效的评估，对用户数据进行验证，对老板们五花八门的想法怎样才能落地开发，按节奏的对产品功能进行升级优化，并不是常人看起来那么简单。

一、需求收集和管理

1. 需求收集

产品需求收集来源渠道，通常会来源于:一线用户需求、产品运营活动、市场/业务需要、竞品分析、公司领导、产品总结思考、BUG修复等。

用户需求收集方式通常包含：

• 用户访谈：找准核心用户，然后根据用户年龄、角色、地区、等不同属性进行细分，在放松彼此信任的环境下进行访谈并且进行重点提炼；
• 问卷调研：事先记录功能需求重点，根据用户属性和事先规划设计调研问卷，鼓励用户填写，并且进行汇总分析；
• 竞品对比：根据竞品分析进行产品功能对比，使用表格提炼出产品功能，并且进行记录；
• 数据分析：对比较重要或是产生歧义的功能需求进行数据埋点，通过数据分析决定产品功能意义；
• 头脑风暴：针对用户痛点，组织头脑风暴会议，每个成员根据自己的想法提出各类解决方案，用户可以根据课题进行自由发言，收集所有方案后综合评估出具体的可行性方案；
• 专家小组：组织对需求具有专业性的专家或对业务具有深刻理解的成员，收集他们对需求与事物的看法；
• 联合开发：在产品的开发过程中，联合真实用户进行共同合作，一起对产品进行优化开发。

2. 需求管理

由于产品需求来源由不同渠道并且常常由不同角色的用户提出，产品经理收集回来的需求往往会具有：需求分散、使用频率高、紧急程度高、实现周期长、刚性需求不足、技术难度高、使用频率低…等特点。

如果通通将这些需求加入开发计划，发现会很难执行，所以我们需要对需求进行评估。

常用的需求管理工具是需求池，需求池至少需要包含:功能模块/需求名称、详细描述、需求来源、提出人、是否评审、需求状态。

产品经理将收集的需求根据根据：重要并且紧急、重要不紧急、不重要紧急、不重要不紧急，的方式进行优先级的排序和划分。

同时对于重要紧急，但可行性低的需求解决方案应该找到替代的解决方案。

需求池是最简单最直接的需求管理手段，也是产品经理必备的需求管理工具，除此之外我们也可以用思维导图、第三方工具等进行优先级的划分，需求的管理。

二、目标分解

有很多产品在开发之处，公司领导就寄予厚望，恨不得在一夜之间就完成各种竞品已有甚至没有的功能。

对于产品开发的前期阶段，产品本身的用户场景不够明确，研发团队对各种新技术的掌握程度还不够熟悉。

盲目的扩大项目范围会导致产品研发周期延长，无法快速验证用户数据；所以在前期产品调研和需求收集的时候我们需要明确目标用户、找准用户痛点，实现核心功能优先，对需求任务进行迭代分解。

前期的规划当然是比较理想化的，但是为了前期对产品进行阶段性目标的分解，我通常会规划一个大体的产品迭代周期，但是实际工作中会跟着数据分析和市场变化，进行迭代调整。

互联网产品变化很快，所以通常在做规划时，我通常只会提前做1—2个版本的规划，其他的计划会跟着数据分析和市场变化，进行调整。

三、数据分析辅助产品决策

有些时候用户需求是模陵两可的，任没有用户数据验证之前很多产品经埋都是凭主观意识进行产品决策。

验证版本迭代是否对产品规划产生效用，最合理的途径之一就就是进行数据分析对比。

目前市场上已经有很多数据分析平台，而且大多都是免费的数据分析平台，这些第三方平台已经能够满足我们的基本需求；我们也可以建立自己的数据平台，这样能够通过多维度的数据分析进行产品决策。

以数据为向导，能够帮助产品经理确定当前的业务流程和产品优化方向。举一些简单的例子，例如：通过时段对比得知用户用户习惯，有利于运营活动的建立日期；页面访问频次，可以得知部分位置广告转化率。

产品数据分析也可以通过多条件组合分析，在必要的时候还可以根据需要整理表格，对数据更密切的关注。

四、记录版本更新日志

1. 版本更新日志

对每个版本的更新情况进行记录，版本更新日志根据公司产品属性不同，记录字段和方式也不同。

为了方便后期运营数据查询上线日期监控，最基本的字段应该包含：版本名、版本号、内部更新日志、外部更新日志、渠道、上线状态、上线日期…。

记录产品更新日志，对于部分变现目标型产品来说能够帮助团队掌控产品迭代历程和用户使用规模的屏幕。

2. 产品上线渠道

记录渠道是为了更好的帮助产品的推广与市场运营工作，同时也能够帮助产品经理更了解渠道特点和用户属性；每个渠道都有不同的特点，如有的渠道审核时间长，有的渠道用户留存高，有的渠道广告审核严格等等。

管理好渠道也能缩短产品的上线周期，迅速提升产品量级缩短不必要的反复修改审核时间。

五、新版本更新推送逻辑设计

1. 新版本内部推送设计

根据业务需求，产品更新业务逻辑设计通常要考虑到：强制更新、自动更新监测、后台自动更新，新版本检测。

产品经理在第一个版本时就应该做好更新推送机制，在后台增加版本管理功能并且接口中预留好更新推送的属性如：本次版本若为强制更新，用户如果不点击更新按钮，则无法进入主程序。

以下举一个简单的产品版本管理例子：在后端进行产品包的上传以及本次更新的属性，前端用户打开APP联网时或者APP在后台启动时，在主页弹出用户更新推送。（需要注意的是IOS系统平台规则中产品内不可设计自动检测更新，必须通过线上市场用户才能获取更新。）

2. 线上市场的更新频率

线上市场也属于上文中提到的渠道，如各大手机厂商都有自己的应用商城。

产品的更新频率、更新日志内容对于线上市场的推广、Aso影响也比较大，正常情况下1—2周进行一个小版本的迭代，市场也会在同类关键词中排名靠前。

经过实际工作中对渠道记录和产品更新测试，我们发现应用市场之间如果版本不一致也会存在抓包，部分应用市场会抓取其他渠道最新的包；应用市场的产品更新，需要按照平台的规则上传对应资料，在审核通过后用户可以在更新列表中对应用进行更新。

六、总结

产品经理的工作用比较通俗的表达方式，其实就是和不同人打交道，进行业务设计前我们要考虑满足哪些不同的用户群体，他们的用户特征，提前预测哪些是我们的核心用户、不同人群的使用场景、用户痛点、怎样对这些人进行有效的业务转化。

在经历不同产品的时候，你也会对行业有一番见解在潜移默化的过程中成长；所以我主张产品经理职业路程的成长，一定要不断学习新的知识，接收外界新的事物，不断的接受挑战，规划产品的迭代应该像对自身知识学习一样不断进行。

本文由 @Arvin 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议