产品新人想要快速地成长，不仅需要时间和经验的积累，还需要主动地沉淀，形成自己得框架。

入产品坑已1年有余，是该有写一点东西的必要了。真的该有写一点东西的必要了（借用一下鲁迅先生的手法~）在不断的practice后，总结下来，大致总是以下这4个方面的事情：

一、需求管理

据我这1年多近2年的临床经验，虽说资历不够，但不多不少，还学到点东西~

相信所有的产品新人刚入行时，接触的最多的行业概念都是“需求”吧，当然我也不例外，也是从需求开始做起，到现在带小组做项目，自己经手产品从0开始到上线的方方面面。

1. 需求收集

其实一开始上司大多会让你去跟进一些功能优化的需求，因为这只需要在了解业务的基础上，对功能优化点进行跟进即可，几乎没有难度。这阶段还不知道怎么去挖掘需求。

当你跟需求有一段时间后，你的疑问就来了，为什么要这样优化？是谁提的要优化？做了这个优化对什么东西造成什么影响…… 也就是产品人常常挂在嘴边的需求分析的5W+1H原则了。

跨过了这个阶段后，就到了收集需求阶段。需求收集无外乎3个来源，3个途径：

需求来源

• 公司相关业务部门（市场、运营、销售、客服等）
• 用户/客户
• 产品经理/老板创造需求（这需要产品经理本身具备很高的产品素质）

PS：乔老爷子曾经说过：People don’t know what they want until you show it to them”（在你把东西拿出来之前，用户根本不知道想要什么）。前人留话了，有时候，我们需要去创造需求。但世界只有一个乔布斯，因此我们还是脚踏实地，仰望大佬吧~

收集方式

• 用户调研/ 反馈：问卷调查、用户访谈、信息采集（包括工作人员在内）
• 来自boss的idea（boss根据他对市场的敏锐度做出的决策）
• 产品数据分析：功能数据、市场数据、竞品分析数据

产品从无到有阶段，需求来源多半是由产品经理/老板用数据分析的方式获得需求。项目落地实施阶段，需求来源大多是从用户调研/反馈得之。项目运行数月后，用户反馈、数据分析则变成了主要的收集方式。

2. 需求分析

需求分析，用哲学上的一句经典名言来说：从哪里来？要到哪里去？这句话用在需求分析上再合适不过。延伸一下，就是需求分析的5W+1H原则了：

• what：需求是什么？
• who：谁提出来的？
• why：为什么要做这个需求？
• where：什么场景下有这个需求?
• when：该场景下的什么时候需要用到这个需求？
• how：怎么做这个需求？

有时候，用户的需求并不会很直接的告诉你。好比女生在和男生交往的过程中，某天拿着美妆博主的试色图片和对方说：你看她涂这个颜色真的好好看哦。这时钢铁直男和情圣的反应就完全不一样了。

直男：我觉得都一样啊，都是红色，并附带黑人问号脸；情圣：确实好看，也很适合你哦(过两天约会的适合用精美的礼盒包好送到女生手里)。同样的话，不同的答案造成的心里落差，可谓千差万别！！

有时候，或者说用户根本不知道自己要什么（前面提到过）。你需要去引导，或者去思考用户言语背后的真实需求。

共享单车出来之前，我想大家都有最后1公里的困扰。但那时候，如果你跟别人说，公司去地铁站好远啊，坐公交很堵，走路又太慢，那对方对半会跟你说：买电动车吧，骑车去公司；买个代步车吧等等。

直到摩拜单车出现在大众视野，我们才知道，自己不过是想要解决最后1公里的困扰（想给共享单车的发明者加鸡腿）。其实这样的例子很多，只要仔细留心身边的一切。

3. 需求跟进

据我这1年多的“临床经验”，一个需求的完整生命周期可以划分为6个部分：

1. 需求确认阶段：该阶段需要将收集到的需求加以确认，再根据需求的重要程度进行优先级排序。一般是在月初，因此一般会定下本月要做的需求（这个视团队习惯而定）。
2. 需求设计阶段：这阶段产品们会将需求转换成原型图，并且将初版的prd输出，发送到团队群内。供研发团队进行一个初步的技术评估。
3. 需求再确认&开发排期：开发和产品们会就第二阶段产品输出的原型及prd进行一次头脑风暴及需求确认，确保双方的理解一致，减少后期因为理解偏差造成的影响。
4. 需求跟进阶段：产品会根据上一阶段的开会结果，重新整理prd，发到团队的协作平台上，并及时更新。协作平台的内容包括各个系统的需求池，以及问题记录。当然，产品还会实时跟进开发进度，处理开发在开发过程中遇到的各种疑难杂症。
5. 测试验收阶段：以PRD文档为准进行测试验收(PS：小公司有可能根本没有测试，因此产品还要承担测试的工作)。开发根据测试结果进行问题修复，全部修复完成后，提交代码，发布上线。
6. 运维阶段：需求上线，并不是需求的终点，而是产品投入市场的起点。需要产品人通过跟进用户反馈，对正式数据进行对比分析，验证是否真的满足用户需求。然后不断的更新迭代~

