时间: 2021-07-30 11:51:17 人气: 9 评论: 0
10个人，10个月，100万，3款产品，我们在变幻莫测的租房领域做了一些探索，犯了很多错误，也学到一些经验，希望本文能对在路上的你有所助益。
首先，让我们用一句话来定义团队要解决的元需求—让租房变得更简单
听到“租房”两个字，大家脑海里最先联想到的产品是什么？58同城，链家自如。
毫无疑问，在互联网的早期阶段，以这两款产品为代表的租房平台确实让租房变得“简单”。
简单在哪里呢？
信息对接的效率提高后，房东和租客的匹配度也同步提高，因此在早期阶段，58同城确实解决了“效率”和“准度”这两个核心问题，从而让租房变得“简单”。
那么，为什么今天的租房不再“简单”了呢？
成本被推高了。
在过去的10年中，中介毫无疑问是主要推手之一。
中介做了什么？
总体来看，当前中介的体验并不是很好。站在中介的角度看来，出于自身发展需要，自然希望服务更多的用户，赚取更多的酬金。
但是在收取高昂服务费的同时，却没有提供与之相匹配的服务。
让我们看看租客面临的有限选择：
再看看房东的选择：
一线城市的租房市场可以说一直处于“卖方市场”，在当前的市场下，中介处于主导地位，租客和房东的选择都是有限的，而租客更是处于食物链的底层。
现在租房市场面临的状况，比早期阶段更加复杂：除了原先的“效率”和“准度”问题，还增加了“信息垄断”“租房成本高昂”等问题。
我们希望围绕这些问题，重新梳理“中介”“房东”“租户”三者之间的关系，下面是我们迄今为止在产品上所做的一些探索。
首先让我们简单的了解一些项目背景。
创始人: 国内某长租公寓运营总监，在长租公寓领域有一定的资源积累。
投入资金：约100w
试点城市：广州
接下来为大家展示我们团队在不同阶段给出的3个产品定位。
定位：“面向一线城市租户的找房导航网站”
通过调研，市面上除了58和自如之外，还存在着一批“小而美”的租房平台，根据长尾**，如果我们增加这些小平台的曝光率，可以在提高租客们找房效率的同时，完成产品初期的引流任务。
最理想的情况是：用户通过我们的网站在各个租房平台之间相互跳转，以实现找房的目的，同时导航可以为用户提供高质量的攻略内容，以此增加粘度。
每年的3月份是北上广的第一波租房潮，我们选择在这个时间点推出产品。但就结果而言，数据很差。
让我们用简化版的Kano模型找找问题所在：
在Kano模型中，用户期望值和产品体验的落差一目了然：
租户们普遍认为在导航网站里找房子“很费力”，因为房源的入口在导航里埋得特别深，再加上当时的页面逻辑也有问题，这就导致用户在网站里特别容易“迷路”；而且没有好的方式能让用户在各个平台间顺滑的“迁移”，用户离开其中一个平台的同时大概率**直接跳出导航网站。
用户不能收藏具体房源，只能收藏平台网址，导致产品粘度很低。
团队的本意是从“效率”出发去解决租户痛点，但是在现在看来，导航这种形式是“隔靴搔痒”式的解决方案，不但没有提高用户的找房效率，那些“小而美”的平台也没有获得更多的关注，用户的关注点仍然在那少数几个传统平台上。
用户找房的基本需求仍然是“房源”，埋头做产品的我们忽略了这一点；当用户们进来第一眼没有找到自己想要的东西时，沮丧和离去都是在情理之中的。
打个比方：
老王肚子饿想吃饭，进了一家新开的餐厅准备点餐。这时服务员拿来了一份地图，地图上标满了全城的餐馆位置。老王怒了：“饭呢？！”服务生的笑容天真无邪，又掏出一本字典那么厚的宣传册“我们还有其他所有餐馆的简介哦，先森了解一下~”老王愤而离席。
现在看来，“租房导航”是介于“基础需求”和“伪需求”之间的一款定位暧昧的产品；再加上界面不友好，内容质量低等问题，这款产品的失败是有迹可循的。
定位：“面向一线城市房东的信息发布工具”
毫无疑问，我们正处于一个“无社群，不言商”的时代。相对应的，诞生于微信的小程序生来就具备社交基因，笨重的“阉割式App”不应该是小程序的玩法，我们认为小程序应该高效率的解决房东的问题，而且体验必须轻量化，依靠“社群”在粘住用户的同来培养用户的使用习惯。
我们希望房东可以使用我们的工具高效率的解决“展示房源”和“租客重复询问”这两个痛点，让房东用小程序生成一张房源展示卡，这张质量足够高的信息卡可以二次传播，在社群和朋友圈里分享，以此来达到初期传播的目的。
我们希望在产品后期，可以通过这些积累下来的房源信息和房东数据来反向筛选优质房源，以此为切入点，逐步解决中介“信息垄断”的问题。
在推广一段时间后，用户调研反映出了很多问题，最严重的问题是房东们反映出租慢，最后还是靠58等租房平台来解决问题。我们发现，问题出在“社群”上，原因有三：
导致的结果是：大多数用户无法在我们的社群里解决问题。虽然也有一些积极反馈，很多房东反映产品体验不错，发布信息更加直观，而且也很方便易用。
小程序给出的体验是“产品+社群”，即使小程序本身作为信息发布工具体验很好，但用户真正解决问题的场景还是在社群里，社群无法提供房源的高曝光，用户自然觉得“出租慢”。
上线3个月后，项目被管理层叫停。
定位：“青年公寓折扣预约平台”
我们希望在提高长租公寓入住率的同时，降低用户的租房成本。
假设传统公寓的获客成本单价是700元，那么，如果我们能以400元的价格获客，再以500-600的价格将客源对接给公寓，我们的盈利空间有100-200；这部分利润可以用来补贴用户，等获得一定的用户量后，可以依靠流量和增值服务变现，这是初步的业务逻辑。
相对于普通租房，集中式长租公寓的优势在于丰富的共享设施和社交属性。而我们产品的信息结构和公寓的空间结构在逻辑上形成对应关系，力求用户去公寓实地看房之前，已经在认知中建立起了公寓的概念模型，我们希望把长租公寓的价值最大限度的展现给用户。
在产品运行了一段时间后，我们发现数据完全不符合预期。于是我们开始复**业务流程，最后根据运营同学反馈来的用户信息，我们确定问题出在了B端 （B端面向公寓方使用，主要功能是“确认预约”和“发布信息”）。公寓方经常绕开平台和用户私下签约，不进行预约确认，以节省成本。
当时的预约流程是：用户在青年家平台预约→将用户联系方式推送给B端→B端确认预约。
新的流程修改为：用户在青年家平台预约→通知B端预约信息，隐藏用户详细信息→B端确认预约→B端查看用户联系方式
修改流程后，数据回暖不少。
事实证明：只靠纯粹的商业道德，很难对商业上的合作伙伴进行实质上的约束。
这款产品的后续业务和模式还在探索中，我**将第一手的经验分享给小伙伴们，请持续关注我哦。
相信大家读过文章后产生了诸多疑问。
就结果而言，有些决策在当时的资源状况下并未得到最优解。篇幅所限，在本系列（创业产品反思录）接下来的文章中，我**以一个创业公司应届产品小白的视角来对这些问题一 一进行解读，希望对大家有所帮助。
如果你现在处在难得的假期中，仍然愿意花时间读完我的文章，欢迎随时来和我交流哦 (＝^ω^＝)
如果你对我们的产品特别感兴趣，也可以私信我，北京的同学欢迎面基(*/ω\*)
本文由 @ 大北 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
