在我们的主要产品中，我们有一个已经存在了几年的功能请求，现在已经被请求了很多次。它在技术上很容易实现，问题是它将从根本上改变工具的概念，并且可能会导致更多的错误报告，因为人们误用新功能来匹配新概念（我们将无法解决）。我们有一个单独的功能可以很好地解决这个问题，但我们仍然收到实施新功能的请求。
我们应该吗
将其实现为插件。
如果此功能与您的产品理念背道而驰，则表明该产品不符合您用户的心理模型。其后果远不止一个缺失的功能。你需要深入用户的头脑，弄清楚如何根据他们的期望调整你的模型，或者引导他们对你的模型的期望。
对此进行足够的思考，它可能会成为您的绝佳机会。
在“神话人物月”（你已经读过，不是吗？）中，布鲁克斯说“建筑的概念完整性是最重要的”。这意味着，如果请求的功能破坏了产品整体设计的概念完整性，您可能应该继续避免实施它，无论请求多少。或者，您需要重塑架构，以使请求的功能适合修改后的架构。
我工作的其中一个产品添加了一个“非常需要的功能”。它的行为不同于产品中的任何其他功能。这是一个可怕的疣。但既然比赛做到了，我们就不得不这样做。但是，我们并没有保持我们的架构（恰好与该领域的竞争对手根本不同），而是模仿了竞争对手的功能，直到愚蠢的细节。
我仍然对这个功能被拙劣地植入系统中的事实感到愤愤不平，因为产品的其余部分语义被破坏了。为了在伤口上撒盐，我不得不向我们的客户群展示“自切片面包以来最棒的东西”的新功能——这真的很伤人。
话虽如此，没有人抱怨（我认为他们应该）对该功能。它有时可能会被使用。竞争可以用来对付我们的差异更少。
（请注意：我并不反对以与我们产品的正常工作方式一致的风格实现该功能；我只是反对以我们的竞争对手使用的风格实现它——因为其他相关功能的工作方式类似于损坏的实现在他们的系统中，而我们的系统更加理智和友好。）
这很难。有时市场会胜出。
几乎不可能回答这个问题，因为我们不知道你在说什么。
说了这么几点：
我倾向于实施它，因为这会让您的客户满意。
一个选项是给他们一个菜单选项，将他们引导到这两种方法。
可能是某种向导，可以帮助他们决定使用哪种解决方法。
虽然不是一个编程问题，但多年来我已经看到很多人都在为这类问题苦苦挣扎。
你需要问自己几个问题
1) 您或管理层是否进行了成本效益分析？问问自己“该功能将如何......”
2) 如果产品会发生根本性变化——将其拆分为一个全新的 SKU 是否有意义？
3）管理层最终会得到他们想要的。您想与他们合作为您的客户提供最佳体验并成为英雄，还是与他们对抗并寻找其他机会。
我会尝试为您的工作重新设计 UI，以使其对您的用户更容易和更明显。在一天结束时，客户支付账单，因此我们有义务满足他们的需求。当他们的要求会导致更多问题时，我们会提供不同的解决方案，这样我们就不会在未来产生更多错误，而且我们仍然让客户满意。
我会简单地猜测成本（在可用性方面）与收益，至少作为衡量的主要因素。例如，如果该功能可能会帮助 45% 的用户，但会使其他 55% 的用户更难使用该程序，请不要这样做。
定义“我们的用户”。它是您用户群的 5%、80%、95% 吗？您是否对他们进行了足够多的调查，以了解这是绝大多数用户想要的东西，还是只是一群流氓用户（他们可能是最难取悦的）。
我认为首先需要确立这一点。如果它是您的大多数用户群并且它在他们眼中增加了价值，那么我会尝试在您中间相遇的地方达成妥协，不损害您产品的完整性，但仍然为客户提供一个仍然可以替代的解决方案满足他们的需求。
向提出请求的人宣布解决方法作为请求的解决方案。使解决方法在 UI 中更加突出/更易于使用。
我会选择任何具有更高潜在投资回报率的东西。您会通过实施此功能来增加利润吗？如果是这样，这是否超过了支持新功能的成本？如果潜在利润大于您的支持成本，我建议您使用该功能。
如果无论是在经济上还是通过降低支持成本都没有收益，那么这样做是没有意义的。