Se Connecter Maintenant 最近，我在做一个极简的还款记账工具，完全从零开始，踩了不少坑。之前写过一篇分析竞品的文章，说是竞品分析，其实更像给自己梳理商业可行性。用波特五力模型过了一遍市场，结论很直接：在线还款记账这个赛道，互联网大厂已经做得非常成熟，资源、技术、实力，都不是个人开发者能硬碰硬的。所以出路只有一条——做小，做精，去啃他们看不上的利基市场。
大厂的产品功能堆得又多又全，但很多人其实用不上那么多。我想做的，就是一款“小而美”的工具，只把最核心的还款记账做好，不贪多。做这个产品，过程价值远比结果大，整个从0到1的过程，能让我摸清产品各个阶段该做什么、该注意什么，以后再做别的，就能少走弯路。
上一篇文章已经把BRD和MRD要讲的东西理得差不多了。简单说，BRD就是回答“这事儿值不值得做”，给高层看商业价值、市场机会、盈利预期，文档通常很短，不太涉及产品细节。MRD则承上启下，把公司战略层面的意图，翻译成产品层面的方向和范围，相当于一个框架，告诉团队我们要做什么、不做什么。有些公司分工细，业务产品经理一句话需求丢过来，技术产品经理就得去写PRD，说的就是MRD指导PRD这个流程。
现在，重点落在了PRD上——产品怎么落地，怎么推向市场。PRD面向开发、设计、测试、运营，要把功能、流程、规则都讲清楚。它还不是最终执行层的文档，后面还能拆出需求说明书、设计说明书、测试说明书等等，但核心是把业务流程和功能描述透。
既然是极简产品，核心流程就得先理清。我用的是自上而下的设计方法：先定义总流程，再拆解子流程。所有设计都围绕还款记账这个核心场景展开，不铺大摊子。
功能设计上，登录注册、密码管理这些基础模块就不多说了，重点说说还款记账本身。一开始觉得简单，真做起来才发现细节非常多。比如，用户的视角是跟着月账单走的，自然就设计成按月展示的卡片视图——这个月要还多少，已还多少，还剩多少，一目了然。但新用户第一次进来可能会懵，不知道从哪里开始记账。于是我们在卡片上做了一个“改为记账”的入口，并在还款卡片上实时显示新增的还款项。每笔还款前面自动编号，剩余欠款大于0时，用醒目的颜色提示，让用户一眼就能关注到自己的还款状态。删除功能我们放得比较谨慎，没有直接暴露在卡片上，而是收到编辑的下一级操作里，避免误触。这些细节都是反复推敲出来的，虽然不起眼，但直接影响使用体验。
安全方面也不能马虎。每次修改还款金额，都需要同步更新当月总额，这个靠数据库触发器保证数据实时一致。在输入还款关联ID时，必须做ID认证和非法字符过滤，不然很容易被SQL注入攻击。后续如果涉及敏感数据传输，肯定要上数字证书和HTTPS，这是底线。
产品做出来后，我用KANO模型把功能筛了一遍，看看有没有遗漏高优先级的需求。KANO模型的思路很简单，就是分析功能对用户满意度的影响，区分出基本型、期望型、兴奋型需求。目前已经实现的几个核心功能，都属于基本型和期望型，解决的是用户还款记账的痛点。但光有这些还不够，接下来要考虑怎么做出“尖叫功能”——那些超出用户预期的兴奋点，能让用户觉得爽，甚至愿意自发传播。比如，能不能在还款提醒上做得更聪明？能不能根据用户还款习惯，自动生成一些省钱建议？这些都可能是痒点甚至爽点。但不管怎么加功能，有一条红线不能碰：不能把产品做重。极简的定位不能丢，每一个新功能都要问自己，它是不是真的必要，是不是让用户更轻松，而不是更复杂。
其实做这个小产品，最深的体会是，产品思维不是凭空想出来的，而是一点点磨出来的。从BRD到MRD再到PRD，每一层都在做取舍，最后落地到代码和设计上，还得不断调整。这个网站（miliao.xyz）现在只是个开始，后面还有很长的路要走，但至少，我知道该往哪个方向走了。
