选择产品形态，就是选择我们在哪里以以及如何呈现在用户面前并与用户产生联系。如果不是未成型的新项目，那么已经有了主要的产品形态，之后也会因为想要离用户更近，而有延伸新的产品形态的需求。那么，要如何通过延伸产品形态离用户更近？
自从接手一个web产品之后，就一直在思考web产品如何离用户更近的问题。探索过程中，也获得一些经验来分享。
选择产品形态，就是选择我们在哪里以以及如何呈现在用户面前并与用户产生联系。如果不是未成型的新项目，那么已经有了主要的产品形态，之后也会因为想要离用户更近，而有延伸新的产品形态的需求。
过去以产品为中心，讲渠道；现在以用户为中心，谈入口。我以流量入口为划分标准，梳理了目前互联网产品的主要形态：
1. 商业模式/业务模式/产品架构/业务流程
这些都是策划一个新项目时，决定最初那个MVP长什么样子要考虑的。我们需要问自己一些问题：
（1）我们核心想解决什么问题？或者满足什么需求？
（2）我们的用户是谁？在哪里？
（3）TA们的需求场景是什么？
（4）我们如何创造价值？如何盈利？
2. 项目阶段/开发成本/运营成本
项目阶段，是做决策的重要背景。项目或者产品处于什么阶段，决定了我们可以投入多少，可以预期的回报是多少。
启动期就是MVP尝试的阶段，也是冷启动的阶段。产品形态要尽量低开发、重运营，做到快速测试市场，同时又具备冷启动的能力，通过运营获得更广泛的市场反馈。
成长期就更侧重在加速成长，以寻找更多更有效的渠道和流量入口为目的，拓展产品形态；同时也是降低科技创新带来的主流渠道变更风险，防止自己被降维打击。
图2:产品生命周期
3. 运营/增长策略的实施空间
运营以拉新、留存、转化、促活（复购）、裂变为目的设计策略时，需要一个落地环境和流量承接池；而不同生态内的规则不同，订阅号做拉新和APP做拉新的策略思路就不尽相同。
另外，不同产品形态的增粉门槛也不同，订阅号增粉的门槛是「关注」这个动作，APP则是「下载」这个动作，明显下载的门槛更高，但APP内的策略空间也更大。决策就是要依据这些相互制约的因素做一个权衡。
使用场景，是结合场景来思考，用户最有可能在什么场景下使用我们的产品。场景思维更有利于我们了解细分需求，比如同样是提供资讯服务，通勤时间里的开车场景和地铁场景就可以是不同的产品形态，地铁场景可以选择文字的形式，开车场景则用音频的形式更合适。
36氪正是发现了这个细分需求，所以推出了36氪随身听的小程序，可以自动连续播放各种资讯文章的音频版。
关注产品形态的发展趋势，就是降低科技创新带来的主流渠道变更风险，防止自己被降维打击。这也是为什么微信推出小程序后，大量的小程序开发者涌入，大家都不想不知不觉的被干掉。其他生态也积极的采取措施，比如支付宝推出小程序、各应用商店推出不用下载的轻应用。
关注产品形态的发展趋势，还有一个目的就是防止流量的流失。当前寄生的平台失去主流地位，流量向其他平台倾斜时，产品也要及时的跟进。比如做电商，不会错过拼多多和直播；做内容，不会错过抖音和快手。这个逻辑就比较直接，精准流量去哪里，我就去哪里。
以上都是基于做过的项目，形成的粗浅的经验总结。那么接下来我就结合当前在做的项目，举例阐述我的策略思路。
我当前参与的项目是做一个面向EVENT行业从业者的服务平台，可以理解成细分领域里的百度文库。
1. 商业模式/业务模式/产品架构/业务流程
（1）切入点是想解决活动行业从业者的产出内容的价值单一的问题。
（2）我们的用户是活动策划岗位人员，目前互联网上没有面向这个行业或者岗位的论坛。
（3）我们可以通过提供策划方案的上传和下载服务，让策划产出的内容在流通中双侧都创造了价值，上传者获得了收益和认可，下载者获得了经验和灵感。从而提升了整个策划从业者群体的收益，和策划水平。
（4）策划人员的工作时间通常在写PPT，或者在为写PPT搜集资料。那么策划人员有下载需求的时间通常在工作时间，而策划人员的上传时间通常在目前没有项目不忙的时候，想要增加收入，就会上传自己的方案。
这么分析下来，我们主要提供工作产出内容展售服务，内容就是活动策划方案PPT。由于用户需要完成PPT文件的上传和下载操作，而且更重要的是为工作场景服务，所以核心的产品形态，就初步定了电脑端的web端。
2. 项目阶段/开发成本/运营成本
项目初期，开发团队就一个技术负责人，主要的开发工作都花在了web网站的搭建上。运营则重点放在向圈内从业者调研、邀请等冷启动的运营，同时策划了一个冷启动模型，形成了初期的产品形态（非MVP）。
图3:冷启动模型
回头再来看这个冷启动模型，我们实际选择的产品形态，其实是WEB+WAP+订阅号+社群，可以优化的地方就是流量承接方式。事实上，当时公开课裂变来的用户全部落到社群里，但由于课程来的流量，不全是下载需求者，无法在群里直接完成转化，况且我们初期的社群运营能力也不足，承接的很多群都死掉了。
如果不是把社群放到跟订阅号同等的承接地位，而是先落到订阅号（因为订阅号输出的干货内容受众更广），再把订阅号粉丝进行分层运营，漏斗到不同类别的社群里，可能效果会更好。
3. 运营/增长策略的实施空间
我加入团队的时候，产品主要的业务流程基本跑通了，但就移动端的运营略显乏力，每一期课程带来的拉新数量逐渐降低，群越来越多，但死掉的群也不断增加，而且最终漏斗到web端的效率很低。
于是我们开始第一次增加产品选型——服务号。
服务号相比于订阅号，入口更浅，有消息推送功能，能够满足web产品在移动端推送消息提醒的重要缺憾。目前大多数web产品的提供移动端推送消息提醒有2种方式，一个是短信通知，一个就是服务号消息通知。由于微信生态内，授权登录的便捷性比手机号登录体验好很多，所以我个人还是更推荐服务号的。
面对移动化的趋势，我们这类PC工作场景的网站，延伸移动端也做不错的尝试。比如石墨文档、有道云笔记等，web+服务号+WAP，就几乎是标配。小程序出来之后，把高频的功能拎出来做小程序，也是不错的策略。
所以，有了这些前辈的经验，短期规划的话，可能会选择做多个服务号矩阵+小程序的方式，来延伸移动端。长期规划的话，依然还是会考虑App。
总结
至此，我们的产品形态就更新成了下图的样子。公开课、订阅号和社群都成了流量矩阵，主要的产品形态确定成了「web+服务号+WAP」。
目前的选型策略已经得到验证，加入服务号作为移动端的主要产品形态是非常成功的，不管是课程裂变的流程的精简，还是和用户直接的联系的加深，都有非常正向的作用。
在选择了产品形态之后，其实还有一步容易漏掉的，就是用户引导。服务号虽然在微信的入口比较浅，但不置顶的话依然会淹没在无数的消息里。所以引导用户置顶，就像工具类产品引导你提升效率是一样重要的动作。
最后，对于服务号的玩法，我将在下次文章中总结一些经验分享。
