跳到主要内容

RentHub 产品经验

方法论是别人的总结，经验是自己的财富。

这一章记录 RentHub 团队在产品开发中积累的真实经验——什么方法有效，踩过哪些坑，以及我们在具体场景下的产品判断逻辑。这是一个活文档，随着团队经验积累持续更新。

1. RentHub 是什么产品​

在讲具体经验之前，先说清楚 RentHub 的产品定位，因为所有产品决策都应该从这里出发。

RentHub（租汇）是轻资产服务平台，为 商户（出租方，lessor） 与 租户（承租方，lessee） 提供信息发布、交易撮合、支付结算、物流协调、争议调解等中介服务；业务聚焦 B2B / C2C 物品与工业设备租赁，当前阶段以 C2C校园租赁 为主。

客户端以微信小程序为主触点，并配套 Web 管理后台与官网。

我们存在的价值：

解决传统租赁中信任建立困难、信息不对称、流程繁琐等问题，提供一个安全、便捷、标准化的数字化租赁平台，让更多人能轻松地出租和租赁物品。

这句话决定了我们的产品方向：

  • 不是堆概念的「硬科技噱头」，是最实用的租赁履约与结算工具
  • 不是只服务少数高净值客户，是面向有真实在租、在借需求的普通用户与小商家

2. 我们的用户画像（真实的，不是猜的）​

2.1 商户侧核心用户​

  • 同时上架、管理若干件在租物品（个人闲置或小商家库存），以自运营为主
  • 年龄分布广，对智能手机基本操作熟悉，但不喜欢复杂界面
  • 核心诉求：结算及时、合同清晰、少扯皮
  • 不能接受的事：操作复杂、到账状态不清、需要反复对账
  • 最常说的话：「我只想知道这几笔订单谁还没付清」

2.2 租户侧核心用户​

  • 主力为微信生态内的个人与小团队用户
  • 核心诉求：流程透明、付款有凭证、沟通有记录
  • 不能接受的事：信息不对称、售后找不到人、操作费时
  • 最常说的话：「我这边已经付了，商户说没收到」（说明需要双向确认机制）

3. 产品经验：我们学到了什么​

3.1 经验一：先做宽度还是深度？先做深度​

早期我们犯过一个错误：急于覆盖更多功能，把精力分散在「上架发布」「合同管理」「付款结算」「售后与争议」每块都做一点。结果每块都不够好用，用户用了一次就不再用了。

后来的做法： 选最核心的一条路径（合同管理与付款结算），把这条路走透——确保每一步都顺畅，每一个状态都清晰，直到用户说「这块用着顺」，再扩展其他功能。

对团队的启示： 当资源有限时，宁可有一个功能做得很好，也不要有五个功能都差不多能用。用户会为“刚好够好”的功能付出时间，不会为“差不多能用”的功能推荐给朋友。

3.2 经验二：微信生态的限制 = 产品约束 = 产品决策​

RentHub 建立在微信小程序上，这意味着很多“标准 App”能做的事我们做不了，或者成本很高。

这不是坏事，而是让我们专注核心价值的约束。

几个我们遇到过的具体情况：

限制错误应对正确应对
微信支付有手续费和资金流规则尝试绕过规则帮用户理解流程，做好状态管理
小程序无法发送任意推送通知什么都不做用微信模板消息覆盖关键提醒场景
用户可能在弱网环境操作假设网络永远好加加载状态、超时处理、操作幂等性
小程序页面有层级限制（最多 10 层）无限嵌套页面重新设计导航结构，减少层级

启示： 了解平台限制是产品设计的前提。在 RentHub 开始一个新功能设计时，先问：微信小程序能支持这个吗？有什么限制？

3.3 经验三：用户的操作路径比你想象的更短​

我们发现了一个规律：用户在小程序上的注意力极短，操作意愿在 3 步之后急剧下降。

这对产品设计的意义：

  • 核心操作（付款、续约确认、查看合同）必须在 3 步内完成
  • 每增加一步，就要有充分的理由
  • 入口要明显，不要让用户猜

