产品汪大大小小的工作中，归纳起来有这样一些日常事务：

1. 需求管理

2. 写文档

3. 项目跟进

4. 数据分析

5. 产品评测

6. 市场调研

需求管理

多半的需求来自自己使用中的感受，用户反馈和数据大多只是辅助验证想法、指导需求优先级或启发灵感的因素。产品同学对需求的把握能力最产品工作中最难的部分，并且常常功夫在事外，平时的积累很重要。做好产品的需求管理，一般有这样几件事情：

1）产品定位和长线规划

一般是半年左右的规划，做好规划的基础是明确或者反思产品最重要解决的用户需求是什么，产品定位是什么，区分核心功能和附加功能。展现形式最好是ppt，也便于向老大汇报，从产品定位到欲实现的后续功能，这其中的逻辑关系可以看出你对产品规划的节奏感，也容易让数据业务层的技术同学做好提前的基础数据流规划。

2）零散的想法

灵感这东西常常来无影去无踪，随时记下很重要，使用中感到引起困惑的操作流程，吐司文案是否人性化能打动你，引导时机是否恰到好处，哪些环节和交互没有给用户及时的反馈，页面是否突出了该突出的核心功能等。

所谓想法，包括两部分缺一不可，吐槽（哪里做的不好，产品同学首先应该是个挑剔的用户）和解决方法（用好奇心探索和发现问题，并能对想到的问题尽量试图找到一个目前能够想到或理解的答案是做产品应当训练自己的一点）。我通常会这样去找寻解决方式，从竞品或有类似场景需求或功能的其他应用吸取灵感，与团队成员讨论或调研他们的看法，从中获得启发。

3）用户反馈

属于例行工作，坚持有规划的去做很重要，每周抽2个小时回顾，记下关键几条（新问题、频率高的问题），并打上标记，便于每月一次从数量和类别分布上的统计。产品同学如果人员充足，这事儿最好轮流做，然后每周简单碰一次分享一下。

4）bug记录

使用中任何问题当即记下，任何小问题的修复从提出到修复的效果验证，整个过程都是PM要参与的，而常常因为问题较琐碎，做了前者而忽略了后者，想起来的时候发现技术漏做了，甚至是你自己都记不清bug复现的流程或者badcase是什么。所以这种时候好脑筋不如烂笔头，避免后续麻烦的方法就是管理好你产品中那些可爱的bug，之所以是可爱，因为那些bug都记录了你产品不断变化的过程。

产品评测和数据分析也是两个相对专业的发现产品问题或需求的方法，但它们同时也承担着评估产品迭代效果的功效，因此放到后面细说，不在此处赘言。

和下面要说的其他产品工作相比，需求管理工作是最需要产品同学之间交流的，定期的头脑风暴、用户反馈分享和交流、自己的使用感受交流，会对提高产品工作效率、发散想法有很大的帮助。

写文档

说写文档这件事儿，要说这么几点，

确定版本需求

在写之前，有个重要环节叫“确定当下版本要做什么”，这是需要产品做决策的一种最常见的场景（决策和判断力是做产品最重要的能力，木有之一）所谓决策，意味着你面前有很多路，也常常意味着你的资源有限，n多需求先做哪个后做哪个、多个需求解决起来有何关系、是否存在天然的先后顺序等，都需要产品同学判断和权衡。但这种能力非一日之功，要慢慢培养，把产品规划做好，需求、bug管理好，评测分析做好，该做什么其实自然明了。

搭架子

到了写需求文档的时候，先搭框架，列出需求点，避免遗漏也能全局把握这个版本的核心功能点。若是大功能，先流程（从主流程主场景开始），再确定页面，其次确定页面主功能、辅功能，而后确定页面元素。若是不涉及页面的逻辑层面的需求，则重点在于接下来的事情，叫场景想象，你能想象出的场景的丰富性一定程度决定了你写的文档的严密程度，而往往又决定了测试环节（或你自己验证时）能发现bug的可能性，最终可能影响上线质量，而后可能影响下个版本的需求。这件事情换言之叫从各个维度说清楚产品可能发生什么，当然也有一些方法可言，分维度的的去说，先从视觉说，用户什么场景下、做了什么动作的情况下，会呈现出什么样子，再从数据层面说，什么操作带来什么数据的变化，再从某个操作前后可能关联的操作说，如果前面用户操作过什么，在此处的交互中将发生什么。此处有个小细节是关于产品中的各种交互文案，其实在思考需求细节时顺带确定和写出是上策，不然很可能回忘，到想到时，常常急于给技术一个方案，而草草了事，那些我们在产品里看到的过于生硬的、或者不够协调统一的显得非常没有诚意的交互吐司，大概就是这么形成的。

