在每个产品周期的某个时间,执行团队都希望帮助产品管理“improve”它的客户Beta流程。*这通常是因为上一个Beta花费的时间太长,没有得到足够的有用客户反馈或未能为GA上市后的销售突飞猛进带来收益。请注意,这三个目标是互斥的…

摆脱Beta困境的一种方法是,认识到Beta周期的不同受众和目标,然后为每个受众构建不同的程序。在这里,我将测试版潜在客户分为三个阵营: 忠诚的反对过量使用勉强的志愿者.

忠诚的反对派

这些是您当前客户群中最狂热的技术人员。如果您足够大,可以拥有一个用户组,那么忠诚反对派会参加下午的路线图会议,以交换配置技巧并游说缺少的功能。他们喜欢您的产品几乎就像他们指出小错误一样。

如果还没有,应该宠爱忠诚反对派。在Beta测试期间,他们将销毁您的预发布软件,对您的文档进行语法检查,并为您的新功能发明怪异的用法。 (这些都是好东西!) 不会产生任何短期增量收入,因为他们已经在向客户付款。
计划尽可能多的早期代码掉落至忠诚对立:这以非常规的思维补充了您内部质量检查的工作。为发现错误的人考虑使用限量版T恤,并使您的销售团队远离这些怪异的宝石。在晦涩的USENET位置放下对它们的赞美。

的Overcommitted

这些客户和潜在客户很容易辨认:他们会经常致电您的销售团队,以确保您的发布仍按计划进行。在极端情况下,他们会在您的Google Analytics(分析)发布日期附近建立自己的产品或服务交付计划-毫不懈怠。当您的GA交货日期不可避免地滑落时,它们就会陷入深水。

在Beta程序中包括“过量使用”是必需的,而不是可选的。它为您的销售团队提供了一种避免面子的方式来兑现承诺,并使客户希望隐藏自己的乐观情绪。您最初可能会抱怨并拒绝,但是期望被销售副总裁推翻。

不过,过度使用Beta版客户的风险很高。他们将期望生产准备就绪的产品经过全面测试,因为您的销售团队给了他们这种印象。有些人会将您的“早期GA发布”直接投入生产。如果缩短了测试周期以恢复丢失的工程时间,则可能会给您带来灾难。尝试为每个帐户分配支持工程师或智能现场SE,并准备要求工程部门提供一些非常快速的修复方法。

勉强的志愿者

现实一点:大多数测试版客户从未安装您的产品。您手工制作的CD和安装手册可能会与80个其他未经测试的Beta产品一起搁置。

迪尔伯特经理勉强的志愿者来自一对错误的印象:销售团队认为Beta版的安装将有助于更快地完成交易,而CIO则认为其网络经理(或系统管理员,数据库专家,服务台团队或软件架构师)有空闲时间玩新玩意。您的销售代表“要求很高”,并说服客户的CIO成为测试版网站。当这滴下组织结构图时,没有人愿意放弃另一个周末来调试您的代码。  (如果您在字典中查找“被动攻击性”,则会看到不情愿的志愿者的照片。)

您将花费大部分的Beta版计划来追寻勉强的志愿者。考虑要求每个人提供一个测试计划,以快速的方式将感兴趣的人与不感兴趣的人区分开。

重新封底:

结果 收入 风险
忠诚的反对 如果给出较长的Beta周期,则会获得真实的反馈 没有 没有
过量使用 可以为销售代表和客户节省面子 一些 一些
勉强的志愿者 没有 没有 浪费时间

SoundBytes

从理论上讲,我们都喜欢beta测试。实际上,忠实的客户会遇到一些恐慌的潜在客户,从而急于全面发布。这样产生的反馈很少并且收益最少。如果您想获得有用的结果,请为友好的客户计划一个较长的beta阶段,然后针对紧急情况安排一个简短的质量检查后周期。

*对于不熟悉Beta版测试的用户,这是在对(软件)产品进行完整编码并进行初步测试之后,但尚未准备好交付收入的阶段。经典的开发阶段称为 α (内部编码和粗略测试), 贝塔 或限量发行,以及 GA (“一般可用性”)或FCS(“第一批客户发货”)。每个初创公司都会在测试中作弊(质量检查 ),以便尽快发货GA收入单位。