在Asana是一个公开的产品之前，Jackie Bavaro作为第一个产品经理在幕后指导公司的产品决策。六年后的2017年，Asana是发展最快的协作软件工具之一，拥有超过25000名付费客户。与此同时，杰基·巴瓦罗随着公司的发展壮大，现在是Asana的产品管理主管。从调整体位到之前在谷歌和微软担任项目经理，杰基已经看到了各种规模的产品团队的运作方式，我最近在我们的播客上接待了她，深入挖掘她的经验教训。我们的聊天内容包括Asana的产品开发过程，她的团队如何继续缩小范围，她称之为"产品论坛"的常规检查点的价值，平销返利，平衡数据与产品直觉，消费返利新模式，等等。如果你喜欢这段对话，请查看我们的播客。你可以在iTunes上订阅，也可以在你选择的播放器中获取RSS提要。下面是一段经过轻微编辑的聊天记录。布莱恩：杰基，欢迎收看节目。产品经理最有趣的事情之一就是背景的变化。告诉我们一些关于你成为首相的途径。杰基：我走了一条相当传统的道路成为总理。我主修计算机科学和经济学，然后在大学期间得到了一个项目经理的实习机会。所以，我认为自己是幸运儿之一。我有一个朋友在去年夏天做过这份工作，他直截了当地告诉我，我必须申请这份工作。如果不是他真的把我逼上了，我不会意识到这对我来说是个好工作。布莱恩：现在你已经和很多不同的经前综合症打过交道了。有没有什么背景，你发现实际上是自然的或最适合成为一个？你能得到的观点越多样化越好。杰基：要成为一个优秀的项目经理，你是一个聪明的问题解决者，你喜欢思考产品和设计问题。我还发现，那些是创造者的人，那些已经建造了一些东西或者他们已经开始了一些事情的人，往往会做得很好。除此之外，你能得到的观点越多样化越好。现在我们实际上在招聘产品管理职位，我们没有先决条件，因为我们相信拥有来自不同背景的人将有助于我们制造更好的产品。布莱恩：有意思，所以你纯粹是在寻找天赋。你也曾在微软和谷歌做过产品工作。你认为每一家公司对什么是项目经理或应该做什么都有自己独特的倾向吗？杰基：几年前，我写了一本书，物联网流量卡，写了一本关于申请不同公司做项目经理的书。我用自己的经验和别人交谈，公司真的是五花八门。但是，如果我想概括一下，我会说，在谷歌，人工智能龙头企业，它是非常工程驱动的，而且非常非结构化。作为项目经理，他们会让你陷入困境，告诉你，你的工作就是找出你的团队需要什么。而在微软，它是由项目经理驱动的，而且非常结构化。一个团队中有多个项目经理，并从其他项目经理那里学习，项目经理负责非常结构化的规范以及他们所在领域的所有产品决策。在Asana，我们考虑了我们喜欢谷歌和微软的东西，也考虑了与Facebook员工的合作，因为我们喜欢清晰，所以我们把它写得非常清楚。项目经理负责挑选合适的问题，确定目标，并确定解决方案是否达到目标。pm不负责设计解决方案或决定如何构建。那是设计师和工程师。这使得体位的世界变得更高层次和更具战略性，即使是对于全新的经前综合症也是如此。确定经前综合症在体式中的作用布莱恩：你到底想让你的PMs在构建和交付产品的细节上有多高？杰基：我们很多项目经理每天都会和他们的设计师见面。他们会集思广益，给出很多反馈。所以，并不是说PMs不介入细节，而是有明确的责任线。首相必须决定，我们到底要做什么？我们要解决什么问题？他们必须能够与他们的设计师达成协议，让设计师负责解决方案。项目经理可以说，"嘿，我不认为这是达到我们的目标，易于使用，"但他们不会进去说，"把这个按钮移到这里来。"布莱恩：放大解决方案的细节或正在发生的错误，并缩小到一个更高的层次来关注正在解决的问题，或者更进一步地制定策略，这是你见过的团队斗争吗？我们当然觉得这是我们的产品经理的一场斗争。杰基：是的，这是我们试图在我们的过程中建立的东西。最近我们遵循双钻石的产品开发模式。首先，你要集中精力，围绕问题做一些扩展性的思考，确保你解决了正确的问题。如果你解决了一个错误的问题，不管你设计得多好，或者你建造得多好。一旦我们缩小了要解决的问题的范围，我们会对可能的解决方案进行另一轮扩展性思考。很多时候，你一开始就有一个想法，你可以一直坚持下去，然后建立起来，但是如果你花时间去创造更多的想法，你会想出更好的解决方案。

