用途
kero-research 用于在产品从零开始、还没有现成产品可重新设计的阶段进行调研，通常发生在划定功能范围或做技术选型之前。它的目标不是罗列资料，而是产出一个带有来源的诊断和一句话的产品论点。
主要原则与能力
事实优先
每一处主张都必须携带来源：一个链接、一个商店页面、一份公开文件，或任何别人可以打开的页面。如果一条信息无法在决策者面前一分钟内被查验，它就被视为观点，并被明确标注为观点。
先测量现状
在设想未来之前，先测量已经存在的东西：客户今天使用什么、成本是多少、谁在用、用得多不多。“没有这个应用”是一个发现；“这个应用很烂”在展示证据之前只是猜测。
数字必须带来源与日期
下载量、评分、价格、体量、收入都会快速过时。没有日期的数字无法与下一个数字比较。假设要写在它所影响的数字旁边，而不是被折叠进数字里。
读评论而不只读评分
竞争分析的重点是用户说了什么，而不是分数。评分说明有多少人不满意，评论说明为什么不满意。反复出现的抱怨就是产品缺口。此外要观察最好的竞争对手已经免费验证过的模式：在它们的规模上有效的东西是模式，它们的用户反复要求的东西是机会。还要区分谁付费与谁使用，因为很多产品失败是因为受益的人不是买单的人。
寻找改变话术的事实
有时现有工具的价格太低，任何价格比较都会失败，此时论点应当转向品类而非成本。要在对话之前找到这类事实。同时要记录哪些尝试已经失败以及原因：一个因缺少付费方或维护者而失败的前例，是资料夹里最有用的发现。
排除之前先调研
听起来被堵死的想法，往往只是被某个假设堵死。一次搜索通常就能消除疑虑，有时会带来项目最好的决定。如果确实存在真实限制，只陈述一次，并给出最接近的可行路径。
论点
研究以一句话收尾：为什么现有的东西失败，而这个产品替代解决了什么。好的论点会把问题从显而易见的功能上移开。例如，卡拉OK包间失败不是因为歌太少，而是因为没人愿意第一个唱。之后每一个功能都必须能追溯到这句话。
使用方式
最终输出是一份诊断文档，写在项目文件夹内的 docs/research.md 中；如果项目还不存在，则创建该文件夹。文档结构为：最上面是论点，随后是带来源与日期的发现、通过用户视角解读的竞争情况，以及那个改变对话的事实。调研在论点成立、新来源只是重复已知信息时停止。报告中要说明读了多少来源以及类型（商店、评论、公开文件、供应商页面），仅由供应商页面构建的诊断会被标注为观点。
适用场景与限制
适用于从零开始的产品研究、功能范围划定前的诊断、竞争与用户反馈分析。限制条件是：具体工具链、命令、平台支持、收费方式与价格在本资料中暂未提供；其中的输出路径与命名仅为该方法约定的产物形式，未提供实现细节。