文章分享了作者近期的一个项目总结，其中梳理了工作上的一些细节与知识点，希望能够给你带来些启发。

夜已深，整间屋子里只有台灯发出泛黄的光，还有笔记本中的输入光标在闪烁。

工作上，项目已经内测完，也到了上线的时候，这是我在该公司负责过的第二个项目（产品），由自己规划并设计的产品，如今就要上线了，虽然往后的运营也是一段艰难的路，但要上线了心里没有那么一点点喜悦也是假的。

细细的回想，整个过程依然存在很多需要思考和改善的地方，总结一下，也正好梳理一下细节知识点。

一切的开始

今年5月底时，boss叫上合伙人还有身为产品部的负责人的我（恩，产品部只有我一人）开了一个短暂的会议，主题是关于公司新项目的问题，一个纯线上的ToC产品。公司是一家自带流量资源的自媒体公司，所以只要产品的业务明确，资源在手，体验足够好，上线后段时间内基本上是不用担心用户量的问题。当时boss和合伙人们都说的挺带劲的，对项目上线后带来的变现充满了期待。但是我又有些许的担忧，因为当时boss提出来要进入的垂直细分的市场，已经发展了挺久了，而且该市场近几年的发展形势不是特别乐观。当我向大家提出我的看法的时候，大家也安静了一下，然后boss说，我的顾虑也有道理的，但是公司当前有流量和相关合作资源，而开发项目的成本不高，总的来说该项目还是具有高性价比的。

从商业、公司负责人的角度来看，这是合情合理的，一个企业要生存下去，在业务上就需要获得盈利的能力，这是首要条件。从短期来看，结合公司自身的资源分析是能带来盈利，这点我也明白，他们又他们的考虑，所以也没有再发表过多的意见。

到了后来，自己认真的思考一下，现在纯线上的项目已经很难有市场了，在这几年，用户的需求基本被挖掘殆尽，都已经有了成熟产品来满足用户的需求，而且用户习惯也慢慢的养成了。所以线上流量的成本在这几年不断的飙升，正因如此，很多公司也开始把自己产品流量入口慢慢转向线下，同时也开始与线下的业务相结合，形成线上与线下的闭环。而O2O就属于这个范畴，只不过因为之前大家都把这个行业消耗掉了，说起O2O就会下意识的想起烧钱，但是从方向来看，线上与线下想结合是很符合市场发展前景的。

在未来的几年，互联网的重心从产品转向业务，从单纯的线上转向线上与线下相结合，再有AI的加码，还是有一番想象的空间。

有点扯远了，还是回来吧。

市场调研，还是要好好做

这个ToC的项目所处的细分市场很小，而且并不在主流的范围内，虽说是已经发展了比较久。所以在网络上相关的信息太少，当然也没有市场调查数据可以研究和参考。刚开始从易观智库、艾瑞等比较有权威的调研网站中查找是否有相关的行业分析报告，但是结果显而易见。然后就只能从最方便的百度、Google搜索相关行业市场的信息，搜索得到的结果并不多。而搜索到的信息也是参差不齐，搜索到的文章也有一定的年代。

陆陆续续的收集了相关的信息，然后翻翻百度指数，查到了相关行业的大体趋势，并调研分析了市场上主要玩家的情况，最后进行市场问卷调研，得出了一个稍微比较满意的分析结果。虽说市场的容量小、发展空间不大，但是用户的对该行业保有兴趣，并且公司有相关流量和资源，结合SWOT的分析后还是可以进入该市场的。

现在看来，其实当时做市场调研的时候，并没有做的太过深入的分析，当然也有时间这个外部因素的限制。虽说是市场调研的结论只是起到辅助作用，但是能为后面的发展减少不少的麻烦，还是要好好做的。对于行业、市场小，没有相关权威的信息可查，其实就相当于研究一个新兴的行业一样，要对一个陌生的行业进行调研，归根结底是从四个方面入手。

