陆续趁着间断的空档儿，将产品经理的那些事儿分集整理、修剪纪要。
产品经理的日常事儿
产品经理的日常事儿，有需求分析、有项目跟进、有上线支持及上线后运维（运营）等等，遍及到产品过程的所有环节以及产品周边事项。
产品任务
点或面的内容，事前规划的、或自发挖掘的某种诉求、或来自某方面的要求。
说白了就是两种任务类型，一种是自组织自安排的、一种是由上而下的。
需求来源
- 从竞品（同类产品／不同类产品的相同或相似功能）中提炼的；
- 自己按照经验或场景分析规划的、或者与人探讨演练得到的；
- 上级安排的；
- 用户反馈的...
这些罗列点，我更崇尚于日常的不断琢磨和挖掘，包括持续围绕一个未决点进行深入沟通和探研。在适当的时候，将之提炼成需求、并推动产品实现。
需求分析
- 分析场景，用户/目标用户、业务流程；
- 分析竞品、行业，哪些竞品、特色及亮点、可借鉴及警惕；
- 形成方案，落地到自己产品中的场景、业务流及相关逻辑。
需求分析需要将一个诉求点（不管是自我发掘的还是他人提出的），贴合自己产品的定位、目标用户、以及用户场景形成贴切的方案。关键在一个“合”字上，切忌生搬硬造。
需求编写
- 需求描述，用户需要什么、公司需要什么、业务需要什么、产品需要什么；
- 详细需求，用户的一步一步流程；
- 特别提出，某些产品可能会涉及到多端同步问题、版本兼容性问题；
- 特殊场景及非功能性需求，主流程以外的流程分支，包括异常、弱网等；
- 数据追踪，核心目标、哪些指标、定性量化。
需求编写需要描述基本的场景、价值点及诉求，并根据贴合的产品方案细化每个产品步骤，在涉及用户的角度，如用使用（流程）、如何组织人机交互过程（交互），以及推敲流程中、交互中存在的可能性异常的处理。
总结起来，涉及界面、交互、数据输入、数据输出与展现、以及这些事项一组一组的呈现。
需求评审
组织干系人进行产品需求评审，评判需求是否合理、需求呈现各个环节是否完备、实现上是否可行。
这里不得不说一下，前期的需求分析中，适度跟研发沟通产品的目的／设计／实现可行性，有助于思考维度完善、方案设计更具说服力，后期跟进及维护需求则不会耗费太多精力。
研发跟进
- 作为项目里程碑的维度，必须跟进研发进度；
- 及时响应研发提出的问题，留心测试案例；
- 在送测过程尽早注意体验、尽早体验、尽早体验！如果有时间，放空自己，review设计的细节与流程、交互，这也是一种体验方式。
验证及上线
- 做好上线前准备，该发布什么、发布过程是如何的、如何验证，准备相关的checklist；
- 提前运营、提前准备素材或活动推广、提前准备客服咨询及材料。
上线评估
上线后，预计从几个维度评估上线产品或功能的效果。
- 用户的反馈情况、满意度等；
- 数据追踪评估效果，用户数、使用频率。
产品迭代与优化
跟进评估效果及客户反馈情况进行分析，做下一轮的调整和优化，以及修正规划。
- 注意版本兼容性问题、注重优先级评定。
最后一段话
产品经理的这些日常事儿，有需求分析、竞品分析、需求设计、产品规划、需求管理、研发沟通、技术跟进……高度概括就是产品设计、产品和需求管理、沟通，面向的有用户、研发／测试、产品人员、领导，这里面“沟通”都是个大事情。
面对面、即时通信工具、邮件、电话，都是一些沟通手段。
沟通是手段、目的是要干成自己决心的事；有日常的沟通（如月报），有某一目的的沟通（如某个方案的探讨）。产品经理要细心找准自己的“沟通”之道，有个三板斧套路，必定会事半功倍！
网友评论