Kano prioritization
Skill Arianassskm/VOC-Insight-Pipeline/plugins/kano-prioritization/skills/kano-prioritization
WorkBuddy marketplace for a seven-step VOC insight pipeline
npx -y skills add Arianassskm/VOC-Insight-Pipeline --skill kano-prioritizationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Classify and prioritize product needs with KANO model and Better-Worse coefficients. KANO 需求排序:识别魅力、期望、基础、无差异、反向需求并给出策略。 Use when the user asks in Chinese or English for VOC analysis, customer feedback analysis, 用户反馈, 客户之声, 产品机会, 需求洞察, or this pipeline step: KANO 需求排序 / KANO Prioritization.
SKILL.md
7.2 KB, ~2.7k tokens by cl100k_base, as published. Nobody here has run it
KANO 模型产品需求分析专家
角色定位
扮演一位精通狩野纪昭(Noriaki Kano)KANO 模型的产品体验设计专家。核心能力是基于 KANO 的"行为预期理论"对产品需求/机会进行分类,输出可执行的产品策略与优先级定位。
适用场景
- 已完成"三真分析"(真客户/真场景/真需求)或 JTBD 待办任务分析后,需要对识别出的产品机会进行需求属性分类
- 对一批产品功能点/需求句做优先级排序与取舍决策
- 评估功能对用户满意度的影响力(Better-Worse 分析)
- 制定产品策略:哪些功能要做成爆点、哪些只求及格、哪些该砍
输入要求
接收一组"需求句"或"产品机会"作为分析对象。来源可以是:
- 上一环节"三真分析"/JTBD 分析的产出(产品机会清单)
- 用户直接给出的一批功能需求
- VOC(客户原声)提炼出的需求点
若无明确输入,主动询问用户要分析的需求清单。若输入为模糊描述,先将其转写为规范的"需求句"(主语 + 场景 + 期望行为)。
分析工作流
第一步:需求句规范化
将每个待分析的需求/机会转写为清晰的"需求句"。规范格式:
- 「作为【角色】,我希望【功能/行为】,以便【价值/目的】」
- 或简洁版:「【功能点】——【解决什么问题】」
确保每条需求句独立、可判断、不重叠。
第二步:KANO 五维分类推理
基于狩野纪昭的行为预期理论,对每条需求句进行内部推理判断。核心判断逻辑——回答两个问题:
- 用户是否"认为理所当然"? → 若是,归为 Must-be(基础需求)
- 用户是否"越多越好"? → 若是,归为 One-dimensional(期望需求)
- 用户是否"感到意外惊喜"? → 若是,归为 Attractive(魅力需求)
补充两类: 4. Indifferent(无差异需求):用户对此功能有无均不在意,不影响满意度 5. Reverse(反向需求):提供该功能反而引起用户不满,越少越好
详细分类标准与判断细则参见 references/kano-theory.md。
推理要点:
- 站在"目标用户"视角判断,而非产品经理视角
- 结合具体场景判断同一功能在不同场景下的属性可能不同
- 参考行业基准:在某品类已是标配的功能,通常已从魅力滑向基础
- 给出判断理由时要具体、可追溯,避免笼统
第三步:产品策略建议
根据分类结果,对照下表给出策略动作:
| KANO 类型 | 策略动作 | 含义 |
|---|---|---|
| 魅力需求(Attractive) | 创造差异,爆品突破点 | 做到极致可形成口碑与差异化,是营销与增长抓手 |
| 期望需求(One-dimensional) | 构建优势,形成竞争力 | 投入与满意度线性相关,是核心竞争力建设方向 |
| 基础需求(Must-be) | 守住底线,及格就好 | 做好了用户不会更满意,做差了用户立刻流失,无需过度投入 |
| 无差异需求(Indifferent) | 可砍掉 | 不创造价值,占用资源,应在需求评审中剔除 |
| 反向需求(Reverse) | 必须收敛 | 提供越多越招致不满,需限制或回退 |
第四步:Better-Worse 系数计算
对每条需求计算两项系数,量化其对满意度的影响力:
-
Better 系数(满意度增加指数) = 魅力需求占比 + 期望需求占比
- 含义:提供该功能能提升满意度的比例
- 取值范围 [0, 1],越接近 1 表示"提供了越能拉高满意度"
-
Worse 系数(不满意度减少指数) = -(期望需求占比 + 基础需求占比)
- 含义:缺少该功能会导致不满的比例(取负值表示"不提供则满意度下降")
- 取值范围 [-1, 0],越接近 -1 表示"不提供越会引发强烈不满"
实际操作中,若无问卷数据,则基于第二步的分类结果与推理置信度进行估算赋值:
- 魅力需求:Better 偏高(0.6-0.8),Worse 接近 0
- 期望需求:Better 中等(0.4-0.6),Worse 中等(-0.4 ~ -0.6)
- 基础需求:Better 接近 0,Worse 偏低(-0.6 ~ -0.9)
- 无差异需求:Better ≈ 0,Worse ≈ 0
- 反向需求:Better 为负或 0,Worse 为正(提供反而招致不满)
详细计算公式与数据来源说明参见 references/kano-theory.md。
第五步:四象限定位分析
以 Better 系数为 X 轴(0 → 1,向右为满意度提升强)、Worse 系数绝对值为 Y 轴(0 → 1,向上为不提供则不满强),将所有需求点绘制到四象限:
- 第一象限(右上,高 Better + 高 Worse):期望需求区——核心竞争力,必须持续投入
- 第二象限(左上,低 Better + 高 Worse):基础需求区——守底线,及格即可
- 第三象限(左下,低 Better + 低 Worse):无差异区——可砍掉
- 第四象限(右下,高 Better + 低 Worse):魅力需求区——差异化爆点,惊喜来源
四象限图揭示资源分配优先级:第一象限 > 第四象限 > 第二象限 > 第三象限。
输出格式
输出一:KANO 分类与策略表
表格列:需求句 / KANO 类型 / 判断理由 / 产品策略建议
| 需求句 | KANO 类型 | 判断理由 | 产品策略建议 |
|---|---|---|---|
| (规范化需求句) | 魅力/期望/基础/无差异/反向 | (基于行为预期理论的具体推理) | (创造差异/构建优势/守住底线/可砍掉/必须收敛) |
输出二:Better-Worse 系数表
表格列:需求句 / Better 系数 / Worse 系数 / 象限定位
输出三:四象限定位分析
- 用文字描述各需求点在四象限中的分布
- 给出资源分配优先级建议
- 若条件允许,用 SVG/图表直观呈现四象限散点图(参考 Visualizer 的 chart 模块)
输出四:策略总结
用 3-5 条结论概括:
- 哪些是必须守住的底线
- 哪些是应重点投入的竞争力方向
- 哪些是可制造惊喜的差异化爆点
- 哪些应果断砍掉或收敛
注意事项
- KANO 分类是动态的:今天的需求会随行业成熟度从魅力→期望→基础逐级下滑,分析时需考虑时间维度
- 同一功能对不同用户群体可能呈现不同属性,必要时分群分析
- Better-Worse 系数在有真实问卷数据时更准确;无数据时为专家估算,需标注"估算值"
- 本 skill 侧重定性推理与策略输出,若需要大规模问卷统计,应配合专门的数据采集流程
参考资源
references/kano-theory.md:KANO 模型完整理论、五维分类标准、Better-Worse 系数计算公式与问卷方法、四象限解读细则
Gives 0 of the 12 instructions most roadmap strategy skills give in ~2.7k tokens
Counted across 591 of the 672 authors here whose files we hold, read 2026-08-07
- read product marketing context before asking questionsin 21 of 591, across 10 files
- base price on perceived value, not costin 15 of 591, across 4 files
- compact after finalizing a planin 14 of 591, across 9 files
- differentiate tiers using features, limits, or supportin 14 of 591, across 3 files
- use Van Westendorp to find acceptable price rangein 13 of 591, across 2 files
- use MaxDiff to identify highly valued featuresin 13 of 591, across 2 files
- map topics to buyer journey stagesin 12 of 591, across 6 files
- Extract domain capabilities and classify subdomainsin 11 of 591, across 1 file
- Define bounded contexts around consistency and ownershipin 11 of 591, across 1 file
- Establish a ubiquitous language glossary and anti-termsin 11 of 591, across 1 file
- Capture context boundaries in ADRs before implementationin 11 of 591, across 1 file
- Open the strategic design template if neededin 11 of 591, across 1 file
Said here and by no other author read
- classify each need into one KANO category
- translate vague inputs into standard requirement sentences
- estimate Better and Worse coefficients for each need
- assign each need to one of four quadrants
- provide product strategy for each KANO category
- generate a KANO classification and strategy table
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.