创业产品反思录:从拆解元需求到产品定位
人人都是产品经理社区 发布于 2018-10-08 08:56:31 举报
阅读数:466

​​10个人,10个月,100万,3款产品,我们在变幻莫测的租房领域做了一些探索,犯了很多错误,也学到一些经验,希望本文能对在路上的你有所助益。

拆解元需求

首先,让我们用一句话来定义团队要解决的元需求---让租房变得更简单

听到“租房”两个字,大家脑海里最先联想到的产品是什么?58同城,链家自如。

毫无疑问,在互联网的早期阶段,以这两款产品为代表的租房平台确实让租房变得“简单”。

简单在哪里呢?

  • 房东告别了满街贴小广告的时代,在家里只需花一杯咖啡的时间,即可发布招租信息。
  • 租客的找房效率大幅度提高,只需在上班的地铁上滑滑手指,就可以筛选掉两位数的房源。

信息对接的效率提高后,房东和租客的匹配度也同步提高,因此在早期阶段,58同城确实解决了“效率”和“准度”这两个核心问题,从而让租房变得“简单”。

那么,为什么今天的租房不再“简单”了呢?

成本被推高了。

在过去的10年中,中介毫无疑问是主要推手之一。

中介做了什么?

  • 中介通过资本垄断了一线城市大部分的优质房源,这导致的直接结果是用户在任何一个租房平台上找房都翻不出中介的“五指山”。
  • 中介之间的恶性竞争。为了垄断和扩张,不断蚕食租客的权益,租金一涨再涨。
  • 中介日常在网络平台上发布大量房源信息,稀释房源信息质量,以达到垄断信息的目的。

总体来看,当前中介的体验并不是很好。站在中介的角度看来,出于自身发展需要,自然希望服务更多的用户,赚取更多的酬金。

但是在收取高昂服务费的同时,却没有提供与之相匹配的服务。

让我们看看租客面临的有限选择:

  • 支付高昂的服务费,节省时间,从中介处购买房源信息,承担中介跑路的风险。
  • 在租房平台上花费大量时间筛选房源,碰运气。

再看看房东的选择:

  • 在中介的电话攻势下缴械交房,坐收租金,但是要承担房屋被改造和中介跑路等风险。
  • 在租房平台上发布信息。大概率会淹没在中介的信息洪流中不见天日,从而蒙受损失。
  • 利用自己本地的人脉出租。

一线城市的租房市场可以说一直处于“卖方市场”,在当前的市场下,中介处于主导地位,租客和房东的选择都是有限的,而租客更是处于食物链的底层。

现在租房市场面临的状况,比早期阶段更加复杂:除了原先的“效率”和“准度”问题,还增加了“信息垄断”“租房成本高昂”等问题。

我们希望围绕这些问题,重新梳理“中介”“房东”“租户”三者之间的关系,下面是我们迄今为止在产品上所做的一些探索。

产品定位的三个阶段

首先让我们简单的了解一些项目背景。

创始人: 国内某长租公寓运营总监,在长租公寓领域有一定的资源积累。

投入资金:约100w

试点城市:广州

接下来为大家展示我们团队在不同阶段给出的3个产品定位。

第一阶段

时间:2017.12 - 2018.3

定位:“面向一线城市租户的找房导航网站”

通过调研,市面上除了58和自如之外,还存在着一批“小而美”的租房平台,根据长尾理论,如果我们增加这些小平台的曝光率,可以在提高租客们找房效率的同时,完成产品初期的引流任务。

最理想的情况是:用户通过我们的网站在各个租房平台之间相互跳转,以实现找房的目的,同时导航可以为用户提供高质量的攻略内容,以此增加粘度。

每年的3月份是北上广的第一波租房潮,我们选择在这个时间点推出产品。但就结果而言,数据很差。

让我们用简化版的Kano模型找找问题所在:

在Kano模型中,用户期望值和产品体验的落差一目了然:

租户们普遍认为在导航网站里找房子“很费力”,因为房源的入口在导航里埋得特别深,再加上当时的页面逻辑也有问题,这就导致用户在网站里特别容易“迷路”;而且没有好的方式能让用户在各个平台间顺滑的“迁移”,用户离开其中一个平台的同时大概率会直接跳出导航网站。

用户不能收藏具体房源,只能收藏平台网址,导致产品粘度很低。

团队的本意是从“效率”出发去解决租户痛点,但是在现在看来,导航这种形式是“隔靴搔痒”式的解决方案,不但没有提高用户的找房效率,那些“小而美”的平台也没有获得更多的关注,用户的关注点仍然在那少数几个传统平台上。

用户找房的基本需求仍然是“房源”,埋头做产品的我们忽略了这一点;当用户们进来第一眼没有找到自己想要的东西时,沮丧和离去都是在情理之中的。

打个比方:

