在细分市场开发新产品的大约六个月后，一个令人担忧的问题开始浮现在我们的团队身上："我们在这方面花了太多时间而没有足够的时间来展示吗？"当我们第一次推出Segment时，这个问题的答案就更清楚了。创业公司第一次找到适合自己的产品市场的旅程中最美妙的一点是，公司拥有非常明确的跑道数量。当你的银行账户里有X美元，每月有$Y烧钱时，你就可以准确地知道你的现金何时用完。这种压力经常产生钻石。在那些已经发现产品适合市场的老牌公司，比如今天的细分市场，新产品的跑道计算就更加模糊了。对某一特定产品的研发投资是不可能的，它需要达到一个更高的收入目标，才能使一个有意义的目标贡献。幸运的是，我开始的故事有一个圆满的结局。这个产品变成了人物角色，现在有很强的产品市场契合度。但是，诚然，我们在构建这个产品时所采取的方法有一些缺陷。如果我们无情地优先考虑客户问题和解决方案，而不是太早着手基础设施项目，我们就不会让跑道问题悄悄出现在我们身上。在本文中，我将分享产品经理在后产品市场适合的初创企业中开发新产品的经验教训。我将讨论我们在构建角色方面学到了什么，以及我们如何将这些知识应用到下一个新产品，协议中。加在一起，在发布人物角色一年后和发布协议六个月后，这些新产品在ARR上的总价值超过1000万美元，两者之间有一个健康的组合！别忘了MVP（最小可行产品）三年半前我加入Segment时，我们的产品帮助公司将数据从生成地路由到对业务有用的位置。我们提供了一个API来从网站、移动应用程序和服务器收集数据。通过这一单一的整合，我们使公司能够迅速启用成百上千种新的增长营销和分析工具。我们知道，我们处于一个非常有利的位置，可以帮助我们的客户利用其第一方数据在细分市场中流动，做得更多。我们相信，我们可以帮助他们将他们的数据整合成一个完整的每个用户的图片，然后他们可以用来个性化他们的产品，营销和支持。这一变化将改变我们的价值主张，从节省工程时间到为企业创造新的收入。2017年，我们决定资助一个项目来实现这一愿景。我们从研究开始，发现客户对于他们想用拼接在一起的用户资料做什么有着千差万别的想法。一些客户希望使用配置文件为客户支持平台构建一个"侧边栏"，在这里，代理可以看到用户所做的一切，以便更快地回答他或她的问题。其他人则希望通过编程方式调用用户配置文件，在他们的网站上构建高级个性化。"为客户创建计算功能的团队仍希望在机器上创建功能"目的。与从客户的产品愿景和一般验证开始，我们开始构建一个基础架构，以支持我们发现用户感兴趣的广泛的用例。我们构建了一种方法来缝合不同的id，托管完整的用户配置文件，并在数据之上进行计算。我们对我们建造的基础设施很兴奋，但是大约六个月后，我们开始担心我们的跑道。因为我们没有专注于一个"需要完成的工作"或者对我们期望发布的特定解决方案进行模拟，所以我们没有办法向客户展示基础设施的工作来收集反馈。我们低估了我们所设想的基础设施所需的工程工作量，而且对于我们想首先为客户解决的确切问题，我们也缺乏具体性。我们意识到我们需要对接近。我们做了更多的研究，强迫我们自己优先考虑单个用例。从第二轮研究中，我们发现profile技术的首要用例是跨所有渠道的个性化。受众是成长型营销人员，他们需要一个强大的用户界面，以便根据最细的数据集中受众，从而同步到终端渠道。虽然我为我们开发的产品感到骄傲，但我相信如果我们开始关注这个级别，我们可以更快地将产品推向市场今天。从在这一点上，作为一个产品团队，我们决定在未来更严格地界定真正最小的mvp项目。模拟之前代码：最有效的方法从我们构建人物角色的经验中学习到，我们采取了一种非常不同的方法来寻找适合我们下一个主要产品计划的产品市场，重点是数据治理。我们注意到，有很多入站请求添加到我们称为"模式"的功能。Schema提供了通过段和基本控件传递的数据，用于筛选出一些数据。虽然我们本可以继续构建客户要求的增量改进，但我们没想到这种方法会对业务产生重大影响。基于这些请求的数量，以及提出请求的客户的购买力，我们决定退一步，看看如何为客户提供更具影响力的解决方案，以应对客户面临的潜在挑战面朝前我们建造了任何东西，我们指派了一个由一个设计师和一个产品经理组成的团队来研究这个问题。我们对超过25位在"数据治理"下提交请求的客户进行了访谈，这似乎是他们面临挑战的首要主题。这些访谈深入探讨了他们所面临的问题，他们如何优先解决这些问题，这些问题对他们的业务的影响，以及他们目前的解决方案。我们很快注意到一个模式：客户受到高度激励，避免向细分市场发送质量差的数据。杂乱无章的数据导致他们做出错误的产品决策，失败的营销活动，浪费了无数的时间来追踪和清理不良数据。一旦我们发现了这个问题，产品经理和设计师召集了一个更大的团队，包括工程部、市场部和销售部，集思广益，讨论如何帮助客户解决这个问题。我们想出了三个可能的方向，我们把它们带回给客户反馈：异常检测-当事件停止触发时，自动通知顾客。转变-当事件被错误地发送到段中时，允许客户使用段来修复它UI.自动数据验证-提供工作流来定义数据模式和一组工具，用于帮助验证和强制执行事件与计划的模式匹配。（这后来变成了协议。）我们本季度的目标是获得三张与客户的电子邮件或松弛消息的屏幕截图，这些截图显示出对其中一个功能的真正兴奋。我们的扩展目标是让客户告诉我们，一旦这个功能完全建立起来，他们愿意为此付费。这个游戏的名字是优先级排序。我们想确定哪种解决方案最能吸引顾客，这样我们就可以朝着那个工作和那个工作发展。最初的低保真样机最终产品解决方案。注意它们有多相似！我们最终将这三个想法的简陋版本原型化。我最初以为异常检测会胜出，但在运行了数周之后，我们仍然没有发现一种情况，我们拯救了一个客户免于破产。它看起来像是一个"很好拥有"的功能。转换可能解决了一些实际问题，但对于我们可以轻松应用到的数据类型来说，转换实际上没有任何价值，我们为所有数据类型构建转换的成本远远超出了我们为自己设定的跑道。我们有一次令人难忘的客户访问，帮助我们突破了专注于自动数据验证的边缘。我们的设计师、技术主管和产品经理飞往洛杉矶，与我们最大的企业客户之一进行了一整天的现场访问。我们观察了他们发布新版本的过程，他们有一个超过5名QA工程师的完整团队，他们需要在几十个不同的移动设备上测试数据跟踪，然后才能发布几乎一天的工作。我们意识到，如果我们的原始原型能够自动通知并强制执行他们首选的数据规范，允许他们在坏数据影响到他们的任何生产分析或营销服务之前隔离或屏蔽坏数据。这次访问以及与其他客户一起测试我们的新模拟的几次额外采访，让我们坚信我们正在做一些事情。我们继续与客户携手合作，最终确定产品的第一个版本，并继续与客户一起改进它今天。这个story还有另一个美好的结局：在我们推出的任何新产品中，协议的收入增长最快。目前，它比过去的附加产品有更自然的走向市场的动力，因为我们销售给购买我们核心产品的相同部门，联系原则为了重新找到适合市场的产品，我们每年都会继续寻找适合市场的新产品，我们从发布人物角色和协议。想法来自四面八方。协议成功的关键之一是从一开始就让工程、产品和设计进行协作。设计有一些突破性的想法，关于最便宜的原型，我们可以建立。在直接听到一位客户的痛苦之后，一位工程师意识到，为了帮助客户维护数据质量，我们有机会在代码编辑器中添加一个类型检查系统，以防止错误从一开始就被引入。这个金块变成了打字机，这是工程师们最喜欢的功能。事实上，PM（传统上是新产品市场的"发现者"）