反复抠细节

写文档还容易犯两个毛病，一是写完不看不反思，二是过程中不注意文档的维护，我曾经多次犯过这样的问题，评审中发现文档的纰漏，或发现遗漏的场景和逻辑点。避免犯错的方法是提前一些写文档，且多看几遍（以假想产品已成形的使用状态去看）。关于文档的维护，重要性和做好的方法是态度和习惯问题，不必说。

项目跟进

工作中经历过很多次延期、意外和疏漏后，我总结出这样些许经验：

1）项目时间表。从立项到上线为周期做表格，全局把握项目动态，记录项目的各个时间节点，在关键时间节点上提前告知和提醒相关人员，需求变更也在表格中记录，便于与QA同步需求。

2）单元性测试。大项目用几大功能点进行拆分，尽量每周团队内部出一个版本验证效果，及时发现问题。

3）敏捷开发。敏捷开发模式，站立会形式，一日一碰。

4）打点统计的规划。做需求时同时把打点统计需求加入开发中完成，而不是QA环节做。

5）大小版本交替进行。版本规划中尽量大小版本交替进行，让团队的开发节奏一张一弛。

6）版本总结会。延期问题、项目中出现的错误、欠缺考虑之处，在上线后的总结会中提出并得到团队同学重视，避免犯同一错误。

数据分析

主要包含这三类分析：

1）例行版本变化分析

例行版本上线分析主要用来持续观察产品核心功能的相关指标，用于对比分析产品迭代效果。例如看片神器中的用户量、留存、播放量、资源分布、播放类别分布、播放下砸成功率、搜索相关指标，属于需要例行观察的核心指标。

2）新功能效果分析

主要针对刚上线版本的新功能或改进功能进行分析。使用比例、次数、路径上的各个操作的数量和频率是否符合预期，和上个版本相比、和同等地位其他功能模块对比等，方法不一而足。

3）用户行为分析

每隔一段时间应对所有打点进行统一的分类分析对比，从全局把握产品被使用的情况，以及与产品定位预期是否一致、是否存在一些鸡肋功能或做了但没做好的功能、有何特别的数据显示了某些用户行为变化等，通常进行大的版本规划前这种用户行为分析是十分必要的。

产品评测

评测的意义在于将体验从个例扩大为相对准确且可量化的共性上去。评测通常是围绕一个核心功能，但不止于发现这一功能的产品问题。例如视频的例行评测包括搜索评测、播放、下载评测。搜索评测可以发现从内容缺失（爬虫和产品策略问题）、结果排序（搜索排序问题）、结果可用性（聚合、源排序、播放效果问题）等。播放下载评测可以发现解析、播放器、播放流程、切源流程、清晰度策略等多个环节的问题。

市场调研

市场调研除了在产品初期要做以外，实际上产品的生命周期中是一直要关注的，产品要在市场中存活下来，要时刻确定产品有价值的，满足这个价值的竞品做的如何，是否有其他途径和产品方向可以取代我们的产品等等。细分一下，产品同学要做的市场调研方面的工作有：

1）资讯获取。每周有固定的时间整理和回顾本周的行业动态，零散时间的积累会在长时间看出效果。

2）新产品体验。关注移动端新产品，从创意、到视觉、到交互，汲取有价值的方面，或仅仅作为一种开阔眼界也是有价值的，和任何一个领域一门学问一样，多看是增加见地的最重要的方法。

3）竞品分析。大到产品定位，小道一个小的产品功能或交互逻辑，都值得仔细推敲已经实现了这个功能的竞品的实现方式，避免出现前人做的不好的地方，才有望从它们中间脱颖而出。

4）产品间的交流。和需求管理类似，市场行情、新产品新创意的分享交流也是提高产品工作效率，培养产品团队专业性的方法之一。