老王肚子饿想吃饭,进了一家新开的餐厅准备点餐。这时服务员拿来了一份地图,地图上标满了全城的餐馆位置。老王怒了:“饭呢?!”服务生的笑容天真无邪,又掏出一本字典那么厚的宣传册“我们还有其他所有餐馆的简介哦,先森了解一下~”老王愤而离席。

现在看来,“租房导航”是介于“基础需求”和“伪需求”之间的一款定位暧昧的产品;再加上界面不友好,内容质量低等问题,这款产品的失败是有迹可循的。

第二阶段

时间:2018.3 - 2018.6

定位:“面向一线城市房东的信息发布工具”

毫无疑问,我们正处于一个“无社群,不言商”的时代。相对应的,诞生于微信的小程序生来就具备社交基因,笨重的“阉割式App”不应该是小程序的玩法,我们认为小程序应该高效率的解决房东的问题,而且体验必须轻量化,依靠“社群”在粘住用户的同来培养用户的使用习惯。

我们希望房东可以使用我们的工具高效率的解决“展示房源”和“租客重复询问”这两个痛点,让房东用小程序生成一张房源展示卡,这张质量足够高的信息卡可以二次传播,在社群和朋友圈里分享,以此来达到初期传播的目的。

我们希望在产品后期,可以通过这些积累下来的房源信息和房东数据来反向筛选优质房源,以此为切入点,逐步解决中介“信息垄断”的问题。

在推广一段时间后,用户调研反映出了很多问题,最严重的问题是房东们反映出租慢,最后还是靠58等租房平台来解决问题。我们发现,问题出在“社群”上,原因有三:

  1. 社群成员基数小,房源曝光度较低。
  2. 社群粘度低,无法持续为用户输出价值。租房是高成本的低频率事件,大部分用户解决问题后会直接跳出,再次产生需求的时间跨度很大。
  3. 社群纯靠运营人力引流,造血功能弱。

导致的结果是:大多数用户无法在我们的社群里解决问题。虽然也有一些积极反馈,很多房东反映产品体验不错,发布信息更加直观,而且也很方便易用。

小程序给出的体验是“产品+社群”,即使小程序本身作为信息发布工具体验很好,但用户真正解决问题的场景还是在社群里,社群无法提供房源的高曝光,用户自然觉得“出租慢”。

上线3个月后,项目被管理层叫停。

第三阶段

时间:2018.6 - 2018.10

定位:“青年公寓折扣预约平台”

我们希望在提高长租公寓入住率的同时,降低用户的租房成本。

假设传统公寓的获客成本单价是700元,那么,如果我们能以400元的价格获客,再以500-600的价格将客源对接给公寓,我们的盈利空间有100-200;这部分利润可以用来补贴用户,等获得一定的用户量后,可以依靠流量和增值服务变现,这是初步的业务逻辑。

相对于普通租房,集中式长租公寓的优势在于丰富的共享设施和社交属性。而我们产品的信息结构和公寓的空间结构在逻辑上形成对应关系,力求用户去公寓实地看房之前,已经在认知中建立起了公寓的概念模型,我们希望把长租公寓的价值最大限度的展现给用户。

在产品运行了一段时间后,我们发现数据完全不符合预期。于是我们开始复盘业务流程,最后根据运营同学反馈来的用户信息,我们确定问题出在了B端 (B端面向公寓方使用,主要功能是“确认预约”和“发布信息”)。公寓方经常绕开平台和用户私下签约,不进行预约确认,以节省成本。

当时的预约流程是:用户在青年家平台预约→将用户联系方式推送给B端→B端确认预约。新的流程修改为:用户在青年家平台预约→通知B端预约信息,隐藏用户详细信息→B端确认预约→B端查看用户联系方式

修改流程后,数据回暖不少。

事实证明:只靠纯粹的商业道德,很难对商业上的合作伙伴进行实质上的约束。

这款产品的后续业务和模式还在探索中,我会将第一手的经验分享给小伙伴们,请持续关注我哦。

结语

10个月,3个产品方向。

相信大家读过文章后产生了诸多疑问。

  1. 既然创始人具备“公寓”方面的基因,为何我们在第一阶段不直接做公寓方向的产品?
  2. 在第二阶段,如果接着对“社群”投入成本,是否可能触发社交裂变? 叫停的原因是什么?
  3. 产品的第三阶段,是否可能出现“公寓”“租户”“平台”三方共赢的局面?
  4. 频繁转变产品方向的依据是什么?

就结果而言,有些决策在当时的资源状况下并未得到最优解。篇幅所限,在本系列(创业产品反思录)接下来的文章中,我会以一个创业公司应届产品小白的视角来对这些问题一 一进行解读,希望对大家有所帮助。

如果你现在处在难得的假期中,仍然愿意花时间读完我的文章,欢迎随时来和我交流哦 (=^ω^=)

如果你对我们的产品特别感兴趣,也可以私信我,北京的同学欢迎面基(*/ω\*)

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

题图来自Unsplash,基于CC0协议​​​​

转载于:https://www.cnblogs.com/lianghong/p/9754027.html

