产品经理如何延伸产品形态离用户更近？

选择产品形态就是选择我们在哪里以以及如何呈现在用户面前并与用户产生联系。如果不是未成型的新项目，那么已经有了主要的产品形态，之后也会因为想要离用户更近，而有延伸新的产品形态的需求。本文就是探讨产品经理如何延伸产品形态离用户更近？

一、互联网产品有哪些产品形态？

过去以产品为中心，讲渠道；现在以用户为中心，谈入口。我以流量入口为划分标准，梳理了目前互联网产品的主要形态：

产品形态的划分

二、选择产品形态要考虑的因素？

1、商业模式/业务模式/产品架构/业务流程

这些都是策划一个新项目时，决定最初那个MVP长什么样子要考虑的。我们需要问自己一些问题：

（1）我们核心想解决什么问题？或者满足什么需求？

（2）我们的用户是谁？在哪里？

（3）TA们的需求场景是什么？

（4）我们如何创造价值？如何盈利？

2、项目阶段/开发成本/运营成本

项目阶段，是做决策的重要背景。项目或者产品处于什么阶段，决定了我们可以投入多少，可以预期的回报是多少。

启动期就是MVP尝试的阶段，也是冷启动的阶段。产品形态要尽量低开发、重运营，做到快速测试市场，同时又具备冷启动的能力，通过运营获得更广泛的市场反馈。

成长期就更侧重在加速成长，以寻找更多更有效的渠道和流量入口为目的，拓展产品形态；同时也是降低科技创新带来的主流渠道变更风险，防止自己被降维打击。

成熟期要沉淀出几个主流的产品形态和业务模式，重点打磨优化。

产品生命周期

3、运营/增长策略的实施空间

运营以拉新、留存、转化、促活（复购）、裂变为目的设计策略时，需要一个落地环境和流量承接池；而不同生态内的规则不同，订阅号做拉新和APP做拉新的策略思路就不尽相同。另外，不同产品形态的增粉门槛也不同，订阅号增粉的门槛是「关注」这个动作，APP则是「下载」这个动作，明显下载的门槛更高，但APP内的策略空间也更大。决策就是要依据这些相互制约的因素做一个权衡。

4、使用场景/产品形态的发展趋势

使用场景，是结合场景来思考，用户最有可能在什么场景下使用我们的产品。场景思维更有利于我们了解细分需求，比如同样是提供资讯服务，通勤时间里的开车场景和地铁场景就可以是不同的产品形态，地铁场景可以选择文字的形式，开车场景则用音频的形式更合适。36氪正是发现了这个细分需求，所以推出了36氪随身听的小程序，可以自动连续播放各种资讯文章的音频版。

关注产品形态的发展趋势，就是降低科技创新带来的主流渠道变更风险，防止自己被降维打击。这也是为什么微信推出小程序后，大量的小程序开发者涌入，大家都不想不知不觉的被干掉。其他生态也积极的采取措施，比如支付宝推出小程序、各应用商店推出不用下载的轻应用。

关注产品形态的发展趋势，还有一个目的就是防止流量的流失。当前寄生的平台失去主流地位，流量向其他平台倾斜时，产品也要及时的跟进。比如做电商，不会错过拼多多和直播；做内容，不会错过抖音和快手。这个逻辑就比较直接，精准流量去哪里，我就去哪里。

三、举例：一个工作场景的Web产品如何延伸产品形态

以上都是基于做过的项目，形成的粗浅的经验总结。那么接下来我就结合当前在做的项目，举例阐述我的策略思路。

我当前参与的项目是做一个面向EVENT行业从业者的服务平台，可以理解成细分领域里的百度文库。

1、商业模式/业务模式/产品架构/业务流程

（1）切入点是想解决活动行业从业者的产出内容的价值单一的问题

（2）我们的用户是活动策划岗位人员，目前互联网上没有面向这个行业或者岗位的论坛

（3）我们可以通过提供策划方案的上传和下载服务，让策划产出的内容在流通中双侧都创造了价值，上传者获得了收益和认可，下载者获得了经验和灵感。从而提升了整个策划从业者群体的收益，和策划水平。

（4）策划人员的工作时间通常在写PPT，或者在为写PPT搜集资料。那么策划人员有下载需求的时间通常在工作时间，而策划人员的上传时间通常在目前没有项目不忙的时候，想要增加收入，就会上传自己的方案。

这么分析下来，我们主要提供工作产出内容展售服务，内容就是活动策划方案PPT。由于用户需要完成PPT文件的上传和下载操作，而且更重要的是为工作场景服务，所以核心的产品形态，就初步定了电脑端的web端。

2、项目阶段/开发成本/运营成本

项目初期，开发团队就一个技术负责人，主要的开发工作都花在了web网站的搭建上。运营则重点放在向圈内从业者调研、邀请等冷启动的运营，同时策划了一个冷启动模型，形成了初期的产品形态（非MVP）。

冷启动模型

回头再来看这个冷启动模型，我们实际选择的产品形态，其实是WEB+WAP+订阅号+社群，可以优化的地方就是流量承接方式，事实上，当时公开课裂变来的用户全部落到社群里，但由于课程来的流量，不全是下载需求者，无法在群里直接完成转化，况且我们初期的社群运营能力也不足，承接的很多群都死掉了。如果不是把社群放到跟订阅号同等的承接地位，而是先落到订阅号（因为订阅号输出的干货内容受众更广），再把订阅号粉丝进行分层运营，漏斗到不同类别的社群里，可能效果会更好。

3、运营/增长策略的实施空间

我加入团队的时候，产品主要的业务流程基本跑通了，但就移动端的运营略显乏力，每一期课程带来的拉新数量逐渐降低，群越来越多，但死掉的群也不断增加，而且最终漏斗到web端的效率很低。

于是我们开始第一次增加产品选型——服务号。

服务号相比于订阅号，入口更浅，有消息推送功能，能够满足web产品在移动端推送消息提醒的重要缺憾。目前大多数web产品的提供移动端推送消息提醒有2种方式，一个是短信通知，一个就是服务号消息通知。由于微信生态内，授权登录的便捷性比手机号登录体验好很多，所以我个人还是更推荐服务号的。

4、使用场景/产品形态的发展趋势

面对移动化的趋势，我们这类PC工作场景的网站，延伸移动端也做不错的尝试。比如石墨文档、有道云笔记等，web+服务号+WAP，就几乎是标配。小程序出来之后，把高频的功能拎出来做小程序，也是不错的策略。

所以，有了这些前辈的经验，短期规划的话，可能会选择做多个服务号矩阵+小程序的方式，来延伸移动端。长期规划的话，依然还是会考虑App。

5、总结

目前已经验证的就是，我们选择服务号作为移动端的主要产品形态是非常成功的，不管是课程裂变的流程的精简，还是和用户直接的联系的加深，都有非常正向的作用。

在选择了产品形态之后，其实还有一步容易漏掉的，就是用户引导。服务号虽然在微信的入口比较浅，但不置顶的话依然会淹没在无数的消息里。所以引导用户置顶，就像工具类产品引导你提升效率是一样重要的动作。

最后，服务号的玩法其实非常丰富，我将在下次文章中总结一些经验给大家。