杰基的产品团队沿用了彼得·梅尔霍兹（Peter Merholz）创立的双钻石模型。布莱恩：这是我们今天早些时候作为一个团队所讨论的问题定义状态，以及它是在开始还是在不断重复。当你进入一个项目时，你是否发现对问题的理解有时会发生很大的变化？杰基：这是可能的。有一件事我们在体位法上还没有被正式化，那就是你必须如何安排事情，或者什么事情你可以重叠。一些团队会预先做大量的用户研究，然后再进行设计和构建。而其他团队只会从一个想法开始，开始设计，开始构建，尝试把它交给客户，然后再做大部分的研究。对于以后做更多研究的团队来说，他们通常会发现新的东西，并在进行过程中学习有关问题的新知识。其他团队也总能找到惊喜。我们总是试图尽早将我们的新功能交付给客户，所以要么通过beta程序，要么通过a/B测试，要么通过向人们展示原型。我们当然可以在以后了解产品的新东西，但是当我们试着提前做研究的时候，我会说很多时候，我们可能85%都是对的。我们真的试着用一种假设驱动的方法。我们将努力了解客户的需求是什么，真正关注我们确定需要开始的部分，然后开始了解需要添加什么。小范围的实践布莱恩：这就让我们进入了范围界定。世界上每一个产品管理团队都说范围界定至关重要。但我认为这是理所当然的。根据我们的经验，我们认为自己很擅长这项工作，但去年我们发现我们倒退到了大项目模式。我们必须非常慎重地进入小范围，并实际写下我们是如何做到这一点的。你的团队是否有过类似的情况，你觉得你需要把范围界定得很好意味着什么？杰基：当我们在界定范围时，我们要从目标出发。我们要从那里开始。当我开始做项目经理时，我知道范围界定非常重要。但是我经常做的是弄清楚什么是大的，漂亮的，全范围的发布：优先考虑所有的工作，然后切断所有低优先级的东西。当我这样做的时候，低优先级的东西最终会被大量打磨，比如一个额外的动画。这对获得价值并不重要。问题是你最终得到的产品有很多不同的功能，但质量并不高。所以我们转而从目标出发。假设客户有五种不同的用例，我们将首先从中挑选一种，并努力将目标做好。这意味着我们将有一个完全成熟的解决方案，然后我们可以运行下一个客户用例。当我们进行范围界定时，你需要从目标中寻找范围。我在前面提到了beta程序，我认为这确实有助于确定范围，因为团队内部将设置几个里程碑：第一个里程碑是我们的团队何时可以对这个特性进行内部引导？什么时候我们可以为我们自己的小团队做点什么。第二个问题是，我们什么时候才能让公司里的每个人都能在公司内部自食其果呢？那么他们会有一个里程碑，我们什么时候可以把这个给我们的第一个友好的客户？他们会为第一批友好的客户设定这一日期，通常是在实际上市日期前几个月。记住这个里程碑并不能回答如何确定范围的问题，但它非常非常清楚地表明了您想要确定范围；您将专注于您需要从客户那里学习的主要内容–beta版需要具备什么才能让您了解这些内容？布莱恩：你提到了范围界定，你把重点放在一个用例上，把它构建成一个高质量的，而不是为了得到更广泛的覆盖而忽略质量。你如何决定什么时候把你关注的问题解决了？你如何决定要覆盖多少个用例？你什么时候做了足够多的事情去做别的事情？杰基：比如说，对于我们去年推出的定制字段，轻淘客，我们有几个不同的用例。我们想到的一个用例是能够使用体位来跟踪bug。另一个原因是能够在敏捷短跑中使用体式。另一种方法是用体位法来处理那些你本来可以在电子表格中建立智慧的案例