【总结整理】租房产品创业的三个方向和三个产品---摘自《人人都是产品经理》...相关推荐

  1. 大话产品经理:真的 “人人都是产品经理” 吗?

    "产品经理", 一个重未被真正定义的争议角色. 他有时是模糊的, 有时却又清晰无比. 有时他是产品的缔造者, 但更多时候他却是开发和设计人员眼中的公敌. 很早以前就想抽时间来写一篇 ...

  2. 《人人都是产品经理》思考

    写在前面的话: 坚持的付出得到了想要的结果,成功入职一家互联网公司做数据分析师:工作半年,基本熟悉业务,日常只是取数跑脚本,很难创造更大的价值.想做出改变,记录行动.输出的模式还在摸索,2022要更加 ...

  3. 人人都是产品经理(创新版)

    产品的思维是方法,而产品创新是目的 创新难-低成本.简单 书中总结了一套低成本产品创新的方法论框架:5MVVP模型,具体流程为案头研究(Paperwork,真的有这个需求么).原型设计(Prototy ...

  4. 【总结整理】写给非技术产品经理的技术能力要求----摘自《人人都是产品经理》...

    写给非技术产品经理的技术能力要求 人人都是产品经理  订阅专栏 产品经理和运营人的学习社区 2018-10-23 2.4万 159 73 从零开始学运营,10年经验运营总监亲授,2天线下集训+1年在线 ...

  5. 三分钟读完《人人都是产品经理》

     欢迎关注公众号--<数据三分钟> 一线大厂的师兄师姐结合自己的工作实践,将数据知识浅显道来,每天三分钟,助你成为数据达人.还有面试指导和内推机会. 零.序 1.我们应该养成一个习惯,当看 ...

  6. 【总结整理】传统行业如何合理利用互联网思维----摘自《人人都是产品经理》...

    [天天问每周精选]第49期:传统行业如何合理利用互联网思维 人人都是产品经理社区 发布于 2018-10-08 08:03:46 举报 阅读数:1287 ​​近年来互联网思维一词火爆,无论是互联网行业 ...

  7. 人人都是产品经理总结 第三章2

    本文对应人人都是产品经理的3.5.3.6两节,其中3.5节重点讲了项目管理中的文档管理.流程管理和敏捷方法,3.6节重点讲了作者亲历的一些项目. 文档管理 1.pd的文档主要分为以下几类(详细的看p1 ...

  8. 【总结整理】面试pm常见的问题---摘自《人人都是产品经理》

    求职路上,"怼"来"怼"去的面试问题 人人都是产品经理社区 发布于 2018-10-29 19:53:06 举报 阅读数:1418 ​​在求职路上,面对那些被& ...

  9. 读书笔记《人人都是产品经理》

    <人人都是产品经理>3个月前看的书,最近第二遍看的时候,做了一个详细版的读书笔记. 相比较其他产品经理的书,这本书的特点如下: 1)这真的是一本写给-1岁产品经理的书,很初级,初级到花了相 ...

最新文章

  1. react 错误边界_React with GraphQL和错误边界中的自定义错误页面
  2. 为什么硬盘速度忽快忽慢_C盘装软件会拖慢电脑速度?C盘是不是比其他盘快?...
  3. AJAX解决中文乱码问题
  4. pythonunittest接口测试_基于python+unittest +requests接口测试
  5. iphone练习之手势识别(双击、捏、旋转、拖动、划动、长按)UITapGestureRecognizer...
  6. Django远端访问
  7. mysql常用快速查询修改操作
  8. 区块链相关问题 理解
  9. java 格式化字符串_Java入门 - 语言基础 - 14.String类
  10. 使用performance monitor 查看 每一个cpu core的cpu time
  11. Adtran加入SDN大潮,剑指运营商SDN转型
  12. html5 sessionStorage 与 localStorage存储
  13. 如何合并excel文件
  14. 去除xp系统计算机多余的系统,WinXP电脑如何清理垃圾?
  15. Coding life_云栖社区的个性化首页上线
  16. xp系统简单tcpip服务器,Win XP系统下添加打印机的方式手工添加TCP/IP端口
  17. 【渝粤教育】电大中专电子商务网站建设与维护 (5)作业 题库
  18. 2020年北京理工大学计算机学硕跨考上岸经验分享
  19. 支付宝退款工具类整理
  20. 使用git上传本地项目到码云

热门文章

  1. 智能电视盒子芯片哪个更强 七大芯片方案性能详解
  2. Eclipse插件-properties文件中中文显示ASCII码
  3. WebRTC的拥塞控制和带宽策略(转)
  4. wordpress添加icp备案号
  5. 嵌入式开发|阿里云物联网平台在线升级OTA
  6. 小白第一次用MacOS
  7. 信号与系统-1-δ函数尺度运算的证明
  8. Movie Graph Guide
  9. 在OCP集群内部署测试应用
  10. 2022年支付宝集五福|看这里100%扫敬业福