目标用户群是谁？用户有没有需求？用户有哪些需求痛点还没有被很好地满足？有着相同或相似需求的用户的数量规模是大还是小？这些是产品经理工作的第一步。
通常用户所提出的需求都是从他们自身的角度出发，但这些需求不一定符合产品的定位和设计的依据，无法直接作为产品规划的依据。因此，我们需要对纷繁复杂的用户需求进行深入分析，筛选出其中的真实需求。
进行用户需求分析的第一步一定是收集需求，可以通过以下几种途径：
收集到的数据并不一定都是具有价值的，这需要产品进行分析过滤。
在分析需求价值时，需要注意以下几个问题：
搞明白以上问题后，就需要对需求进行优先级排序。
基于用户需求提出差异化解决方案以及提炼出带给用户的价值，这是产品经理工作的第二步。
这一步可以分为特定用户和普遍用户，根据自己产品的定位可以打造与竞品差异化的解决方案。
产品的价值如何传递给用户？用户在哪些地方可以用到这种产品？用户在哪里？是怎么来使用产品的？这就是市场渠道分析，这是产品经理工作的第三步。
App 渠道数据分析两大思路：
根据业务需要，我们选取广告来源和广告关键词两个维度，计算出不同渠道的获客数量并评估获客成本。
从客单价的角度出发，接下来可以针对性优化投放渠道和投放内容，大幅度降低投放成本、提高拉新效率。
用户行为数据分析，在这个过程中，我们重点参考用户留存指标，包括次日留存率、三日留存率、七日留存率、三十日留存率等等。
除了用户行为指标，财务指标也非常具有参考性。
搭建一个完整的 App 渠道追踪体系，对每个渠道、每次投放的数量和质量进行精益化的分析。
成本和收入以及盈亏平衡点分析，这是产品经理工作的第四步。
这里可以通过一些财务分析工具来进行分析，或是通过每个渠道的统计数据进行分析。
需求分析与管理及产品交互设计的过程，这是产品经理工作的第五步。
在需求分析环节定论需求重要度之后，直接就按优先级进入设计阶段，除开重要度还有一个需求层次的维度需要分析，只有当这两个维度中，才能将需求定位，定位后可以让明确的了解哪些需求属于基础必备的，哪些是可以为产品加分，哪些是可以可有可无的。
在这里主要介绍马斯洛需求层次模型和KANO模型两种应用。
由此演变出了五个需求等级：
以下是KANO模型：
KANO 模型是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。将影响满意度的因素划分为五个类型，包括：
产品经理应该不应该懂交互设计，答案是必须要懂的。
产品经理对待交互稿，应该是快，草；快速模糊的把信息传递给交设计师，交互设计师根据模糊的概念形成细化的方案。
根据用户的反馈和数据分析，不断迭代调优产品，这是产品经理工作的第六步。
这里介绍数据分析的9种方法：
竞争壁垒分析，这是产品经理工作的第七步。
可以从以下几个方向去做一些思考：
团队管理，产品经理是一个需要别人协助完成自己想法的职位，所以需要强有力的制度和文化的支撑，这是产品经理工作的第八步。
工作流程
一、 贯穿始终的任务（非线性的）
1.1 需求收集
（1）描述：需求基本可分为两种：主动采集和被动采集。主动采集是指深入业务方工作环境，去发现流程的不合理、日常遇到的问题，将问题剖析后转为需求；被动采集则是指业务方在工作中遇到的问题，并且迫切希望解决的问题。需求收集过程中沟通的问题：
l 业务方过于强势，对于问题直接给了不太专业的解决方案，照做就完蛋了，也完全体现不出产品的价值，要学会提问，思考为什么他们希望以这种方式解决问题。
l 业务方回答不到点上，长篇大论，完全跑偏。这时候直接打断并非好方法，我习惯是耐心听取，提取有用的信息，并在恰当的时机与他们再次确认，适当得把话题掰回正轨。
l 业务方不够专业，不能清晰表达流程，沟通起来效率不高。可以索取业务原始数据和协助文档，从结果倒推流程，再找业务方确认。
（2）工具：
l 五why分析法：用于痛点挖掘（涉及多角色时需要分别梳理不同角色的痛点）；
l 用户故事：抽象业务，罗列痛点，一句话描述需求，一群什么样的用户在什么场景下想解决什么问题，解决过程碰到什么问题，最后用户怎么解决的。
（3）产出物：
l 需求背景：业务介绍，什么人在什么过程中遇到了什么问题，希望怎样。
l 涉及角色：参与具体业务的所有协作人
l 对接人：协助产品了解当前业务逻辑的人
1.2 需求整理排期
（1）描述：将需求入库后，需要定期整理，将已经不满足当前业务的需求出库，能合并的合为一个需求，有必要拆解的拆为多个需求。按照优先级得分、紧急状态去规划近3个迭代的需求（并非定死，迭代周期期间有可能穿插一些紧急的需求，按实际情况操作）
（2）工具：
l 需求打分表：按照需求类别、需求级别、优先级别等不同纬度打分，给排期提供数据上的支撑。
l 四象限法：同样用于评估哪些需求先满足，哪些可以先缓一缓。
（3）产出物：
l 近期三次迭代的需求规划
1.3 解决线上问题
（1）描述：产品经理的本质就是用合理的方式解决一个又一个难题。随着新版本迭代或者已有功能的使用中，业务人员常常会遇到系统出问题，有可能是系统bug、也有可能是功能流程问题、甚至仅仅是使用问题（无法理解怎么操作）等等。面对不同的问题，需要灵活处理，自己能解决的最好，不能解决的要及时调配资源辅助，特别是一些紧急的问题，耽搁少许可能就会导致严重的损失。
（2）工具：
l 强大的内心：遇事不慌，冷静得直面问题
l 积极主动的态度：客户、系统问题，产品都是首当其冲，你不冲在前方，也别指望在他人引领下走向光明。
l 责任心：事不关己，高高挂起的态度永远成为不了优秀的产品
l 良好的沟通力：高效、专业，当然也要适当注意言辞
（3）产出物：
l 修复好的系统bug
l 问题转需求
l 客观正视自己设计的需求方案（用户不会用，还得多想想自己的原因）
1.4 跨职能协作
（1）描述：产品经理需不需要懂业务？答曰：产品经理必须非常熟悉业务（尤其是B端产品）。要达到业务和软件系统的最佳融合，产品经理必须十分熟悉业务，在产品架构、功能迭代方向上，确保业务能够有效落地。解决方案上，并非要把系统设计的多么完美，要尽可能结合现实，考虑实际落地场景，承担部分项目经理的责任。
（2）工具：
l 业务数据分析
l 业务方向规划
（3）产出物：
l 跟随业务优化的系统优化
l 数据分析结论和应对方法
二、迭代任务（线性）
2.1 需求设计
（1）描述：需求设计是产品经理硬实力的体现，需求文档力求逻辑清晰、易读性高，以确保开发团队内协助高效。在设计过程中，基于需求背景、用户痛点、业务场景、业务角色等梳理需求目标，以目标为导向思考解决方案
（2）工具：
l 用户现场调研：深入业务方的日常行为及工作，发现根本问题
l HMW分析法：拓展问题解决的方向，发散思维寻求更多解决方案
l 竞品分析：了解其他相似功能或模块设计逻辑，体验产品的过程中，重点关注用户、使用场景、需求，吸取主流设计模式的优点。
（3）产出物：
l 需求概括：需求背景、目的、目标用户等，这些在需求收集阶段就要梳理出来，在需求设计阶段细化
l 业务流程图：涉及角色、交互的系统，梳理关键流程节点，前期厘清流程避免后期大面积返工，当然最终流程也需要跟业务方确认后再设计细节
l 功能流程图：包含主流程、详细子流程，考虑多线程流程、逆向流程等
l 功能架构：按照层级结构往下拓展，eg：端（管理后台、H5）->模块（商品管理、库存管理）->功能（新增、删除）->子功能（批量删除）
l 信息架构：每个子功能需要哪些信息支撑，由下至上梳理
l 页面结构和原型：页面间跳转逻辑，页面内组件交互备注说明、业务规则说明等。
l 其他：修订历史、简单核心用例
2.2 需求评审
（1）描述：需求评审，是每个产品经理必须经历的工作环节。在评审会议上，前端、后端、测试、UI、业务方、领导等不同角色都有可能参与，每个角色对于需求的关注点不同，目的有四：评估需求的价值（做还是不做）、评估需求方案的合理性、初步评估技术可行性、明确需求开发的事项。所以如何高效完成需求评审、让大家都能理解你做的方案，是一个产品经理的基本素养，和赢得团队信任的基础。
（2）评审流程：
l 首先是界定需求类别：需求本身可分为：功能优化、功能拓展、新功能。不同类别的需求描述着重点不同。
l 介绍需求背景：上来就讲功能点绝对是莫名其妙的，可能讲完了在场各位连你到底要做什么都还不知道。
l 描述当前业务流程：明确涉及的角色，描述当前关键业务节点，目的是让大家都了解业务逻辑，以便去判断方案是否存在大方向的偏差。
l 描述需求目标：根据背景和业务流明确此次方案的边界，要解决哪些问题，谁通过什么方式来解决。
l 描述方案/功能流程图：列出主要的功能模块/功能点，讲清楚需要哪些功能点来解决哪些对应的问题
l 细致描述页面流程：采用逻辑+模块的表达方式，功能流程图上每个关键节点都是一个产品模块，先讲清楚每个链上的产品模块，再讲模块的功能。上帝视角与用户视角结合，既要说明逻辑、模块、功能等概念，也会从一个具体配置人员的角度讲一讲他们该如何使用这个系统。
l 描述需求考核指标：此次需求设计的效果验证，最好能提供一些可量化的数据指标，即完成这个需求后能带来哪些数据的变动。
（3）产出物：
l 会议记录：在会上，在讲的同时也要把出现的问题记录下来，整理待解决的问题，并与大家确认无遗漏
l 问题解决方案：针对待解决的问题，给出其他更合适的解决方案，小问题发出确认即可，大问题还要约第二次评审，无论是大小问题，在修改需求文档时都需要记录修订时间、内容、修订人，同时通知相关人员
l 版本排期：最后一次评审会确定就要排期，这个可以跟相关部门的负责人沟通，比如技术经理，需要多久时间完成迭代任务，什么时候提测、什么时候可以上线
2.3 参与技术方案评审
（1）描述：需求通过评审后两天，技术人员在充分理解需求后，要过一遍技术方案，产品参与技术方案评审有两个目的：第一是听技术人员讲一遍需求，过一遍核心业务点，可以了解技术人员对需求的理解是否存在偏差，是否有遗漏；第二同时也是产品学习的一个过程，去充分理解技术实现的过程，在需求开发过程中可降低沟通成本。
2.4 参与测试用例评审
（1）描述：提测前两天，测试人员要细致得列出所有的功能的测试点，然后在会上一条一条过，产品参与测试用例评审目的有二：第一是辅助测试人员完善测试用例，需求细节在文档中没有描述清楚，在会上就是很好的纠错环节；第二是发现自己没有考虑到的点，逻辑上的不完整，异常页面缺失等，尽早发现问题，规避风险，同时也警醒产品在下一轮迭代设计中，尽可能考虑周全。
2.5 测试周验收需求
（1）描述：测试周中期阶段，测试人员基本已经把需求主流程跑通了，产品要参与实现效果验收。一切顺利的情况下，把控实现的细节；如果有部分功能子需求来不及实现了，需要记录下来并入库往后排期。
2.6 迭代培训
（1）参与人：本次迭代涉及到的业务方人员
（2）培训框架：
l 功能适用场景：描述需求背景、此次功能目的和要解决的问题，必须要提及本次迭代的功能界线。
l 适用的角色：即谁会用到这个功能
l 功能逻辑，流程：各角色之间是如何使用此功能协助的，需要特别注意哪些点
l 操作指引：在实际的线上系统，完整操作一遍作为演示。
（3）目的：推进功能的使用，降低用户作出改变的成本
2.7 跟踪上线的功能
（1）验证需求：根据需求设计时设定的验证方案，通过线上数据、用户反馈、使用者建议等评估此次需求是否达到预期，找出达不到预期效果的根本原因，思考下一步工作思路。
（2）收集新需求：对于新上线的功能，业务方在使用过程中的问题需要详细记录，必要时转为新需求，持续跟进已上线的功能，不断优化迭代，适应业务高速发展。
一般工作流程是：
1.产品经理(PM)提出产品方面的需求，输出PRD(产品需求文档)和原型图，并发起需求评审会议。
2.交互设计师接到PRD文档后进行梳理和确认，将模糊的需求和功能具体化，制作出低保真交互流程图和页面的结构信息框架，并以文字标注的形式进行交互说明，最终输出交互规范文档，并召开交互评审会议。
3.UI设计师接到交互文档后，第一步并不是马上动手去做，而是要先对需求进行理解，理解该产品的功能内容是什么 服务的人群有哪些特征 产品的目标是什么等等。有疑问的地方及时与PM或交互设计师进行沟通，最终达成对产品目标的一致理解;第二步，找竞品。对竞品的色彩搭配、结构布局、icon设计、字体规范等方面进行研究和分析，可作为参考借鉴，但不要抄袭;第三步，视觉设计。到这一步就可以真正开始动手做了，按照产品的需求，对重要功能和内容进行突出，弱化次要内容，注意整个页面的层级结构和比例关系，保持美观性和易用性之间的平衡。设计过程中参照移动端和PC端的设计规范，遵循一致性设计原则。
第四步，交付。在与PM和设计主管确认设计稿ok后，对页面进行标注和切图的输出。切图根据需要，对于iOS系统，需要提供1倍图、2倍图、3倍图，同时注意切图的命名规范(网上有很多关于切图命名规范的文章，这里不再赘述);对于android系统，主要提供hdpi、xhdpi、xxhdpi、xxxhdpi尺寸的切图，特殊情况还需要提供点九图。
4.开发工程拿到标注稿和切图后，对开始对页面框架进行搭建。这时候，UI设计师的工作并没有结束，跟进和验收也是UI设计工作的重要组成部分，即要保证设计稿的还原度。中途若出现问题，也要及时配合开发小伙伴一起解决。一个优秀的UI设计师，除了关注设计执行上的工作以外，前期的设计规划和后期的迭代跟进同样需要关注。
以上就是青藤小编关于UI设计师如何与产品经理以及开发协同合作的相关分享，希望对大家有所帮助，如果您想要了解更多相关内容，欢迎大家及时在本平台进行查看哦!
产品经理是以解决问题为核心，整合和管理各种人力、物力等资源，高效地将解决方案变成实际产品输出的领导者。
在不同的公司，产品经理的角色和职责虽略有差异，但是核心职责是相通的，我们可以从产品研发的五个阶段来解读产品经理的主要工作内容：
一、产品规划
产品规划的目的在于让研发工作开展更有序。
在产品规划阶段，产品经理的职责就是做好前期调研工作，输出完整的产品规划方案。
前期调研的主要工作包括市场调研、政策分析、行业动态、竞品分析、客户调研等；做好前期的调研工作后，产品经理要对调研结果和数据做进一步的梳理，明确产品的定位，结合自身资源情况，明确业务发展趋势，规划系统建设方向，最后输出一份完整的产品规划方案。
二、需求分析
需求分析的过程不是简单的需求搬运，产品经理首先需要将收集的需求根据实际情况进行分类，如根据对象的不同，可将需求分为业务需求、用户需求、功能需求三类。
将需求分好类后，产品经理可从真实性、价值性、可行性三个维度对需求进行筛选，过滤掉虚假的、不可行的、没有价值、价值不大或投入产出比不理想的需求，并从剩下的需求中提炼出客户的本质需求。
然后对需求进行归类并排出优先级，帮助产品有条理地安排开发秩序，最后输出需求文档。
三、产品设计
产品设计的过程就是将产品需求功能化、具像化的过程，产品经理需要输出具体的能达成需求目标的功能设计方案，以支撑需求方、研发团队、运营团队等相关方进行高效沟通与业务执行。这一阶段产品经理的主要工作包括流程设计、功能架构、原型设计等。
四、推动产品目标的实现
首先，产品经理需要协调各岗位的时间进度，进一步解答各岗位对需求的疑问。
其次，产品经理还要对开发过程中遇到的困难进行正确判断，排除外界对开发的干扰因素，为开发团队排除困难，并及时作出需求变更或技术方案攻关的决定，跟踪产品的研发进度，确保研发工作顺利进行。
在这个过程中，产品经理应做好与上级领导及团队成员之间沟通协调工作，保持各方信息的一致性，进行有效的沟通，保证产品按既定目标前进。
五、产品的验收与交付
产品上线后，产品经理要及时关注相关数据，并做好数据分析工作。以数据为依据评估产品或功能是否达到预期效果，如果没有达到预期效果，产品经理要牵头做好复盘工作，分析未达到预期效果的原因，输出完善的举措和计划，并切实执行。同时产品经理还需及时跟踪客户反馈，为下个版本或产品积累数据和经验。
做产品所形成的这些思维不一定只适用于产品行业，它也是可以跨界应用到很多领域的，帮你在工作中更加明确要做什么，以及在确定怎么做、找资源、推动实现方案、持续打磨优化等方面都有能应用之处。
小张从毕业到现在一直从事互联网产品工作，期间在不同的产品团队做过不同的产品，有成有败。
在和不同行业、不同领域的朋友交谈过程中，察觉到产品的思考方式是可以跨界应用到很多领域去做事情，今天就来初步聊聊这个话题。
一、产品工作概述
先大致描述目前成熟互联网公司中产品经理的工作流程：
1.需求收集和分析：产品经理工作的开端是需要明确要做什么，这部分包括：
(1).信息收集：对用户反馈的收集、对竞品的研究、对行业的理解、合作团队的反馈，初步收集需求。
(2).分析&管理需求：分析收集到的信息和需求，整理出有价值的需求，并进行优先级排序。
2.输出方案：即确定怎么做。确定续期的优先级后，针对每一个需求希望达到的目的，设计相应的策划方案，满足需求、解决问题。
3.协调设计、开发、测试：有了方案，接下来就是需要通过评审拿资源，让其他岗位的同事愿意接受你的方案。
当方案经过各方评估确认后，即可进入到设计开发中，等待功能上线，当然这个过程中还会涉及到人力的协调、设计开发方案的评审等。
4.功能实现上线：功能经过设计、开发、测试后，即可对用户发布，在这个过程中，如何进行项目管理，提高整体的执行力，保证按照预定的计划高质量完成是一个很考验项目管理能力的活儿。
功能上线中，一些较为关键的功能还会涉及到逐步灰度放量，比如一期先放10%的用户，看效果，在评估是否继续放量。
5.反馈收集：功能上线后，产品还需要持续收集用户反馈，“持续打磨优化产品”。
包括功能的数据表现反馈，例如有多少用户使用、留存如何、点击率如何等；以及用户对功能的实际反馈，例如体验是否顺畅、是否有不明确的逻辑等。
以上是简化版描述的产品经理工作，归结起来可以概括为以下几点，在接下来的部分将讲下这五点可以如何应用在其他领域：
明确要做什么确定怎么做找资源推动实现方案持续打磨优化
二、应用到其他领域
1.明确要做什么：
找到机会需要保持对市场的敏感和生活的敏感：
(1).对市场的敏感：即对你所处的行业中变量的敏感。
例如对互联网开发者而言，目前开发app显然是件高成本低收益的事情，但是小程序开发已然是逐渐起风的风口；对于内容创作者而言，公众号的打开率已经很低了，而抖音则是势如劈竹正当时；
(2).对生活的敏感：即保持对身边新事物的观察和关注。
例如前段时间我刷朋友圈就发现很多朋友在分享在薄荷阅读中的阅读经历；观察到这两年身边养宠物的朋友越来越多；观察到营销玩法从一线城市传播到三线城市的时间间隙越来越短；观察到现在学生毕业的求职成本越来越高，竞争越来越大，大公司对专业度的要求也越来越高；这些都是可能产生新机会的领域。
2.确定怎么做：
找到你想要解决的需求后，接下来就是明确解决问题的方案：
(1).产品化的方案：作为互联网产品狗，当我发现有需求需要解决后，我的条件反射就是这个可以通过做个什么产品来满足，产品的核心功能点是什么，产品的交互、形态、体验是如何的。
这些都是偏互联网人的直接反应，就先不展开了。
(2).运营类的方案：这点是我想要重点展开讲的。在18年这个时间节点，互联网产品已经基本应有尽有了，在这种情况下，通过利用各种已有产品来做运营的方式来解决问题就显的更为重要。
你可以在公众号、头条写文章，在知识星球运营粉丝圈，在抖音、快手po视频，在斗鱼、YY、映客做直播，在淘宝、京东、拼多多做电商。凡此种种，都是不需要自己再做“产品”的解决方案，需要的是你在已有的产品上为你的目标用户做好你的服务和运营。
而如何针对你的目标用户制定运营计划就是一个比较费脑子的事情，如何获得最初的用户，如何让他们留下来，如何转化为付费用户实现商业化，都是需要去思考和设计的。
3.找资源：
思考梳理完解决方案后，接下来就是找资源了，这也是我发现对很多互联网人来讲比较难的一步。如果是开发类的解决方案，则需要找设计、开发人员配合，实现成本在我看来是不高不低。
但是现在的互联网产品已经过了可以自然爆发的解决，开发完后的如何让产品运营起来才是最难的。这个时候需要找流量、找投资、找变现方式，这些都是需要去找资源完成的。
同样，如果是想要通过做抖音或者头条号赚钱，也需要去思考如何制作高质量的视频，如何卖货赚钱。
4.推动实现方案：
明确方案+找到资源后，需要的就是执行力，将方案落地，这很考验团队的执行力。
执行力是讲起来很简单的三个字，但是发现能做好的人非常之少。
简单讲讲我对执行力的理解，最基础的要求是能把事情按时按量完成。如果是在公司，可能大部分人还是可以达到这个要求的，毕竟有老板催着，但是如果是兼职类项目，发现能够做到这点的人真的少的可怜，可见大部分人都是需要被逼着才能前进的。
再往上理解一层的执行力，即使可以让团队按时按量完成工作，是偏向项目管理了。这点不是对每个人的要求，而是对负责该功能的产品经理，或者团队负责人的要求，需要通过指定团队规划、定期review等方式不断推进团队整体前行。这是一件很累的事情，特别是在你还不是老板的时候，但是如果通过一定的流程固定下来，对提高团队的执行力是非常重要的。
5.持续打磨优化：
所有的产品或者解决方案初期完成后，都需要不断按照受众的反馈和反应去调整，满足市场or用户需求这件事情是没有止境的。
通过观察数据，你可以发现你在哪个环节是薄弱的；通过和受众沟通，你可以发现他们主要吐槽的点是在哪里，针对这些点，无论是产品功能的优化还是运营方案的调整，都可以去提高你的服务，满足他们的需求，提高你的竞争力。
三、尾言
无论是想要好一款产品或者做成一件事情很难，今天仅从产品视角简单解读大体的框架，其实其中每一点都可以展开来写，后续有机会可以再就每项展开来写。
也欢迎大家找我聊你们对大框架或者每一点的感悟。
#专栏作家#
产品小张，微信公众号：产品小张,人人都是产品经理专栏作家，每周一篇深度文章带你用产品思维解读各类事物。
题图来自unsplash，基于CC0协议
大家在关注