首先是要尽可能的追本溯源，了解行业产生的原因， 服务链条的关键环节；然后就是学习并研究行业巨头的演变过程，巨头的发展往往包含社会、政治、经济、科技、管理、策略等多重原因，他们的演变更能体现出市场的变化；接着就是分析行业中主要存在的商业模式与商业格局；最后就是尽可能多的使用不同产品，一定要有自己的总结感悟，做到对市场的上下游的了解透彻。当然现实中并没有那么多的时间给你去研究搞搞市场，所以产品经理的平时对行业的积累、对市场敏感度的锻炼尤为重要。

竞品分析，很必要

记得当时自己也是有意识的做了有针对性竞品分析，从事后来看也符合预期。

竞品分析报告是竞品分析的直接输出物。我们平时在网上看到大多数分析报告其实是不合格的，因为很多竞品分析报告，实际上只能算是产品体验报告，基本的模块就是“客观的第三方数据内容+纯展示竞品5维度”，这样一篇几千字的报告，半小时看下来，不知道其目的是做啥子的。

真正的竞品分析报告，是针对某个阶段产品或发展需求所面临的挑战/困难，缩小范围针对性分析，对症下良药。比如说一个产品正在处于产品的概念阶段（当时我的情况），那么此时的竞品分析主要是针对市场（用户需求、市场容量、现状）、商业模式等维度进行深入分析，至于其余的产品架构、功能、流程、交互、运营等维度，暂时可不考虑。这样不仅可以减少工作量，还能有目的、针对性的做出分析。

在做竞品分析时，其实很多产品经理都忘了一点，就是需要结合公司自身情况来发掘出自身特有的竞争力，而不是最后都是做“参考”的内容，不然做出来的产品都呈现出同质化倾向。

用户调研！重要!

在这个产品开发的过程中，因为时间过于紧迫，根本没有时间做这部分的内容。这也是小团队为追求短平快的通病吧。

不过如果有条件做，大概流程应该是这样做的。在此之前先复习一下用户调研的作用：

通过对用户的任务操作特性、知觉特征、认知心理特征的研究，使用户的实际需求成为产品设计的导向，使产品更符合用户的习惯、经验和期待。

在做用户调研时，要按照以下步骤进行。

第一点是需要明确做这件事的目的。所以进行用户调研之前，需要明确用户调研的目的。只有明确调研的目的，才能有效的指明用户调研的方向。

第二点是确定进行调研的用户，即要找到目标用户。那么如何找到目标用户？就需要运用产品的“用户画像”，完整的用户画像流程可以分为四步。第一步是用户信息收集，第二步是用户信息分析，第三步是用户信息验证，第四步是用户画像优化。

第三点确定调研方式，个人会选择最普遍而又高效的用户访谈。需要做的是准备好问题，同时需要对用户进行分析，给出可能的答案以及答案背后的深度问题挖掘。
剩下的就是调研工作，也是考验产品经理的时候。然后写调研报告以及根据报告结论指导下一步的工作。

用户研究不仅对公司设计产品有帮助，而且让产品的使用者受益，是对两者互利的。所以有条件时，用户调研还是很必要的。

产品规划与设计

这一部分，现在想起来，由于没有及时与技术人员沟通说明，导致后面开发人员没有注意到细节部分的内容，这个还是比较亏的。不过这个今后也会做出明确反省。

产品的规划与设计，这两个部分核心的思路，便是用户体验要素（战略层、范围层、结构层、框架层和表现层）。

产品规划（战略层）

完成了主要竞品的分析之后，自己的思路清晰了许多。对接下来的产品规划有很大的帮助。产品规划的内容，核心内容无非这几个：

• 确定产品战略方向
• 确定产品定位、市场定位
• 确定目标用户
• 确定产品的使用场景
• 确定商业模式
• 版本迭代计划

整个产品规划阶段，基本都是围绕在这几个核心进行展开。

当时制定产品规划时，也是按照上面的步骤进行，不过这些内容和方向的确定都是经过前面的大量工作才能完成的。

功能需求（范围层）

