我的团队发现，分享知识的最佳方式是让产品团队假装成用户。我们找出一些我们知道会造成问题或让用户特别沮丧的事情，然后为产品团队提供一个相关的场景和需要完成的任务。我们设计这个场景的目的是让这些任务引导他们找到这些问题。我们为他们提供实时支持，就像我们为用户提供的那样，但除此之外，我们不会给他们任何额外的帮助或白手套服务。这听起来很简单，但这种形式得到了极好的反馈。
举一个具体的例子。我的团队知道我们的用户 现金应用程序数据 很难发布某种类型的仪表板。 ，但它从未真正阻止人们发布内容，因此从未将其标记为紧急情况。我们为产品团队创建了一些示例仪表板，并要求他们发布它们。接下来的 2 个小时里充斥着大量支持消息、指导请求和挫败感。
小时结束后，产品团队 8 个人中只有 5 人成功发布了仪表板。他们反馈说，被告知用户感到沮丧与亲身感受到这种沮丧截然不同。他们讨论了如何简化流程，以及在体验过程中他们会发现哪些东西会有所帮助。
从那时起，我们已经举办了几次这样的挑战。现在，我们的目标是，每当团队开始一项新的前端功能工作时，就举办一次挑战。我们一路上学到了很多东西；例如，我从仪表板发布挑战开始，因为这是我最沮丧的事情之一。到最后，团队对问题的理解更加深刻，但优先级并没有改变。这意味着这是一次很好的学习经历，但对他们来说没有任何结果。现在，我们为挑战创建场景，这些场景与优先级或即将开展的工作直接相关。