作者从事产品岗位已经一年多了，负责的内容也都是C端的前端产品规划及产品设计的内容，有从0到1，也有从1到2，经历过一周需求到上线，也经历过效果不佳而迫停，走到现在也是一路坎坷。将这一路总结成文，希望对你有所帮助。
回顾一下，把自己踩过的坑和经历总结出来，给自己一个成长的总结，也给一些产品新人提供一些经验。
市面上的产品多种多样，但是每个产品从概念到成型的历程一般都脱离不了用户体验要素中所提到的战略、范围、结构、框架和表现五个层次。每个层次对于产品经理的要求也不尽相同，也从一定程度上要求了产品经理必须是一个全能的职业。产品经理在工作中是贯穿整个项目过程的，从需求到上线，包括后期的迭代，大部分工作都是由产品经理来策划跟进推动的。
一.需求到功能
通常有几种：
团队内部
运营、老板等外部因素
用户调研；
团队内部的需求通常来源于头脑风暴，少部分来源于某些团队成员的会外建议，这部分人对产品本身的认识是最深刻的，提议的出发点通常是产品本身。
来源于竞品的需求通常是说服力比较高的，但是在分析需求的过程中记得考虑下用户在什么场景下会产生这种需求，尤其是竞品产生新功能的时候，尤其注意这时候功能的复制是不是合理的。
运营和老板的需求我把他们放到一起，这类需求的来源通常让产品经理非常被动，通常他们会说我们的产品为什么没有XX功能，为什么我们的功能和别人不一样，作为产品，不要偏听他们的一面之词，要挖掘到他们提出需求的本质，并且注意他们只是需求提供者，并不是方案提供者。
用户调研也是比较有效的一种需求来源，通过用户访谈，观察用户使用同类产品或者同类功能时的行为，甚至通过问卷来分析用户的心理情况，都是可取的，但是操作过程中也要注意用户的“说谎行为”，产品完成后使用者的反馈意见也很重要，也是收集需求的一个有效渠道。
需求收集后，建立产品需求的需求池，以便于对需求进行分析管理。通常需求池的模板如下：
2.需求整理
需求整理是每个产品经理都要掌握的技能，而且每个产品经理采用的方式不尽相同；一个产品的服务对象永远不会是所有人，这里介绍一个比较常用的方式，5W2H的方法，分析受众（WHO）在什么时间（WHEN）什么地点（WHERE）因为什么（WHY）去做什么（WHAT）,怎么做（HOW）,会付出什么（HOW MUCH）,以此来定位该需求是不是伪需求，如果不是伪需求，对应该需求用什么功能来解决。
3.需求分析
以KANO模型去分析需求中的基本型需求、期望型需求和兴奋型需求，以此配合产品的当前发展阶段来给需求进行分期完成。
（下图来源于人人都是产品经理《需求评审之前，需求挖掘和需求管理怎么做？》）
该文中作者还对KANO模型做了一系列的延伸，在基本型需求、期望型需求和兴奋型需求的基础上增加了无差异需求和反向需求。
基本型需求是必须具备的，用户觉得是本来就该有的，一般是产品的基本属性和基本功能；
期望型需求是用户期望有的，没有可以接受，但是有了会非常认可；
兴奋型需求是用户所没有想到的，超出用户预期的需求，提供后用户会产生惊喜；
无差异需求是有没有对用户都无所谓，用户不在意；
反向需求则是用户根本没有这种需求，提供后会影响用户的满意度。
基本需求通常是产品最基本的功能，不能缺少，不然不足以支持整个产品的功能及框架；期望需求也是产品第一版本所需要考虑到的内容，如果功能缺失造成用户的体验不好，会造成很大程度的用户流失；而对于兴奋型需求，往往是产品的卖点，但是在资源或时间紧缺的情况下可以考虑适当延后，但是最终还是要落实到产品上；无差异需求可以考虑下商业价值，如果在不影响用户的情况下获取利益，是最好的方式了；反向需求就像产品中的广告，用户很讨厌，但是为了商业价值还是要妥协。
二.功能到结构
这个内容的主要目的有两点：
产品功能的层级结构的确认；
对功能实现的成本进行预测；
用户在使用某个功能时的有关因素包括：用户自身属性，场景属性，用户行为属性；每个因素都对用户使用该功能有着不可避免的影响，在确定产品功能的重要性时需要给每个影响因素设定一个影响指数，和每个因素在产品中的比重值。
目标用户人群的基本属性指数a（性别，年龄，职业等自然属性），用户基本属性的比重值为x；用户的行为属性指数b（兴趣，习惯等），用户行为的比重值为y;场景属性指数c（时间，地点，环境，要做什么等），场景属性比重值为z；该功能在产品中的重要指数即可通过a*x+b*y+c*z进行一个粗略估计。我通常取值a+b+c=1，x+y+z=10,这样获得的数值对比性比较明确，参考性也比较强，有一定数据时获得的结果准确性更高，有一定量数据的情况下参数的取值也要根据数据而定，不能根据猜测来判断。功能的分类也通常是根据场景来划分的，而一些使用频率不高的功能就会选择弱化一些。
这个过程通常可以把产品中每项功能的重要性和层级展示出来，为后期的产品设计提供很强的依据。
其次，在功能确定之后，需要带上团队的设计师及开发人员进行工期预估会议，这个会议的目的有两个一是为了给项目一个大概的节点，使项目从开始到上线的过程中有一个计划，便于进行时间管理和提高团队效率；第二个目的是要在会议过程中判断某些兴奋性需求的功能实现性价比，能否在不影响整个项目进度的情况下把产品功能做的完美，还是因为时间问题把一些功能延期，产品经理也要在这个过程中慢慢的学会自己判断功能实现的时间成本，避免因为没有经验而被程序员忽悠。
三.结构到框架
产品结构到产品框架的过程可以说是产品经理到交互设计师的交接过程，然而大部分公司都是由产品经理把这部分工作做掉的，这个环节主要包括三个方面：产品的内容设计，产品的操作逻辑，页面上的框架布局，体现到成果上即产品内容及产品原型和逻辑图、时序图等。
内容设计
产品的内容设计是产品的内容核心，通常也是一个产品的立足之本，没有好的内容就不会有好的体验，即使页面效果做得再好，对用户也毫无吸引力。相反，如果产品本身的内容质量足够高，哪怕在功能和页面上有瑕疵，也可以通过快速迭代的方式来改善。简单举几个例子，爱奇艺、腾讯视频等播放器需要足够的视频资源及分类；直播平台的主播及直播内容都可以说是平台的内容；只有内容的定位精确和资源足够的情况下，产品功能的设计才有意义。
操作逻辑
操作逻辑是所有产品体验中必不可少的一个环节，无论是前端还是后台都非常重要（当然区别在于前端重体验，后端重逻辑，权重值不同）。产品的定位用户通过聚类和分类后都可以把用户分为几个固定的群体，每个群里内的用户存在几个或多个共同的特点，或者说有一些相似的用户习惯，针对主要用户群体的用户习惯形成的操作逻辑和操作方式，用户活跃程度才更容易保持。操作逻辑可以简单分解为信息传递和操作反馈两部分，信息传递是产品页面上给用户传递的信息及可操作性，操作反馈则是用户产生操作行为后会有一个假象的反馈，或者说结果，而我们的任务就是去设计应该给用户什么样的反馈及以怎么样的形式来展现。
原型设计
原型设计是把需求传达给设计师的媒介，也是对产品框架的设计，同时也是产品经理的入门基础。绘制原型的目的主要包括几个方面：
搭建产品框架，清晰的表达思路；
提高效率，减少和设计师、程序员的沟通成本；
为产品备案。
首先在绘制原型的过程中，产品经理对产品逻辑和业务逻辑会有更深入的理解和思考，产品逻辑出现问题时也可以及时的进行修改；
其次减少沟通成本，一是减少和项目组外成员的沟通成本，通过原型的展示使产品逻辑更直接的展示出来，使更容易理解产品；二是减少产品设计开发中的沟通成本，好的原型可以减少很多的口头沟通成本，而且复用性很高，产品设计开发过程中可以节省很多的时间。最好每个项目组或者产品团队要有自己的原型设计规范，一方面是为了原型设计的美观，另一方面根据规范撰写的产品逻辑和备注说明更容易被设计师和工程师理解，其次在原型设计时可以节省很多时间。最后根据产品规范设计的原型可以更方便的让新人学习，减少培训成本，在产品负责人缺失时后续产品可以更好的衔接上。
四.框架到设计
UI设计：UI设计主要的工作内容就是把产品设计优化然后展示给用户，然后交付到开发实现。关于设计所涉及的几个问题：布局、配色、文字、按钮、切图、适配。其中布局、配色、按钮和文字在每个不同的产品中都有不同的规范标准；而切图和适配则是UI行业内统一的规范及标准；
PCweb和APP的差别较大，手机web则可以看做两者之间的过渡。当然目前APP更热一点，以app为例，建立规范和标准，另外最好用一套规范去适配Android和iOS两个平台来降低设计成本。当然每个产品的标准和规范并不相同，在此以APP为例举个例子：
关于尺寸：
标准色：
标准字：
按钮:
这只是一个粗略的设计规范，另外如何划分模块、图文间距、公共控件等都需要有一个详细的设计规范，希望大家都配合设计师确定一下。设计稿评审通过之后，标注切图交付到开发。
五.设计到开发
设计图完成之后，按照功能或模块把产品拆分开来，进行开发评审会议，主要目的为分别确定功能完成所需时间同时确定功能开发的优先级，该会议需要前后端和产品同时参与。按照功能或模块的优先级把任务安排到前后端负责人。
前端确定开发的页面量级和难度，难点需要整理出来确定解决时间（特别困难的情况下衡量下需求是否要简化或者延期）。
后端确定需搭建或维护的数据库，需要的接口量级，难点需要整理出来确定解决时间（特别困难的情况下衡量下需求是否要简化或者延期）。
注意把控开发进度，两个点：一个时间，一个效果。时间是按照项目规划按时完成，一般每天最少一次跟进下进度，尽量把任务分配到天，每天都完成一部分。另外实现效果不能防水，以一个高标准去要求最后的产品效果，即使最后只能达到80%，也是一个可以推出的东西，如果以80%的效果去要求，最后很可能连60%都打不到。
最后一点，尽量和开发打好关系，尤其是经常给你干活的开发，处理好关系给你的帮助会远远大于你的付出。
六.产品的迭代
不论是硬件产品还是互联网产品都逃脱不了产品的生命周期论，这就无可避免的需要产品进行迭代，而互联网产品的迭代频率又远远高于硬件产品，迭代的过程贯穿在整个产品的生命周期中。
互联网产品的生命周期中，导入期通常是产品一期产品的推广和迭代，用户量会逐渐增多，需求的数量也是逐渐增多，这个过程会一直持续到产品的成熟期，在成熟期阶段，产品的新需求会越来越少，更多的是产品的维护和调整，而用户量还是会缓慢增加；当到达衰退期时，需求会严重减少，而用户也会在这个阶段去寻找更好用的产品，这时产品通常需要一个大的改版来挽留用户，如果成功，则会把产品推入到一个新的产品生命周期。通常一个成功的产品是需要持续对市场产品进行调研分析，然后对自己的产品进行调整和迭代的。
产品迭代和产品创建过程中的需求来源是有很大区别的。前期的需求来源比较简单，后期迭代中的需求更多的需要依靠数据统计和用户反馈来进行改版。大到一个模块、一个功能，小到一个按钮、一个色块，在迭代阶段不能是简单的拍脑袋，而是需要一定的数据支撑；日活、留存、点击量、转化量都是参考；改版上线的过程通常也是以灰色发布为主，A/B测试就是其中一种，通过两种方案的数据对比来获取最终选择方案，过程比较缓慢，但是很有效果。
产品迭代的时间规划视团队内部的合作方式而定，频繁无周期的改版和长周期改版都是不合理的方式，前者影响工作效率，后者影响产品更新进度。建议在没有大调整的情况下2-4周做一次改版，而且周期固定，形成团队的工作习惯；当有大的调整时，视资源和开发进度在时间上进行调整。
这是我工作一年的小结，希望可以互相交流。