完成产品的规划，就进入了产品的设计阶段，在这一阶段，最难的一步应该是如何把需求转换为功能了，只要把这个问题解决了，后面的工作也就好说了。那如何将用户需求转换为产品需求？这时“二八原则”就开始发挥了。就是说，只有普遍用户的需求，才能转换为产品需求，进而制定功能模解决用户的需求痛点。这个过程需要综合团队的实力以及需求的迫切度来确定，而这的直接产出物就是功能需求列表。

在进行下一步之前，我们还需要先完成业务流程图、功能逻辑流程图，完成了这些就可以使绘制的原型图更有逻辑性。

原型图（结构层和框架层）

原型图，其实就是产品经理把自己的抽象的想法转变为具象的输出物，是产品经理想法最直接的展示。而这一切都建立在完成上面所有工作的基础上。现在我自己对这一块的做法，是把原型、交互直接结合在原型图上，最后生成一个高保真原型图让设计开发人员去体验，在必要的页面会在旁边添加上注释，这样的好处是能让设计开发人员能最直观的去理解整个流程。

其实从现在来看，这个高保真demo的形式有一个不足的地方，就是开发人员很难对项目中的页面跳转有一个全局观。这样会导致开发对任务逻辑上需要花时间成本去研究。后来我观摩了各种原型图展示形式之后，发现页面线框图能够很好的解决这个问题。不过觉悟的时候，项目已经开发到尾声了，还是在下个项目时再把线框图加上。

PRD

对于产品需求文档，网上有流传这一些使用word撰写的文档案例，篇篇都近两万字（我毕业论文的字数了）…这论文级的PRD实在不是我的风格，想必开发人员看下去也是很艰辛啊…

在这个项目中，PRD的作用没那么大，只是起到的记录的作用，因为开发人员基本上是围绕着原型图进行开发的，并且我在原型图上有做详细的备注，能很好的满足他们的需求。所以到后来，一些产品需求上的修改，再加上PRD的内容模块也不够完善，就干脆不更新了。

其实到后来会发现，由于人员流动与交接都需要用到PRD，如果PRD没有跟进更新的话，那么就要忙死产品经理了，想想都累。

所以自己就变相的运用产品思维，重新梳理了一下自己的PRD的结构，优化PRD在使用上的体验，使用Axure RP来撰写，可以满足PRD对向前团队的大部分需求。其结构如下图：

而自己之前也写了一篇关于使用Axure RP撰写PRD的文章-Axure Pro 8制作产品需求文档，大家有兴趣可以看看。

项目管理

其实我在做产品经理之前，是一个项目经理，所以这部分工作处理的还是比较好的。而这个项目中，针对以前的处理方式再做出了一些优化，效果还不错。

一个项目在真正的进入开发周期之前，需要项目经理（产品经理）对功能的优先级进行开发排期，然后制定一个详细开发时间表，并设置里程碑。当时是通过表格与甘特图结合的形式，以一周为一个里程碑，也就是每周一个周计划，每日早上组织站立晨会，基本内容是汇报前一天的工作完成度以及当前的任务安排。然后再由产品经理进行汇总，并督促进度。而最终的进度汇报也由我直接汇报给boss。

通过这种管理方式，能带来一种项目的把控感，每天的早会可以明确的把握进度方向，不至于进度落下。而最后项目也是如期上线，也给团队、给自己一个鼓励。

其实从现在来看，思路方式都是对的。不过如果项目规模再大一些，那么对产品经理的项目管理能力要求就很高的。当然，大的项目一般都会有项目经理进行管理。总的来说，项目管理的根本目的是通过各种手段确保产品能如期上线。

总结

在整个项目规划与跟进的过程中，当时少不了各种问题，不过通过大家的努力也都得已解决。如果都记录下来，想必不是一篇文章的篇幅能够解决的。作为一个产品的负责人，需求上要有同理心、市场调研分析上要有市场能力、产品上要有产品能力与逻辑思维能力、开发阶段要有项目管理能力与沟通能力，往后产品上线要有运营能力、数据分析能力…

其实做完项目下来，才知道自己哪里不足，然后对自己叨叨、总结。

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

题图来自PEXELS，基于CC0协议