Kogan买家总问“能不能加这个功能”，下一款产品到底该不该改？

平台观察

2026-11-09

262

买家提出功能，是线索，不是投票。

新品还没开模，客服表里先多出了一列“能不能加……”。

Kogan新品功能需求与开发优先级判断（原创专题配图）

Kogan新品功能需求与开发优先级判断

这列看起来很诱人。现款正常卖，买家又主动告诉你下一款想要什么，好像市场已经替研发写完了需求文档。中国卖家最容易在这里走偏：问得多，就以为需求强；工厂说能做，就以为应该做；再算一遍成本，发现好像也没有贵多少，于是新品方向就这么定了。

问题是，买家提出功能，是线索，不是投票。

真正值得进入下一轮开发验证的，也不是“被问得最多”的功能，而是某个明确的用户任务已经被反复证明存在，而且现有方案确实解决不了，替代办法又不好用，开发之后还不会把现款最值钱的优势一起赔进去。

这件事放到Kogan上尤其值得认真拆。当前Kogan商品页会把功能、规格、包装内含、保修与退货等信息分开呈现，部分第三方商品页还会用Q&A解释兼容性、使用方法等问题。卖家看到“能不能加某功能”的咨询，第一反应不应该是转给采购，而应该是重新看一遍商品页：买家是在要一个不存在的能力，还是没有找到一个本来就存在的能力？

先别急着改设计，第一步是把“功能需求”分成三类

假设你现在有一款卖得正常的桌面电子产品。

有人问：“能不能一键切换两个设备？”

有人问：“为什么我的电脑接上去没有画面？”

还有人问：“包装里为什么没有我以为会附送的转接配件？”

这三句话听起来都像产品问题，实际上完全不是一回事。

第一类是缺陷或者已经承诺的功能。如果商品页已经写明支持某种连接、某种模式或者某个配件本来就在包装清单里，那么实际做不到，优先级就不该进入“下一款新品愿望清单”。它是现款需要处理的问题。继续卖着一个没有兑现商品描述的产品，再等下一代改掉，经营逻辑是反的。

第二类是不会用、兼容性误解或者信息没有讲清楚。例如产品本来支持某种连接方式，但只适用于特定接口；或者支架本来可以完成某种角度调整，只是说明书和商品页没有把动作讲明白。这里增加一个按钮、一块电路或者一套模具，很可能只是把“信息问题”变成了“成本问题”。

第三类才是真正的新增能力：现款无论怎么设置都做不到，买家必须改变自己的使用方式，或者额外购买配件、增加步骤，才能勉强完成任务。

只有第三类，才值得进入下一轮产品开发候选池。

这个分类很重要，因为Kogan当前商品页本身就会把产品的功能与规格写得相当具体。对于一款现有商品，卖家不能一看到咨询就默认“客户发现了一个新品机会”。先把页面、说明书、包装清单和当前售后记录对一遍，很多所谓的“新功能需求”会自己消失。

还有一类事情更不能混进去：现款的安全、质量和履约问题。

如果是关键配件缺失、实际规格与页面描述不符、错误的兼容性承诺、运输中容易损坏、安装说明导致明显误用，或者已经出现应该及时处理的安全风险，这些都不是未来产品经理的愿望。它们属于当前经营必须解决的问题。

如果你做的是Kogan Marketplace，官方当前规则明确把Marketplace卖家的商品、商品页面内容以及相应退换和补救责任放在卖家一侧。把现款问题写进“下一代再解决”，既没有解决买家眼下的问题，也没有让新品研发变得更有价值。

真正的新需求，要问的不是“你想要什么功能”，而是“你什么时候卡住了”

“能不能增加一键切换”这句话其实信息量很低。

真正有用的问题是：你是在什么时候需要切换？

假设这个匿名场景里，买家每天在家用笔记本办公，晚上又接另一台设备娱乐。每次切换都要拔线、重新插线、重新调整显示设置。这和另一个买家偶尔出差，半年才遇到一次类似问题，显然不是同等强度的需求。

所以记录反馈时，最好把一句“希望增加XX功能”，改写成一个完整任务：

> 在什么使用时点，用户想完成什么事情；现有产品卡在哪里；现在用什么办法绕过去；这个绕法到底带来了什么损失。

最后那个“损失”特别容易被忽略。

有的替代办法只是多一步操作，用户完全可以接受；有的替代办法需要多买配件；有的替代办法会牺牲产品原本的便携性；还有的替代办法虽然麻烦，但只发生在非常少的场景。

没有替代办法，不一定意味着必须开发。替代办法足够便宜，反而可能意味着不用开发。