一个实际例子： 初版的付款流程有 6 步（进入小程序 → 我的租赁订单 → 选择合同 → 查看详情 → 发起付款 → 输入金额 → 确认支付）。我们把它优化到 4 步后，付款完成率明显提升。

3.4 经验四：状态反馈是最容易被忽视但最重要的体验​

用户最怕的不是操作失败，而是不知道操作是成功了还是失败了。

我们收到过很多这样的反馈：

  • “我点了好几次，不知道提交了没有”
  • “转账了但是不确定对方有没有收到”
  • “提交售后了但是没人回应，不知道有没有看到”

这些问题的根源是：缺乏清晰的状态反馈。

我们的改进方向：

  1. 每个关键操作（提交、付款、售后工单）都要有明确的成功/失败反馈
  2. 异步操作（如等待对方确认）要有“等待中”的状态，而不是空白
  3. 失败时要告诉用户原因和下一步怎么办，不只是“操作失败”

3.5 经验五：不要用功能解决信任问题​

早期我们尝试通过加功能来解决用户的信任顾虑（“会不会钱转出去没有记录？”）。结果是功能加了，信任问题依然存在。

后来我们意识到：信任来自一致性和透明度，不来自功能堆砌。

几个建立信任的具体方式：

  • 每笔交易都有不可删除的时间戳记录
  • 出租需要双方确认
  • 用户数据的使用方式在首次使用时说清楚
  • 出问题时有明确的处理渠道和响应承诺

3.6 经验六：小程序的“冷启动”是产品挑战​

微信小程序有个独特的挑战：用户不会主动打开它，除非有具体的理由。

这和独立 App 不同——App 可以有应用图标提醒存在感，小程序完全依赖场景触发。

我们的解法：

  • 付款提醒：结算节点前自动推送模板消息，带用户直接跳转到付款页
  • 合同到期提醒：到期前 X 天触发，带用户到续约确认页
  • 新消息通知：商户/租户有新操作时互相通知
  • 广告推送：在合适的时机推送相关广告内容

启示： 在小程序场景下，设计用户的重访触发点和主干功能本身一样重要。如果用户只在安装时用了一次，产品等于没做。

4. 产品原则：我们认可的工作方式​

在以上经验的基础上，以下是 RentHub 团队当前认可的产品工作原则：

4.1 原则一：先搞清楚问题，再讨论方案​

任何功能讨论，先对齐“我们在解决谁的什么问题”，然后再讨论怎么做。这一步不能省。

4.2 原则二：少做，做好​

宁可砍掉 3 个功能，把 1 个功能做到位。用户会记住“这件事这个 App 做得特别顺”，不会记住“这个 App 功能很多但都不好用”。

4.3 原则三：快速验证，持续迭代​

一个功能上线就是一个实验。上线前定好成功标准，上线后看数据和反馈，根据结果决定下一步。不要追求一次做完美。通过快速小规模的灰度测试，验证核心假设，迭代优化。

4.4 原则四：每个人都对产品负责​

产品问题不只是“产品的问题”。任何人发现用户体验有问题、发现功能方向有偏差，都应该提出来。这是团队文化，不是越权。

4.5 原则五：对用户诚实​

如果功能暂时做不好，宁可不做。不要用“先上一个凑合的版本”来敷衍用户。用户的容忍度有限，一次差体验可能让他们永久离开。

5. 持续改进：怎么把这些原则变成习惯​

知道原则容易，执行困难。以下是几个把产品思维嵌入日常工作的具体方式：

5.1 每周产品回顾（15 分钟）​

每周找一个时间，团队一起回答：

  • 这周有什么用户反馈值得注意？
  • 上周的功能数据怎么样？和预期相比如何？
  • 下周优先级是什么？为什么？

5.2 功能上线后 Review​

每个功能上线 2 周后，发起人主动分享：

  • 使用数据如何？
  • 有没有意外的用户行为？
  • 下一步迭代方向是什么？

这不是汇报，是学习。目的是让整个团队都能从每次发布中积累产品判断力。

本文档记录的是当前阶段的经验，随着 RentHub 产品演进，内容会持续更新。如果你有新的产品经验值得记录，欢迎提 PR 补充。