【起点精选】野路子的产品心经：2017这一年遇到的10点产品问题
踩多少坑都不怕，只要你记得抽空进行问题总结，以及接下来的计划安排，下次总会做的更好。
距离我上一篇文章，整整隔了一年，由于换了公司忙的飞起，每个月的一篇文章被加班取代了。针对17年的工作，不反省自我，总结经验，对不起那些想杀我祭天祈求2018年风调雨顺国泰民安的开发啊~这周抽出了时间总结了2017这一年遇到的问题，以下总结10点：
1、需求评审粗糙或缺失
答：
（1）注意好会议前
召集好相关人员参与会议。定好时间、会议室、记录人。
（2）会议中讲解需求流程
需求背景：概述需求从哪来，为何要做这个需求。
用户与需求概述：描述解决用户什么痛点难点，将产品做成什么样。
功能模块：需求涉及相关的重点大的功能点，按照主流程重点先讲，再讲分支点。
原型与交互：讲解原型内容和交互，注意异常流程要提及。
数据指标：讲解本次需要哪些关键性的指标。
任务分配：需要其他部门、其他岗位配合的资源罗列出来，提前安排资源支持。
（3）在会议住中找个同事帮帮你做会议纪要，把争论点疑问点都记录下来。
（4）会议后，将变更点、变更范围都记录清楚，将会议纪要发给大家评估。
2、需求宣讲太草率
今年由于项目任务重，时间紧，自己没有主动发起严格的需求宣讲，有的开发需求都没有听过直接开干了。导致有些需求不太合理，且有些场景细节漏掉了，开发有些需求不理解，因为他们没有实际操作过业务，中间要废很多时间精力来给开发测试答疑沟通，一来二去开发想在年底杀我祭天了，我也很痛苦，愧疚又羞愧，还要花时间补充、修改。同时耽误了其他事情的进程。
答：从下一个新需求开始，我要按照我整理的方法进行宣讲，所谓开头开得好，产品返工少~~
（1）自己先讲需求：先介绍业务——达到什么目标存在什么价值意义——实现的思路。
（2）给出1-2天时间，给开发自己去阅读文档自己理解，再指定开发反述。
（3）在测试发问，注意前端正常流程、异常流程怎么操作，后台正常流程、异常流程处理的细小逻辑。
（4）注意事项：
确保会议时间充足：提1-2天发好通知，让开发和测试安排好工作确保不缺席，时间点最好定在离吃饭时间间隔远，反正我司程序猿吃饭是天大的事，不能耽误一丝一毫。
会议中的疑问记录好：由于对需求的理解不同岗位考虑的问题不同，在会议中会经常打断你，会问实现的问题，也会问到你没想到的异常场景，当你能马上解答的你可解答一下，若无法现场及时给出答案的需要记录下来会后再解答，不要耽误会议时间。
3、需求场景遗漏
需求分析时会漏掉场景想不全，导致需求变更的时候愧疚和害怕，所以会考虑到开发的成本，不敢对需求大动干戈。而选择折中。而这种折中会影响到用户体验。
答：
所以，我分析需求时，为了避免遗漏一些细节，逻辑不严谨。从以下几个维度去思考：
（1）用户是谁—解决什么难点—产生什么需求
（2）脑图结构化，每个功能点，思考影响节点和分支场景。
（3）每个页面从开始-发展-结束的情况（有无数据、正常异常情况），放空自己，把自己想象成用户，实在做不到，可以找到对应的朋友看他们怎么操作，会有什么让你想象不到的问题。
4、离用户不够近
需求做的没底气，做了一个地区去赶另一个场子，已做的地区后续需求不明确，也不知道自己做的需求到底能不能符合市场贴近用户，这个是时间的问题，先统一做几个地区，再做需求优化。
答：
（1）今年用户现场去的太少，需求开干前就应该去收集需求。
（2）产品设计后，再去用户现场验证，种子用户圈起来。
（3）产品上线后，持续维持和用户的互动，收集用户的意见，持续优化迭代产品。使用户画像清晰化，产品价值和产品定位明确化。
（4）竞品分析，紧盯竞品：2周浏览一下竞品。1个月写一下竞品发展情况。
5、需求文档能力待提升
需求文档写的不好。重庆第一个版本那样写太麻烦太啰嗦费时间 福州第二个版本又太简单，需要寻找一个平衡点来写文档。打算山西的好好思考怎么写的需求文档易读性更好，让开发觉得我还可以再留到19年底再杀。大致罗列了一个大纲：
答：
（1）产品简介：简要的说明产品使用价值。
（2）版本管理：写好版本时间，需求变更点，变更原因。
（3）功能模块：
功能描述：写好目标用户和使用场景，在写每个功能模块的时候，简要的畅叙一下，自己能够试着去变成用户，也让开发测试有带入感。
页面原型：页面状态加图示且说明。
操作流程：正常、异常流程说明、及主要业务流程图。
业务规则：前置条件、加载机制、数据处理。
交互说明：正常交互、异常交互、页面跳转。
字段说明：字段、说明、数据来源。
6、需求验证不到位
需求验证，这点没做好，开发完成后没有去验证是否符合需求。没有很好的和开发团队配合。现在做的B端产品，测试环境准备相当复杂，自己也不会弄，每次环境配下来要花很多时间，所以每次就测试测完不管了。
答：
和测试团队制定了新的计划，需求单子增加一个要求：是否需要需求验证。如果需要，在测试结单前，测试将产品需要验证的点，把产品叫过来，演示一遍。
7、产品运营设计太薄弱
产品做了，价值点怎么传递给用户，对于B端产品，专业性较强，不像C端用户自己去探索发现，B端用户只要能够保证完成自己的工作，很难去改变工作习惯，也很难去主动挖掘潜在价值。如何很好的把价值传递显性的给用户，同时改变用户的习惯。目前我做的产品是很欠缺的，这题太难了~超纲啊！比五年高考三年模拟还可怕对于我来说~
答：今年好好总结思考，再整体总结出一篇文章。
8、文案功底欠缺
文案功底欠缺，由于之前文案自己写了之后，都有专业的团队人员负责修改优化，导致我对文案无法做到字字珠玑，从各个方面来看，文案真的太重要了~
答：
（1）一个功能页面选取一个文案点，平时反复打磨，邀请同事探讨，怎样的文案达到最佳表达效果。
（2）多看书多学习，平时自己花时间和功夫利用其余时间累积。可以在生活中多去思考。
（3）每个月底的周六去看一些业内的分享讲座并出自己的心得。
9、产品深度欠缺
缺乏行业大局观。不知道行业发展趋势未来在哪里，这样也就无法把控产品的深度，和市场上哪些妖艳货没什么区别了~
答：
其实这个问题，作为一个入行不到5年的产品来说，是普遍的通病了，也是个大难题。这个没有什么捷径，除非你是才智过人天赋异禀，作为凡人的我，知道只有在这个行业沉淀下去，经历得多了，思考得多了，慢慢积累，自然也会变成一个有高度有深度的产品人。
10、时间管理
公司大，事情多又杂，时间上管理不当，导致时间花了，不知道干了什么事。而且每天加班，每天忙到连自我提升的时间都没了~
针对这种情况列了管理表，结果写着写着就遗忘了。我觉得管理表作用还是挺大的，对于自己的工作安排，时间节点都清晰明了，不会造成事情丢三落四，但是但是！！！每次都没有坚持下来。
答：
（1）一定要坚持列好管理表。将年度计划、半年度计划，细化到月度计划、周计划、天计划。
（2）按照计划事情一定要一件一件做。遇到计划有变及时更新计划表，制定新的计划。
月度计划、周计划工作表
需求点清单表
自己每天工作计划表
以上只是罗列了一些问题和如何解决问题的一些点，真正的要解决这些问题远不止我回答的那么简单，这些都是需要我们在平时的产品工作中慢慢积累，认真思考的。我们要学还很多，路很长~如：产品经理如何正确撕逼？
本文由 @李大发 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自StockSnap.io，基于 CC0 协议
原文链接：野路子的产品心经：2017这一年遇到的10点产品问题 ｜人人都是产品经理
距离我上一篇文章，整整隔了一年，由于换了公司忙的飞起，每个月的一篇文章被加班取代了。针对17年的工作，不反省自我，总结经验，对不起那些想杀我祭天祈求2018年风调雨顺国泰民安的开发啊~这周抽出了时间总结了2017这一年遇到的问题，以下总结10点：
1、需求评审粗糙或缺失
答：
（1）注意好会议前
召集好相关人员参与会议。定好时间、会议室、记录人。
（2）会议中讲解需求流程
需求背景：概述需求从哪来，为何要做这个需求。
用户与需求概述：描述解决用户什么痛点难点，将产品做成什么样。
功能模块：需求涉及相关的重点大的功能点，按照主流程重点先讲，再讲分支点。
原型与交互：讲解原型内容和交互，注意异常流程要提及。
数据指标：讲解本次需要哪些关键性的指标。
任务分配：需要其他部门、其他岗位配合的资源罗列出来，提前安排资源支持。
（3）在会议住中找个同事帮帮你做会议纪要，把争论点疑问点都记录下来。
（4）会议后，将变更点、变更范围都记录清楚，将会议纪要发给大家评估。
2、需求宣讲太草率
今年由于项目任务重，时间紧，自己没有主动发起严格的需求宣讲，有的开发需求都没有听过直接开干了。导致有些需求不太合理，且有些场景细节漏掉了，开发有些需求不理解，因为他们没有实际操作过业务，中间要废很多时间精力来给开发测试答疑沟通，一来二去开发想在年底杀我祭天了，我也很痛苦，愧疚又羞愧，还要花时间补充、修改。同时耽误了其他事情的进程。
答：从下一个新需求开始，我要按照我整理的方法进行宣讲，所谓开头开得好，产品返工少~~
（1）自己先讲需求：先介绍业务——达到什么目标存在什么价值意义——实现的思路。
（2）给出1-2天时间，给开发自己去阅读文档自己理解，再指定开发反述。
（3）在测试发问，注意前端正常流程、异常流程怎么操作，后台正常流程、异常流程处理的细小逻辑。
（4）注意事项：
确保会议时间充足：提1-2天发好通知，让开发和测试安排好工作确保不缺席，时间点最好定在离吃饭时间间隔远，反正我司程序猿吃饭是天大的事，不能耽误一丝一毫。
会议中的疑问记录好：由于对需求的理解不同岗位考虑的问题不同，在会议中会经常打断你，会问实现的问题，也会问到你没想到的异常场景，当你能马上解答的你可解答一下，若无法现场及时给出答案的需要记录下来会后再解答，不要耽误会议时间。
3、需求场景遗漏
需求分析时会漏掉场景想不全，导致需求变更的时候愧疚和害怕，所以会考虑到开发的成本，不敢对需求大动干戈。而选择折中。而这种折中会影响到用户体验。
答：
所以，我分析需求时，为了避免遗漏一些细节，逻辑不严谨。从以下几个维度去思考：
（1）用户是谁—解决什么难点—产生什么需求
（2）脑图结构化，每个功能点，思考影响节点和分支场景。
（3）每个页面从开始-发展-结束的情况（有无数据、正常异常情况），放空自己，把自己想象成用户，实在做不到，可以找到对应的朋友看他们怎么操作，会有什么让你想象不到的问题。
4、离用户不够近
需求做的没底气，做了一个地区去赶另一个场子，已做的地区后续需求不明确，也不知道自己做的需求到底能不能符合市场贴近用户，这个是时间的问题，先统一做几个地区，再做需求优化。
答：
（1）今年用户现场去的太少，需求开干前就应该去收集需求。
（2）产品设计后，再去用户现场验证，种子用户圈起来。
（3）产品上线后，持续维持和用户的互动，收集用户的意见，持续优化迭代产品。使用户画像清晰化，产品价值和产品定位明确化。
（4）竞品分析，紧盯竞品：2周浏览一下竞品。1个月写一下竞品发展情况。
5、需求文档能力待提升
需求文档写的不好。重庆第一个版本那样写太麻烦太啰嗦费时间 福州第二个版本又太简单，需要寻找一个平衡点来写文档。打算山西的好好思考怎么写的需求文档易读性更好，让开发觉得我还可以再留到19年底再杀。大致罗列了一个大纲：
答：
（1）产品简介：简要的说明产品使用价值。
（2）版本管理：写好版本时间，需求变更点，变更原因。
（3）功能模块：
功能描述：写好目标用户和使用场景，在写每个功能模块的时候，简要的畅叙一下，自己能够试着去变成用户，也让开发测试有带入感。
页面原型：页面状态加图示且说明。
操作流程：正常、异常流程说明、及主要业务流程图。
业务规则：前置条件、加载机制、数据处理。
交互说明：正常交互、异常交互、页面跳转。
字段说明：字段、说明、数据来源。
6、需求验证不到位
需求验证，这点没做好，开发完成后没有去验证是否符合需求。没有很好的和开发团队配合。现在做的B端产品，测试环境准备相当复杂，自己也不会弄，每次环境配下来要花很多时间，所以每次就测试测完不管了。
答：
和测试团队制定了新的计划，需求单子增加一个要求：是否需要需求验证。如果需要，在测试结单前，测试将产品需要验证的点，把产品叫过来，演示一遍。
7、产品运营设计太薄弱
产品做了，价值点怎么传递给用户，对于B端产品，专业性较强，不像C端用户自己去探索发现，B端用户只要能够保证完成自己的工作，很难去改变工作习惯，也很难去主动挖掘潜在价值。如何很好的把价值传递显性的给用户，同时改变用户的习惯。目前我做的产品是很欠缺的，这题太难了~超纲啊！比五年高考三年模拟还可怕对于我来说~
答：今年好好总结思考，再整体总结出一篇文章。
8、文案功底欠缺
文案功底欠缺，由于之前文案自己写了之后，都有专业的团队人员负责修改优化，导致我对文案无法做到字字珠玑，从各个方面来看，文案真的太重要了~
答：
（1）一个功能页面选取一个文案点，平时反复打磨，邀请同事探讨，怎样的文案达到最佳表达效果。
（2）多看书多学习，平时自己花时间和功夫利用其余时间累积。可以在生活中多去思考。
（3）每个月底的周六去看一些业内的分享讲座并出自己的心得。
9、产品深度欠缺
缺乏行业大局观。不知道行业发展趋势未来在哪里，这样也就无法把控产品的深度，和市场上哪些妖艳货没什么区别了~
答：
其实这个问题，作为一个入行不到5年的产品来说，是普遍的通病了，也是个大难题。这个没有什么捷径，除非你是才智过人天赋异禀，作为凡人的我，知道只有在这个行业沉淀下去，经历得多了，思考得多了，慢慢积累，自然也会变成一个有高度有深度的产品人。
10、时间管理
公司大，事情多又杂，时间上管理不当，导致时间花了，不知道干了什么事。而且每天加班，每天忙到连自我提升的时间都没了~
针对这种情况列了管理表，结果写着写着就遗忘了。我觉得管理表作用还是挺大的，对于自己的工作安排，时间节点都清晰明了，不会造成事情丢三落四，但是但是！！！每次都没有坚持下来。
答：
（1）一定要坚持列好管理表。将年度计划、半年度计划，细化到月度计划、周计划、天计划。
（2）按照计划事情一定要一件一件做。遇到计划有变及时更新计划表，制定新的计划。
 |
月度计划、周计划工作表
 |
需求点清单表
 |
自己每天工作计划表
以上只是罗列了一些问题和如何解决问题的一些点，真正的要解决这些问题远不止我回答的那么简单，这些都是需要我们在平时的产品工作中慢慢积累，认真思考的。我们要学还很多，路很长~如：产品经理如何正确撕逼？
本文由 @李大发 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自StockSnap.io，基于 CC0 协议
原文链接：野路子的产品心经：2017这一年遇到的10点产品问题 ｜人人都是产品经理
还没人赞这篇日记
