不断发货新事物的隐藏成本产品人员-产品经理、产品设计师、用户体验设计师、用户体验研究人员、业务分析师、开发人员、制造商和企业家2020年9月09日真实的公司文化、文化、企业销售、增长、迭代、微服务、产品文化、路线图、销售、利益相关者管理、技术债务、记住产品记住产品有限公司1796产品管理7.184 https://www.mindtheproduct.com/the-hidden-costs-of-constantly-shipping-new-things/。
我在一家名为Base CRM的成功创业公司工作了8年。它在两年前被Zendesk收购。在这段时间里,我看到该公司对初创公司的许多问题采取了不同的方法,但有一个保持不变:无与伦比的、痴迷于交付新功能的专注。最近,我更多地考虑了一家公司的整体情况,因为我参与了一项名为Probe的工作,所以我认为在Base应该有一些不同的东西。
免责声明:虽然我在这里写的东西听起来可能是负面的,但并不是那么糟糕。我们仍然是一家真正成功的公司,做了很多正确的事情,我们有一个伟大的团队,数千名销售人员使用的产品。我只是专注于我们可以做得更好的地方(包括我自己)。
基地的心态总是以产品和运输功能为导向。就连我们的座右铭都写着:“不发货就是空的”--还有什么更好的说法来说,你所有的研发努力都应该投入到生产中去呢?这种心态是由我们的首席执行官带来的,他是建立新CRM的幕后推手-乌兹·什米洛维奇(Uzzi Shmilovici)。他是我们非常年轻的团队中最有经验的人(我24岁时加入)。他的经历无疑有助于向我们灌输新产品功能的价值。
很快,整个组织都采纳了这一座右铭,并开始按照这一座右铭生活。完全公平地说:我认为这样做有很大的可取之处。作为当时的一名铁杆开发人员,我仍然相信我们销售的是出厂的产品,而不是它背后的技术解决方案,也不是自动化测试、代码覆盖率等。至少我是这样预测这个座右铭的意思的,我非常相信其他人也是这样看待它的。我不是百分之百正确的。
随着时间的推移,公司不断壮大。更多的客户,更多的融资,更高的抱负。我们的研发人员突然变成了40人,然后是100人。他们都抱着“发货前都是空的”的心态。
事情也变得越来越复杂。CRM是一个宽泛的话题,可以意味着很多事情。它试图接受公司拥有的许多不同销售流程的基础知识,以及广泛的其他功能,如电子邮件或日历集成。要将新功能很好地融入现有的生态系统,需要进行大量的工作。突然之间,我们的路线图上有了1年的项目(很好地隐藏在3个月的项目中,这些项目没有按时结束)。
此外,我们还签下了几笔大笔交易,他们是你不能失去的著名客户。这意味着自定义工作嵌入到已经很复杂的功能中,复杂性增长很快。大客户在纸面上听起来当然不错,但他们带来了成本(复杂性和非常亲力亲为的关系),这是我们没有真正准备好的,而且我们没有设法足够快地划定界限。
…。困难很快就开始堆积起来,不知不觉中,我们不得不处理很多事情。
我们还在产品的后端增加了很多复杂性。迁移到微服务意味着摆脱我们遗留架构的一些问题,但它将我们带入了更困难的世界(可以说是),比如跨服务保持数据一致性。有些我们只是通过购买更多的处理能力来设法用钱来掩盖。其他我们迫切需要修复的问题,特别是那些我们知道不起作用的基础设施的基本构件。一个例子是,我们的微服务之间的通信通道没有至少一次的保证-一些消息永远不会到达目的地端点,这会导致数据一致性问题。
当然,这一切都是我们成功的结果。我们有了新客户,指标看起来不错,我们很快就在市场上取得了进步。这都是因为我们在解决真正的用户问题。
但困难很快就开始堆积起来,在我们意识到这一点之前,我们不得不处理很多问题。
在产品方面,复杂性是相当令人无法抗拒的。我们有一个巨大的系统,其中有许多运动部件相互作用,这些相互作用有时很难理解。随着针对大客户™的定制解决方案的增加,交互中越来越多的缺陷开始显现。
关于产品决策的文档很少。如果您已经使用了很长一段时间(像我一样),那么您对该产品是如何工作的就会有相当好的理解。其他人不得不四处打听,但即使是想法的原始作者也不是所有的答案,因为情况往往很复杂,涉及团队中的多个人。
我们也不经常重访功能。产品规格经过深思熟虑,有时精心制作了几个月,但事实是,几乎没有一件东西是第一次就完美的。(如果是这样的话,几乎可以肯定的是,这其中包含了大量的运气)。这很正常,没有什么好羞愧的--无论我们多么努力地计划和研究,我们都是用不完美的信息来建设的,我们会尽我们所能。可悲的是,我们对我们的功能最初设计得有多好比想象的要自信得多-有人可能会说是傲慢-而且我们没有重新访问或迭代现有的功能。
后端也受到了影响。我们很早就进入了微服务的世界,这并不是说微服务不是一种强大的工具(我仍然是它们的粉丝),但你必须拥有如何做好它的专业知识。当时,我们缺乏经验,只考虑结果和好处,所以我们仍然非常努力地将我们的体系结构分离为微服务,在许多情况下,我们做得很糟糕。我们把它推得太快、太早,而且没有在整个过程中真正吸取教训-因此,实际上,我们只是多次重复同样的错误,而不是在前进的过程中迭代地改进我们的体系结构和流程。
我们在技术文档方面的进展也太慢了。有了这样一个复杂的系统,记录您的技术堆栈、代码和API是至关重要的,但随着发布新事物的速度,以及交付有效解决方案的压力,我们忽略了记录事物是如何工作的,而只专注于将事物带出大门。事后看来,在前进的过程中,我们还应该标准化更多的东西。如果没有编码或操作标准,引入新解决方案的成本就会增加。
到目前为止,我刚刚谈到了我们面临的挑战,以及我们感受到的痛苦。你可以从中学到很多东西,但我想确保我也分享了我在这个过程中学到的一些实际教训,这样你就不会犯同样的错误。
作为所有这些教训的背景,有一件事值得注意,那就是认识到组织文化的巨大而微妙的影响是很重要的。虽然我们的一些挑战是由于我们是一个年轻的、充满热情的创业团队的结果,但许多挑战可以追溯到“在你发货之前它是空的”的文化。这不仅仅是一种说法,它是一种嵌入到我们对错误、客户、增长和技术的看法中的想法。
我当然不是说这是一句不好的话,也不是说这是一种有毒的文化-它对我们的成长和成功起到了重要作用!但我要说的是,我们没有对它如何塑造我们的组织和我们的产品实践给予足够的关注。准备好在您的情况发生变化时调整您的组织。
首先,也是最重要的:无论你在产品设计上投入了多少时间,都要反复进行。即使你花6个月的时间完善它,你最好的、经过深思熟虑的猜测也是不够的。拥有新功能的冲动是巨大的-相信我,我知道!-但要确保你花时间照顾现有的解决方案。等待改进的地方还有很多,只要看看您的现有客户和他们告诉您的内容(通过您的支持系统或销售团队),信任您的团队,给他们时间改进他们以前制定的解决方案,这些解决方案可能会带来更多价值(或减少摩擦)。
在此期间,从您的后端收集有关错误和错误的定量数据。当您想要尝试和构建新的东西时,您在软件中忽略的复杂性和摩擦将不可避免地困扰您,所以请注意您的技术债务,并采取措施控制它。请记住,您的一些技术债务将出现在代码中,而另一些技术债务将出现在文档或流程中(或缺少文档或流程)。你需要同时解决这两个问题,不管怎样。
希望你能成功,赢得大客户。然而,要小心大额交易,因为虽然钱很多,但它们往往是有附加条件的。最有可能的是,您将用不适合的定制解决方案“污染”您的产品,这些解决方案甚至可能根本不应该是产品的一部分。这还将迫使您以某种方式重新设计您的团队结构-也许创建一个专业服务团队-否则您的路线图将成为您想要发货的东西和您的大客户™想要的东西之间的持续战场。我们认为这些类型的大客户将是进入企业销售世界的一条赛格威,但事实证明,它们并不是一条有保证的发展道路。事实上,我们在没有明显好处的情况下失去了我们的第一个项目-没有产品改进,没有为未来的企业客户提供参考或垫脚石。
如果你是个人贡献者,或者是一小群人的组长,一定要清楚地表达你的担忧。创始人(希望如此)专注于最重要的衡量标准和制定战略(这是有充分理由的!),但确保他们了解你负责的事情是你的责任。产品体验变差了吗?越来越多的错误堆积在后端?敞开心扉,要求时间来解决问题,否则你将不得不一直处理这些问题。