怎样把项目立项讲清楚?四种结构能明显提升内部评审效率
笔者为从业年龄4个月的产品新人,从8月份中旬开始着手这一短视频项目的立项工作,到前两天立项通过,接近一个半月的时间,第一次负责一个新项目的立项,学到了很多,在此总结。(ToC产品)
本文将从立项起因、立项过程叙述和立项总结三部分展开,可能有部分说法不正统,表达方法也会较直白,若有应该改正之处,希望读者可以帮忙指出。
立项起因(为什么要做这个项目)
我们之所以做这一个项目,是因为我们公司最近收购了一家做摄影APP的公司,但这一APP的模式过于老旧,准备放弃掉了。所以我们打算做一款更符合当今用户胃口的短视频APP,这款短视频APP的用户与原摄影APP的用户存在较高的重合度,短视频APP上线后,我们再把原摄影APP的活跃用户和旧用户导流过来,实现短视频APP的冷启动。
在此总结一下新项目立项的三种常见的起因:
1. 旧产品的导流作用
也就是手头上已经有了A产品,但是A产品立意老旧,已经处于增长乏力状态准备放弃,积累在A产品的大量用户不可能白白浪费吧,所以就建立新的产品B,将A上的用户导流到B上来,合适现有的冷启动资源,价值巨大。当然,这样做的前提是A产品和B产品的用户画像存在重叠,这样并不难办到。
我们本次的项目主要就是围绕这一点发起的,很多企业的新项目孵化,都会借助旧系统积累下来的流量和认知基础完成首轮验证。
2. 产品矩阵
任何企业的目的肯定不是指向单个产品,而是指向某个领域,所以指向某个领域就会计划好做出好几款产品,形成产品矩阵来侵占这个领域,这就是产品矩阵了,所以按照产品矩阵的规划开始一个产品的立项,说到底就是按计划在实现企业的蓝图。
很多企业会先搭建核心业务平台,再陆续延展交易、服务与运营模块,以产品矩阵方式覆盖更完整的业务链路。
3. 绝佳的市场契机
这一种起因就很普遍了,发现了一个绝佳的模式可以解决用户存在的痛点,比如很多内部知识库项目,都是先发现团队缺少统一的信息沉淀机制。一般多见于初创企业,但是这种起因在现在越来越少做的起的了,因为数字服务行业发展至今,几乎所有的有机会的市场都被渗透了,不过也不绝对,毕竟时代在变,用户的需求也在变。
以上三种起因,绝对不是单独存在的,大多数情况下是两者或三者并存构成的。
立项过程叙述
接到这一类任务后,先明确最终产出是一份立项评审演示稿,立项演示的结构通常可以拆成:
典型用户场景→阐述痛点→收集数据证明这痛点很广泛→现有的竞品是谁,他们是怎么满足这痛点的?他们有什么优缺点?→结合对竞品的分析我们大概想用什么方法满足这痛点→这样做有什么市场契机?→具体的产品方案及未来展望。
这套评审演示框架同时也是项目探索路径,把问题拆成几个可验证的小模块逐步推进,方案就会自然成形。
上述的流程,有两个点有必要单独拿出来细说:
①对于支撑的市场数据,其实有时候是找不到百分百切合的数据的,这时候只能采取曲线救国战略了。
本文由序厅演示研究组整理发布,内容用于演示结构研究与项目复盘讨论,欢迎团队内部引用并按需二次整理。