跳到主要内容

产品主人思维

“你不只是在写代码，你在建造别人生活的一部分。”

1. 执行者 vs. 主人：两种心态的差异​

同样是开发一个“消息通知”功能，两种思维模式的反应截然不同：

执行者心态：

“产品说加推送通知，我就接入微信模板消息 API，测一下能发就行了。”

主人心态：

“用户为什么需要通知？是催收租赁款项？是合同到期提醒？不同场景通知的紧急程度不同，频率该怎么控制？用户能关闭通知吗？通知文案写得不对的话用户会不会觉得骚扰？”

主人心态不是要你越权去做产品经理的工作，而是在做技术决策时，把用户体验和业务价值纳入考量。

2. 为什么小团队尤其需要主人思维​

在 RentHub 这样的小团队里，每个人都同时是开发者、测试、用户研究员。没有专职 PM 把守每一个决策，也没有庞大的 QA 团队帮你兜底。

这意味着：

  • 你写的一行代码，可能直接影响几百个商户与租户的体验
  • 你觉得“这个需求说不清楚，先按字面意思实现”——产品就会出错
  • 你发现了用户痛点但觉得“这不是我的事”——机会就会流失

在小团队，主人思维是必要的生存技能，不是加分项。

3. 五个主人思维的具体实践​

3.1 质疑需求，而不是盲目执行​

接到需求时，先做一件事：问 “为什么”。

不是挑战同事的权威，而是帮助整个团队对齐。很多时候，需求背后的真实意图和字面表述有出入。

实际案例（RentHub 场景）：

需求：在租赁详情页加一个“联系商户”按钮。

表面理解：加个跳转微信的按钮。

追问后发现：用户反映租赁合同快到期了不知道是否续租，本质需求是续约意向确认，不只是联系渠道。

更好的方案：到期前 30 天自动提醒 + 续租意向一键提交，而不仅仅是一个按钮。

怎么问需求：

  • “这个功能解决了哪类用户的什么场景？”
  • “用户现在是怎么解决这个问题的？”（了解现有替代方案）
  • “如果我们不做这个，最坏的影响是什么？”（判断真实优先级）
  • “成功的标准是什么？怎么衡量这个功能是否有效？”

3.2 用全局视角看问题，不只盯着你的模块​

很多 bug 和体验问题出在模块边界——A 功能做得好，B 功能做得好，但 A 跳 B 的时候体验断了。

主人思维要求你在做一个功能时，不只看这个功能本身，还要看：

  • 上游：用户从哪里来？是首页入口、搜索结果、还是通知跳转？
  • 下游：用户完成这个功能后去哪里？下一步是什么？
  • 异常路径：如果失败了怎么办？用户会不会卡死？

实践方法：在开发前，手动走一遍完整的用户路径

打开小程序，以真实租户的身份操作一遍你要改的功能流程。注意：

  • 信息是否完整清晰
  • 操作是否顺畅，等待是否合理
  • 错误提示是否能帮助用户解决问题

3.3 对上线后的结果负责​

很多开发者的心态是“上线即完成”，PR 合并后就忘了这件事。

主人心态是：上线是开始，不是结束。

上线后你应该关注：

  • 新功能是否被用户使用？（点击率、使用率）
  • 是否产生了新的报错？（查看云函数日志）
  • 用户反馈是否有新的投诉？

具体做法：

  • 部署后 24 小时内主动检查相关云函数的错误日志
  • 在团队群里收集用户反馈，主动关注与你的功能相关的评论
  • 如果数据不如预期，提出假设并验证，而不是等别人来告诉你问题

3.4 为用户写代码，不为代码写代码​

有一个陷阱叫做“技术炫技”——用复杂的技术解决其实不复杂的问题，因为这让开发者自我感觉良好。

主人思维的技术选型标准：

  • 够用就好：用最简单、最稳定、最好维护的方案，而不是最新最酷的（要时刻有成本意识）
  • 显式胜于隐式：代码逻辑清晰，三个月后的你（或者队友）也能快速理解
  • 用户感知 > 代码优雅：如果用户感受不到差异，那次“重构”可能不值当前时机投入

一个判断技术决策的问题：

“这个决策对用户有什么好处？”

如果你说不清楚，这个决策就要重新考虑。

3.5 主动传递信息，不做信息孤岛​

主人不只是对代码负责，也对团队对齐负责。

你发现了一个潜在的问题、一个用户的反馈、或者一个技术风险——不要默默知道，要主动说出来。

几个值得主动沟通的场景：

  • 在实现过程中发现需求有漏洞 → 及时提出，而不是按字面实现
  • 发现某个功能上线后数据不好 → 主动说，提出假设
  • 遇到技术方案的 trade-off → 不要自己悄悄决定，拉相关人对齐

4. 从“受雇心态”到“创业心态”​

YC 投资人 Michael Seibel 说过一句话：

“The best engineers I know think like founders. They ask 'why are we building this' before 'how do we build this'.”

最好的工程师像创始人一样思考。他们在问“怎么做”之前先问“为什么做”。

你不需要是创始人才能有创业心态。你只需要把你负责的那一块当成自己的产品来对待——它的成败由你来关心，而不是等别人来告诉你结果。