同样，别急着问“你愿不愿意为这个功能多付钱”。如果手里的证据只有咨询记录，就把价格接受度记成未知。买家说“如果有这个我肯定买”，和真正完成付款，是两件不同的事情。没有实际价格测试、订单数据或其他可比证据，就不要自己补一个“愿付价”。

十条咨询，不一定是十票；同一批人反复问，也可能只是一个问题

功能需求最容易在客服表里被放大。

同一个买家连续问三次，应该先按一个独立需求处理，而不是三票。一次促销活动中，很多人因为同一张没有讲清楚的商品图产生相同疑问，也不能简单地把消息数量当成市场投票。

反过来，如果不同买家在完全不同的使用情境下，都遇到了同一个未完成任务，这个信号才开始有分量。

因此，统计时最好把“消息”换成“独立买家＋独立使用场景”。同一个场景被不同人遇到，可以增加独立证据；同一个人换一种说法继续追问，不应该无限增加权重。

如果你只有咨询数据，没有足够的订单或访客数据，就不要硬算“全体买家有多少人需要这个功能”。用全部咨询者做分母，只能说明这个问题在咨询结构里占多大比例，不能直接推出全体购买者的需求率。

这也是为什么“买家总问”这个判断本身不够严谨。

咨询者永远不能自动代表全部买家。

尤其是某些功能很容易吸引主动提问的人，而沉默的大多数可能根本不在乎。

把少数候选功能放到同一张成本账上，结果通常会很不一样

先把这组算式的口径锁死。下面A、B、C都假设为下一款独立的新功能SKU，不替换现款；计算只看这个新SKU因为新增功能带来的独立新增订单，不把原本现款已经会成交的基础销量算进来，也不假设基础订单会从现款迁移到新款。同时假设新增功能不会把额外的客服、退货、配送或其他成本外溢给现款。这样，28澳元代表现款在扣除原本已经存在的随订单变化成本后留下的基准单笔贡献，单位新增成本只针对新增功能SKU订单发生。

因此，A/B/C统一使用：

新增订单 ×（28－单位新增成本）－固定开发费

这里的“新增订单”不是全部订单，而是能够归因于新功能、且在没有这个新功能时原本不会成交的订单。这个口径回答的是“这项功能能不能靠自己的新增订单覆盖开发投入”，不能直接外推到整款替换、现款下架、基础订单迁移，或者新增功能导致原款也增加成本的情况。

假设现款每完成一单，在扣除当前已经存在的、随订单变化的成本后，可以留下28澳元的单笔贡献。候选A，是让更多设备实现“一根线完成连接”。假设需要一次性开发成本2000澳元，每台新增成本4澳元，保守估计能带来70个独立新增订单。

那么：

70 ×（28－4）－2000＝－320澳元。

A的盈亏平衡新增订单数约为 2000 ÷ 24＝83.33，必须向上取整到84个新增订单。也就是说，在这个独立新增SKU的假设下，至少需要84个可归因新增订单，才刚刚覆盖这笔假设中的开发投入。

候选B，是增加独立电池，让设备可以脱离固定电源使用。假设一次性开发成本4000澳元，每台新增成本1.5澳元，保守估计带来50个独立新增订单。

50 ×（28－1.5）－4000＝－2675澳元。

它的盈亏平衡新增订单数约为 4000 ÷ 26.5＝150.94，向上取整为151个新增订单。

候选C，是增加一种更方便的摆放结构，让设备能够在另一个明确场景下使用。假设一次性开发成本500澳元，每台新增成本0.5澳元，保守估计带来30个独立新增订单：

30 ×（28－0.5）－500＝325澳元。

它的盈亏平衡新增订单数约为 500 ÷ 27.5＝18.18，向上取整为19个新增订单。

所以，在这组仅计算独立新增订单、没有原款订单迁移或成本外溢的假设下，C最值得先拿去做下一轮验证，A暂时保留，B先暂停。这里的84、151、19也只适用于这一口径。

如果后续商业方案改成整款替换现款，这组数字就不能直接沿用。此时必须把基础销量也放回同一套增量模型：凡是原本会买现款、后来迁移到新款的订单，都不能再当作“独立新增订单”；在其他条件不变、只有功能增加成本的简单情形下，这部分基础订单也要按28澳元基准扣除对应的单位新增成本。若替换同时改变售价、原有单位成本、退货、配送、客服或销量，还要把这些变化一并计入。A/B/C的单位贡献、最终排序以及84、151、19这三个盈亏平衡阈值都必须重新计算，不能把独立新增SKU的结果套到整款替换上。

