从用户、场景、频次、现状、影响和价值验证需求强度

一句话提醒

先确认问题真实存在、稳定发生、影响足够大且当前值得投入；一个真需求也可能只是中等强度，而非最高优先级。

为什么今天看它

• 需求是否成立不能只看有人提出；还要确认具体使用者、业务场景、发生频次、现有替代方式和不解决的影响。
• 真实需求不自动等于最高优先级；若有手工替代且主要改善效率，就需要与核心功能和其他投入比较。

留一个问题

谁在什么场景下遇到这个问题？它多频繁发生，当前如何处理，不解决会造成什么影响？做了之后的价值多大，是否值得当前投入？

参考思路

1. 1.明确目标使用者及其实际业务场景，不停留在抽象功能名词。
2. 2.核实问题发生频次，判断它是稳定问题还是偶发诉求。
3. 3.了解当前替代处理方式及其耗时、错误和遗漏成本。
4. 4.判断不解决的影响与解决后的实际价值，避免只凭“看起来高级”认定需求强。
5. 5.先给需求成立性和强度作判断，再单独与其他需求比较当前优先级。

03_知识库/问题/如何验证一个需求是否真的成立.md