在排期之前，先确认它是不是需求
业务方提过来的需求，四条里往往有两条不该进开发：能力早就有了没人知道，或者能力有但没人用得动。 这个工具不算优先级，它只做前面那一步判断。
分诊结果
四类是怎么分的
- A 不知道有
- 能力已存在，业务方不知道。这是信息触达问题，不是产品问题。
- B 不会用
- 能力存在、路径通畅，但业务方不知道怎么操作。学会了就能用。培训能解决的只有 A 和 B。
- C 不支持
- 真的缺能力。这才是需求，进排期。
- D 不好用
- 能力有，业务方也会用，但流程反人性、步骤过多、易出错。这是设计债，不是新功能。
B 和 D 的分界线：「教一遍就能用」是 B，「教了也还是难受」是 D。 这条线最容易糊，糊掉的后果是把设计债当培训问题反复讲课。
体检报告
单条分类只是分类。分布才是诊断。攒够十几条，你团队的病灶自己会浮出来。
记录只存在你这台设备的浏览器里（localStorage），不上传服务器。换设备或清缓存就没了，重要数据请导出。
台账
默认情况下记录只存在你这台设备的浏览器里。登录之后，记录改存服务器数据库，换设备也能接着用。
关于
为什么会有这个工具
平台型产品最常见的浪费，不是把需求做错了，是把不该做的需求做了。
接需求的人默认它是新需求，于是评估、排期、开发。但真实分布里，很大一部分是能力早就有了没人知道， 或者能力有但门槛太高没人用得动。这两类进了开发，是纯浪费；而它们真正需要的动作——把信息送到、把门槛降下来——一次也没发生。
市面上讲需求优先级的方法（RICE、KANO、ROI 打分）都假设「这是个真需求」这一步已经过了。 这个工具卡在更前面的位置。
它不做什么
- 不算优先级分数。分诊完了才轮到排优先级。
- 不替你做决定。它只把你脑子里那个凭经验的判断，变成一条别人也能走的路径。
- 不收集数据。没有账号，没有后端存储，记录只在你的浏览器里。
关于作者
B 端产品经理，做需求分析。做过通信行业的项目，现在深耕平台类产品。
这套四分类不是从书上抄的，是在处理平台需求时逼出来的：业务方嫌平台响应慢，平台嫌业务方需求乱， 双方都觉得对方有问题。真正拆开看，很多矛盾根本不在能力上，在信息和易用性上。分清这一点，双方的争吵才有落点。
本站不含任何公司内部数据。示例均为构造。