「没有单点登录，我们没法把这个推广给整个团队用。」
⚙ SAML/SSO Fernwood & Co · $5,000/mo
关联到 1 个功能 · 1 个账户 · 计入下方的需求 · 示例数据
AIOInsights
值得拥有一席之地的 AI——有凭有据
无论在哪个页面，按 ⌘I 就能打开的产品助手。点一下就能看到它到底在做什么——每个答案都引用了你自己的数据。
一个扎根于你产品本身的助手
问一个产品相关的问题，得到一个引用了你自己数据记录的答案。
- 每个被引用的答案都会链接到它读取过的记录
- 读取的是同一条主线——反馈、使用情况、收入
简单问题，零 token 花费
- 收入、需求和进行中的工作直接从你的记录里算出来
- 不调用模型，没有幻觉，即时得到答案
投入、修复，还是弃用
- 每个功能都有一个基于使用情况给出的判定
- 需求按风险中的收入加权，而不是按原始投票数
会议自己把任务写出来
- 通话会自动转录
- 行动项会以草拟好的任务形式直接出现在你的看板上
示例数据 · 扎根于你的产品
一个信息流
全部信息，一个地方，不用来回切换标签。
功能请求、应用商店评价、调研问卷回答、研究笔记、设计评论、社区讨论、错误报告、支持聊天——只要接入一个来源，就会立刻汇入同一个信息流。
-
Canny · Productboard · Featurebase
-
Typeform · Dovetail · Notion
-
App Store · Google Play
-
Discord
-
支持聊天 · 手动记录
随手记录任何反馈。 在电话里听到的？几秒钟内把它加为一条 insight——同一个信息流，同样的关联，同样的打分方式。
聊天也会变成反馈。 来自支持聊天组件的对话会自动作为 insight 进入信息流——不会单独躲在一个收件箱里。
Webhook 向外发。 每一条被记录的 insight 都可以触发一个外发 webhook，让你技术栈里其余的部分对新信号做出反应。
每开启一个连接器，信息流就会随之填充。目前还没有邮件转发渠道——反馈通过连接器、聊天组件或手动记录进入。
彼此关联，而不是堆在一起
每一条 insight 都知道自己对应哪个功能——以及是哪位客户提出的。
一个无法据以行动的信息流，就是一个杂物抽屉。而这里，每条 insight 都关联着它所涉及的功能，以及提出它的账户——于是反馈自带收入，而收入会计入这页上的每一个排名。
- ✓把任意一条 insight 打上客户账户标签——他们的套餐和收入就会随之带出来。
- ✓把 insight 和功能关联起来，需求就会累积在做决策的地方。
- ✓同样的关联也会出现在客户的 360 页面上——反馈就摆在他们付了多少钱的旁边。
需求
按提出需求的人排序——以及他们付了多少钱。
「需求」视图会在每个功能旁边列出两个数字：有多少客户提出了这个请求，以及这些客户代表的收入。喊得最响的请求，和最有价值的请求，很少会是同一行。
-
请求数，已统计
每条被关联的 insight 都会让它指向的那个功能计数加一。再也不用翻回去重读一堆帖子来想起谁要的是什么了。
-
收入，已汇总
关联的账户会带来它们的订阅。一个功能的需求行读起来是具体的金额，而不只是票数。
-
投入回报比，按功能计算
需求除以投入——每一行都有一个清晰的回报数字，所以会议开始之前，取舍就已经一目了然。
按你的方式打分
五种框架。每个产品，你说了算。
当打分变得清晰明确，优先级排序就不再只是凭感觉。为每个产品选择它运行的框架——底层的需求和收入数据始终不变。
- RICE
Reach × Impact × Confidence ÷ Effort。Reach 默认取自按收入加权的需求，所以计算从真实的诉求开始。
- WSJF
Weighted Shortest Job First——用延迟成本除以工作量，适合按节拍持续交付的团队。
- Value-Effort
经典的 2×2 矩阵，用打分代替贴纸条。速赢项自然浮现。
- MoSCoW
Must / Should / Could / Won't——当讨论的是范围，而不是顺序时。
- Kano
基础属性、性能属性、魅力属性——评估一个功能落地后的实际反响，而不只是诉求的声量。
- 按产品设置
在产品设置里配置，就在你的方法论旁边。一个 B2B 产品可以用 WSJF，同时消费者应用用 Kano——都在同一个工作区里。
信息流里的 AI
AI 负责整理数据，并给出有理有据的判断。
两项真正落地的能力，都基于你自己的数据——不是花架子。一个负责让你的功能分类保持干净整洁；另一个会给每个功能一个你可以追问的建议。
三个名字，一个功能。已合并。
当你的事件流用不同的 key 揭示出其实是同一个功能时，AI 会建议一个统一的规范名称并把它们合并。现在需求和使用量都计入同一行，而不是分散在三行里。
export-csv · csv_export · exportCSV
↳ 建议合并
CSV 导出 ——一个功能，一段历史
来自你的产品事件 · 示例数据
每个功能都会得到一个判定——投入、修复、弃用，还是观察。
AI 会读取每个功能的使用情况、各种信号以及尚未完成的工作，然后给出一个带置信度评分的建议——依据的是数字，而不是谁最后发言。
SAML/SSO投入 · 86%
会话回放观察 · 71%
旧版导入工具弃用 · 74%
来自使用情况 + 信号 + 进行中的工作 · 示例数据
- 信息流会按连接器逐个填充——接入一个来源，它的历史数据就会同步进来；接入之前，不会假装数据已经在那儿了。
- 目前还没有邮件渠道。 反馈通过连接器、聊天组件和手动记录进入——把一封邮件转发进信息流这个功能还没有做。
- 支持聊天是由人工回复的。对话会自动作为 insight 进入信息流，但不会有机器人代替你回复客户。
常见问题
常见问题
我可以接入哪些反馈来源？
功能请求方面有 Canny、Productboard 和 Featurebase；调研和用户研究方面有 Typeform、Dovetail 和 Notion；还有 App Store 和 Google Play 的评价；Discord；再加上支持聊天和手动记录——全部汇入同一个信息流。
按收入加权的优先级排序是怎么运作的？
每一条反馈都会关联到它来自的账户，所以需求排序依据的是诉求背后的收入，而不只是票数。喊得最响的请求，和最有价值的请求，不再是同一件事。
支持哪些优先级排序框架？
RICE、WSJF、Value-Effort、MoSCoW 和 Kano，按产品选择。在 RICE 里，Reach 甚至默认取自按收入加权的需求，所以计算从真实的诉求开始。
反馈会关联回功能和账户吗？
会——每一条都会关联到它涉及的功能，以及它来自的账户，这样你就能把一个已交付的功能，追溯回提出这个请求的客户（以及背后的收入）。
这和一个独立的反馈工具有什么区别？
独立工具会把反馈孤立地存起来。而在这里，它和你的账户、收入、路线图处在同一条主线上，所以优先级排序依据的是真实的客户价值——彼此关联，而不只是拼在一起。