这组数字也只是演示计算方法，不代表Kogan实际销量、供应商报价或买家愿付价格。真正进入决策时，新增订单数、固定开发费和单位新增成本都应该换成已经拿到的证据；证据不足，就把对应变量留为未知，而不是为了得到一个漂亮的排序硬填数字。

别把现有成本重复算成新增，也别把真正新增的成本藏起来

在上面的独立新增SKU口径下，共同成本和新增成本要分开。现有模具如果完全不受影响，就是共同成本，不需要因为新增功能再算一遍；如果为了新结构必须开新模具，就是新增固定成本。现有包装继续使用，也不是新增；如果重量或尺寸变化导致包装升级、尾程费用变化，就是新增。现有客服本来就在处理正常订单，也不应该把整个月工资算到新品头上；但如果新功能让兼容性问题增加，客服每单多出一轮排查，那部分新增工时就应该进入模型。

同样要把新增质量检查、说明书改版、包装调整、软件维护、退货检测、配件管理等放进去。关键不是把所有公司成本都塞进新品，而是确认哪些成本是因为这个功能才发生的。反过来，也不能因为工厂、仓库和客服原本就存在，就把真正增加的那一小段成本全部忽略。

如果以后从“独立新增SKU”变成“整款替换”，成本边界也要随之改变：原款会迁移到新款的基础订单，应与真正新增订单分开看；新增功能带来的单位成本、履约变化和售后变化，要落到所有受影响订单上。只有这样，算出来的才是产品路线改变之后的真实增量，而不是只对最漂亮的那部分新增销量算账。

有些功能看起来很香，真正危险的是它会破坏现款的卖点

假设现款最重要的优势是轻、便携、价格低。

这时候，一个“增加更多接口”的功能看起来很容易理解。可如果为了实现它，需要增加一个更大的电源模块、更厚的外壳和更多配件，最后产品从可以随手放进背包，变成必须单独占一个收纳空间，原本的卖点已经被自己削弱了。

又或者，一个智能功能可以解决少部分人的操作麻烦，但它需要App、固件升级和更多兼容性说明。原来买家拿到产品就能用，现在却多了一层“手机是什么系统、版本是否支持、为什么连不上”的客服问题。

这时候不能只比较“功能有多酷”。

应该比较的是：

完成一个新增任务，究竟换来了多少真实价值，又把多少已有价值交了出去。

这也是为什么有时候一个非常小的结构改善，比一个听起来高级很多的智能功能更值得开发。

供方说“能做”，只是开发决策的一半

供应商报价很重要，但它回答的是“怎么做、多少钱做”，不是“为什么值得做”。

尤其是新品还没有形成的时候，最容易出现一种错觉：供应商拿出了结构图，研发也给了报价，于是整个项目突然变得非常真实。实际上，真实的只是工程方案，需求本身仍然可能是假设。

更稳妥的顺序是先把用户任务说清楚，再做最小原型。

结构类功能可以先验证动作和使用路径，外观还没必要一步做到量产状态；交互类功能可以先验证操作逻辑；兼容性功能可以先把真实设备组合跑通。原型验证的目标不是证明“这东西能造出来”，而是看用户是不是愿意用它完成那个任务，以及它有没有制造新的麻烦。

验证时真正值得记录的也不是一句“喜欢”。

例如，用户是否完成了目标任务、是否需要额外步骤、是否产生新的误操作、原来的优势有没有被破坏、是否出现新的客服问题、不同使用场景下结果是否一致。价格接受度只有在实际做过价格测试时才有意义，没有证据就留空。

做到这一步，再回头让供应商报价，数字才开始有决策价值。

Kogan上的买家沟通，先按公开入口做证据，不要自己脑补一套规则

如果需求来自Kogan平台，反馈怎么收也要注意边界。

目前Kogan公开的客户规则可以确认，Marketplace买家可以通过账户订单相关入口联系卖家；退货流程也明确提供了Marketplace的“Contact Seller”路径。与此同时，当前部分第三方商品页还能看到“Ask a question”一类的商品沟通方式。

但这里有一个容易被忽略的细节：公开页面的入口名称并不完全一致，Customer Charter使用的是“Contact Support”，Guarantee页面使用的是“Contact Seller”。本次公开资料没有找到一份统一列明所有Kogan Marketplace卖家私下沟通限制、主动触达权限和所有账户沟通功能的澳洲版规则。

所以实际经营时，应该以当前卖家账户能使用的功能和对应卖家条款为准，不要因为某个商品页出现过一种沟通方式，就推导出所有卖家都拥有相同权限。

更重要的是，不要为了证明一个功能需求，就把沟通本身变成新的变量。你要验证的是用户任务，不是能不能把买家带到某个外部渠道。