项目冷启动，搭建MVP产品框架

原创： Kevin改变世界的点滴 Kevin改变世界的点滴 前天

大家好，我是 Kevin。这是我2019第37篇原创

因为项目原因，近期开从事新项目涉及，负责了冷启动项目从0到1以及制定MVP策略。在公司商业化战略下，除了有核心资源在项目没有开展之前就被带入外，大部分MVP产品考虑的是社群、公众号、H5、甚至是小程序去验证商业化的通道。

通过用户的反馈、以及抓住用户需求。利用数据有没有用户愿意停留在上面、传播数据如何等，决定是否要花精力再次投入。

今天介绍的案例是我在负责某个小程序项目背景下就产品MVP设计的思考。MVP是可以帮助企业、项目从0到1走的更远，减少失败的有效策略。

减少配置化

明白业务是什么

小程序项目是面向用户提供内容服务的产品。内容包含UGC与PGC，在产品期间1.0小程序推出后是给予用户提供明信片内容以及传送。比如下面产品不同的明信片包含了不同的音频和文案。通过音频与明信片，一种内容性聚合产品，刚上线团队也是希望能够验证业务模式。

通过直接查看不同tab“发布”、”首页“、“我的”背后页面与转化漏斗数据，给予反馈入口，让用户可以直接在反馈入口加入内容。如下面的体验小客服

尝试用户的反馈、用户的主路径功能、以及功能上线后是否有其他没有想到的玩法被用户揣摩。

产品经理在策划产品会分下面2端+1数据3个放心考虑。某一个C端前面模块需要后台进行支撑，这里的后台有可能没有功能性管理、但也有后台逻辑类似图片的刷新、页面的加载顺序等。

考虑MVP产品化，首先要注意能够不做配置花、管理化就尽可能不做，能复用表单的就选择复用。

类似下面的后台模版素材，复用功能可以通过导航栏进行间隔。上述明信片、甚至是功能性小程序，都可以采取先上线固定内容。

后期再进行对内容管理、功能管理。建立如下后台模块，通过一级导航、二级导航对业务进行隔离。这样也方便进行ROABC权限管理。如下图的一级导航列表

产品商业化前

多利用社群

这一点在PMTalk产品经理社区中我们商业化探索尤为明显。每一次产品功能的引入都是在社群中先利用运营跑起业务模式，如果有用户反馈不错或呼应甚至是转化特别高才会考虑进行产品化。

采取下方4步骤策略，在做产品前可以降低风险。

通过上面4个步骤，产品方案落地后其实是能够给予用户更好的体验并且提升产品存货性，因为业务的MVP模式已经在社群或运营上进行解决，传统的说法：线下解决。

这里我举个例子，便是社区的体验报告版块，我们是如何一步又不步打造的。

比如我们之前通过知识星球建立的社群：快速体验1款app。发起这个原因是我首先个人在工作中出现查找竞品的问题，我会去寻找类似的产品。其次就是在曾经产品新人时期，也会有兴趣通过拆解体验报告提升自己的产品经理专业能力。

记得曾经最早这部分内容是在产品社区上发现的这一趣味话题性内容：

后续我自己建立体验报告社群并要求产品人每天都体验1款app与产生这样的内容报告，根据产品人的特定拆解方式。发现产品从业者是有这个需求自发的产生、并且也有需求查看一篇又一篇的体验报告，一个社群50人坚持了30天产生了足足1500份app体验报告

我们抛开内容本质梳理整个业务流程，其实整套社群提供给予用户更快的内容产生、内容消费体验。在产品设计上走的路径为

当然因为开发资源的问题，本来1.0、2.0、3.0是可以并行的。但我们却采取将优先级最终的解决、再解决第二个。

即使我们知道都是必须要解决的问题，但仍然拒绝一口气吃个大胖子。因为有时候产品在线上后，你会发现用户产生的数据会给你其他产品设计方向。

产品场景化

移动端&PC

通过上面的步骤，我们基本把一个产品的最小化定下来了。接下来就是要确定在哪个平台进行“生长”

移动端有天然的社交优势、拉新是非常快的。但PC端就内容产品，生命力会更强。用户可以得到全面的内容创作场景。

不管是选择移动端、还是PC，最终产品化提供的业务是一样的导致功能也是非常相识。只是在MVP阶段你有什么样的资源决定了你可以选择开始那个。

在现在移动端的开源框架相比PC会少一些。杜绝在MVP版本下是闭门造成，而是一边开发一边探索业务模式。流程会如下

开源的好处就是可以最快的面向用户，用户如果不买单马上更换开源项目也是可以的。比如在PC上开源的Wordpress与wecenter

回过头来，你会发现很多想“闷声发大财”的产品或企业，都不如先开始做MVP不断修正自己的主业务更容易爆款。

好啦， 今天的原创就在这里。每天1篇我的产品案例在这里......

转载于:https://juejin.im/post/5ca179316fb9a05e2726a44f