PS：运营阶段还有一件重要的事，在需求上线之前，一定要和各个需使用到该需求的业务部门沟通好，甚至说培训好。否则上线后，会措手不及，甚至导致各部门之间的不愉快~

二、产品设计

清楚地记得，第一次设计的产品是一个APP的订单列表页面，现在看来这不是信手拈来么，但当时由于业务不熟，产品概念还未形成，以至于根本不知道从哪里下手。

幸好有巨人的肩膀可以站立，通过对其他APP的借鉴和模仿，倒也没出什么逻辑问题，只是设计缺乏重点，如图(大家可尽情吐槽)：

 图2-1

1. 前端

前端也可笼统的称为客户端，在没有微信小程序之前，前端有APP设计，WEB设计。

微信小程序的风刮起来后，做前端的产品还需做微信端设计。一般情况下，都是APP+微信小程序组合~

前端产品既要好看，更要实用，二者缺一不可。但非要说一个更重要的，那还得是“实用”。毕竟，解决用户问题的产品才是好产品~

入行的时候这个观念就已深深藏在我脑海里，因此我一直都特别注重实用~  差点忘记好看，所幸公司的UI设计师一定程度上弥补了我的不足。

在反复和设计师交流的过程中，了解了一些“好看”方面的知识（同设计师交流，必须多学点UI方面的知识，不然怨念很深~）

另外没接触过微信小程序设计的同学，做之前，请一定要先看微信小程序设计规范！！不要问为什么，等做出来四不像时，你就知道为什么了。

2. 后台

后台系统常见的有开放式后台系统和非开放式后台系统。相对来说，公司大多都还是非开放式后台用的多些。

开放式后台系统常见的有：微信公众平台、淘宝卖家平台等；开放式的后台在用户体验上会稍微注重些.

非开放式后台不会在界面上提供注册功能，后台系统用户的添加一般是拥有相关权限的管理员添加配置，最常见的是ERP系统。(这1年多，我从专门负责1个ERP后台&APP，到现在同时兼顾2个。由于前1个系统已经非常稳定，因此大部分时间都放在维护今年3月开始的新系统上~）

后台设计，非常注重业务逻辑的流转，在没有了解清楚业务的每个细节前，千万不要轻易下手。否则后面会有无止境的修改(开发心里会骂你一百遍，就问你怕不怕)。流程图是必须的，重要功能的时序图也是必须的；

这是很久之前画的比较笼统的促销活动流程图和时序图（献丑了）：

2-2-1 流程图

2-2-2流程图

三、数据分析（功能）

数据分析不可谓不重要，一切想法要论证是否正确，都必须通过数据说话。但刚入行根本没有数据概念，一心埋头苦干。

直到某次作报告，总监问到我转化率是多少的时候，我一头雾水……才开始关注数据。

PS：首先声明，这里说的数据分析特指功能数据分析，不泛指行业、市场等数据的分析，这种分析可在数据分析网站上查看行业报告。就不细说，最主要是我觉得以我目前的知识面来说，不足以将这种数据看的透彻~

1. 数据来源（常用的有2种）

1. 采用基于前端页面的数据采集工具获取，如小程序的数据助手等可视化的数据采集产品；
2. 通过数据埋点的方式，在开发时根据设计提出的需要埋点的地方进行数据采集，需要时从数据库导出查看即可。

2. 优缺点对比

用数据采集工具

• 优点：不用费时费力去做开发，方便快捷，一般都有载体产品，可随时查看；
• 缺点：特定的数据无法自定义，统计数据相对概念化。

通过数据埋点可

• 优点：可自定义任何自己想要的数据，尤其能够满足特定场景下的特定场景的数据统计；
• 缺点：费时费力，需要人工成本较高，从前期到设计都需要耗时耗力；

PS：附一张数据埋点的表（仅供参考，请多指教）

四、项目管理

PS：由于是中型创业公司，组织机构不够完善，并没有项目经理的存在，因此，我们产品基本上承担了项目经理的责任；

由于本人资历尚浅，经验不足，在项目管理方面，我只做到了解每一个人的性格&做事风格。

甚是幸运，这1年多与项目小组的所有开发人员都相处得十分愉快，项目进行的也很顺利。大概是他们性格好，又肯配合，技术又很给力(给他们加鸡腿，真的给力)！这一年，我们项目组每月的绩效，半数以上都是超过100%的~

关于项目管理，过个几年在来写可能会不那么尴尬，现在写有种小孩扮大人的感觉~暂时就写这么多，谢谢大家，欢迎大家指出我的不足之处，和我交流心得体会，但不欢迎喷子~

本文由@lucky 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议