百木园
最近，我在翻阅谷歌文档，想要与我一直支持的几个创新者分享一个研究性学习计划。
这时，我偶然发现了我在2017年申请产品负责人职位时做的案例研究。创业公司要求产品候选人做一个案例研究是十分常见的事情，这样他们就可以更好地了解候选人的能力。这很像要求开发人员做的代码测试。我不确定UI/UX人员需要做什么，但我肯定也会有这种情况出现。
出于好奇，我看了这两个案例研究，现在我决定将它们发表在这里。我相信这对那些希望任职高级产品岗位的人来说是有帮助的。就算你还没任职，读这篇文章也是有利无害的。
最后透露一下，通过这两份案例研究，我拿到了两份offer。但由于种种原因，我最终没有接受这两份工作，而是选择加入了Eneza Education，成为他们的产品主管。
我会删除掉公司的具体信息，把这份案例研究分为两篇不同的文章发表（这两篇文章都很长），把当年的内容原封不动地呈现出来，不会做任何改变。
废话少说，让我们进入正题吧。
首先，讲讲第一个案例：应聘处于成长阶段的物流初创公司的产品主管职位，当时的七个问题：
01
在一个小公司（尤其是在内罗毕这样的城市），我最担心的是能否按时交货。因为根据目前为止的APP使用情况来看，交货需要等待很长一段时间，所以我不能在这一点上有所保证。
我在下午1:50提出了一个送货请求，APP通知我如果是直接送货，最快可以在下午3:00到达。如果是间接送货，则最快可以在下午2:26到达。
我试了一下定时功能，但并没有用，因为我不能指定交货时间。而我的关注点在于，一定程度上保证交货时间。
当然，APP可能没法保证这个，这更多跟骑手有关。但是，该APP显示我周围是有骑手的。这让我更加不理解为什么需要这么长的等待时间。
其次，我会花时间来确保骑手和客户之间的沟通是准确的。在APP测试的过程中，有这样一种情况：APP通知测试者（我使用的是第三方），包裹已经送达，然而实际上并没有。
我不确定这是个故意设计的培训挑战还是单纯的技术问题。但这对客户来说可能是一个挑战。
最后，我会花更多的时间来规范骑手的行为。有时你会发现一个好的骑手在不工作的时候可能是一个很粗鲁的人。作为一家小企业，我们的客户/供应商未必会了解企业和企业之间的区别，所以骑手的言行举止会在很大程度上影响客户对我们公司的看法。因此，骑手需要具有从一而终的专业度。
02
1）拉新
我们在一天/一周/一个月内获得的新增客户数量是多少？我们是通过哪些渠道获得客户的（按数量细分）？自然增长和付费渠道的区别是什么？我们每周/每月可以获得多少独立访客？我们的客户获取成本是多少？客户获取数据将帮助我们了解我们的获客拉新速度以及增长的最佳方式。
2）留存
获取客户是一回事，留住客户是另一回事。往一个有洞的桶里倒水只会竹篮打水一场空。只有先堵住洞，再继续浇水才是有意义的。
我将跟踪我们每周/每月的客户流失率。如果流失率（未能留住）超过了获客率，那我们业务很快就会倒闭。对于任何产品来说，高流失率都是一个巨大的问题。通过跟踪这一点，我们可以了解，我们的客户在注册后是否继续使用该产品。
3）参与度
我将跟踪每日、每周和每月的活跃用户。我还会跟踪产品在某段时间内的用户活跃度，用户活跃度的一个例证是每天、每周和每月完成的交付数量。跟踪参与度可以让我知道客户是否真正依赖我们的产品。
4）月度经常性利率（MRR）
新的MRR（新客户带来的新收入），附加MRR（现有客户使用我们更多服务而增加的收入），总的新MRR（附加收入减去流失率）。跟踪MRR能从财务的角度展现产品的成长轨迹。
还有一些其他的指标，我会特别跟踪，以便利用它们来改善产品的用户体验。
5）满意度
我们的用户对产品的满意度如何？调查、客户评论、其他社交媒体上的看法等等都可以帮助我们了解这些信息。将其与客户服务数据（每周/每月的客户支持请求数量、首次响应的平均时间、关闭支持请求的平均时间）相结合，可以更容易地了解我们客户的满意度。
6）采用
基于我们交付的功能，用户需要多长时间才能将其熟悉运用？这个数据可以让我们知道是选择继续推送一个功能还是放弃。
7）任务成功率
客户需要多长时间才能完成一个特定的任务，比如给一个骑手下单？发出的任务完成的百分比有多少？这些数据使我能够确定用户在执行任务时面临的具体问题，为改进产品提供了一个数据驱动的方法。
03
产品管理涉及大量的不确定因素。如果改变的功能不符合产品策略，我会说“不”。
对于任何产品来说，产品的功能数量都是有限的。盲目地对每一个需求说“是”，会导致产品的臃肿。
在你提建议之前，要知道这是一个可以让客户在送货的时候聊天的产品。有时，团队成员可能会说，添加这个小功能又不会花很长时间，或者可能会说很多人都有同样的需求。
但其实，没有所谓的“小功能”，因为所有的功能都具有其复杂性。
的确，倾听客户的反馈是很重要的，但如果只是把它作为一个准则，你很快就会变成一个为不同客户构建不同功能的公司。但我们希望推出所有客户都会使用的功能。
我如何说“不”呢？作为一个团队，我们都必须了解我们的产品策略是什么。团队中的每个人都应该知道至少未来两年的路线是怎样的。所以共同的产品策略可以让我有理由说“不”，它让我有信心说“不”，它让我能够解释我们将专注于什么功能。
04
我会使用ACID测试，其中包括以下问题：
- 它是否符合我们的愿景——产品策略中新建功能的终极准则。
- 每个人都能从这个功能中受益吗——我正在避免建立一个一刀切的产品，因此我们推出的功能必须使我们所有的用户受益。但这并不意味着他们都会使用这个功能。
- 它如何影响现有的工作流程——它是改进、补充，还是有所创新？
- 它能使业务增长吗——它能增加收入吗？它是否降低了流失率？它是否能增加用户粘性？
- 它是否会产生新的有意义的互动——人们会用它来实现有意义的事情吗？它会如何影响我们已经搭建的其他功能？
- 如果它成功了，我们是否能负担得起它——它对我们的客服团队意味着什么？开发团队呢？它是只能在短期内奏效，还是可以让我们长期支持的？
- 我们能否设计出回报大于付出的方案——这可以从长期来看，而不一定需要在一年左右的时间内完成。
- 我们有能力做好它吗——要么不做，要么就要做得有特色。
- 我们能确定它的范围吗——我们是否有足够的信息来清楚地了解这个功能？
对于我们来说，要建立这个功能，需要对上述全部或者大部分问题作出肯定回答。只有在极少数情况下才会有例外。
05
我们必须确保在推出新功能时不会给我们原本的客户带来不便，因此推广工作将分步骤进行，每一步都有一个关键的结果来决定何时进行下一步。
1）团队测试
正在工作的团队将是第一组直接测试人员，即开发团队和产品团队。他们的主要任务是识别bug。团队测试允许我们在还在建设时加入新功能，而不用等到它完成。对一个小团队来说，这是快速而高效的，因为他们也清楚哪些功能还没有搭建。在这一步，我们会在测试环境中使用一个实时数据副本。
2）公司测试
下一步是向整个公司推行该功能，不需要特地教他们怎么使用这个功能（因为我们也会像这样向公众发布）。这也是一个做低成本内测的好机会。在向公众发布之前，先在公司内部推行，可以让我们弄清楚功能中容易让客户感到迷惑的部分。
3）内测
我们可以邀请该产品的一小部分用户参与内测，也就是将新功能发布给这个特定的群体，并作为一个测试版本进行交流。
他们将实际使用该APP，而不仅仅是通过模拟来进行测试。为了确保我们能充分地利用他们的反应（反应一直被认为在反馈之上），我将让一部分测试版本的内测用户来进行可用性测试，来看用户是否能发现并使用这个功能（即用户参与），看他们在工作流程中如何使用它，看他们是如何使用它的，并找出任何会阻碍他们使用的问题。
4）公开发布
一旦内测版本中发现的问题得到解决，我会公开发布该功能。这一步的一个重要部分是传递正确的信息，让用户知道可以用新功能做什么。
在这一点上，我将监测可发现性（有多快可以找到它）、参与度（有多少用户在使用它）和采纳度（有多少用户在他们的工作流程中使用它）。每项指标越高，说明该功能的表现越好。
06
1）KCB银行
该APP的设计和营销做得非常好。为了扩大该APP的影响，银行让客户和非目标客户都能使用。然后，KCB利用其所有渠道让客户和潜在客户都下载它。该APP还会定期更新，表明该银行想要建立一个人们会真正使用的APP，而不是一个摆设。
2）Overview Finance
我一直为财务状况跟踪时的概念而困扰，直到我遇到了Overview。虽然仍处于内测阶段，但这个APP有两个粘性功能。
其一便是它能自动跟踪通过Mpesa或Airtel收入或者支出的资金。例如，我要用Mpesa支付燃料费，它可以自动将其记录为燃料支出，这样就不需要我自己输入了。当我需要手动输入时，流程也非常简单，因为已经有了正确的信息。它为我做了一件小却重要的事。
3）Uber
关于这款APP的一切都很赞。无论是给用户带来一流的体验，还是更新的频率。不管是哪个版本，你都可以看到他们致力于改造什么。Uber司机大约7分钟就能到。这是一个很好的组合体验。
07
巴克莱银行的USSD程序我很不喜欢。基本上，巴克莱银行把他们的整个银行平台都搬到USSD平台上使用。该APP允许你进行RTGS或Swift交易，但每次想要在上面完成某个任务都要经过很多步骤。例如，如果我想看一下我的余额，我必须经过以下步骤：
几乎每一个过程都是这么冗长。
我打算下一个版本通过使用模式来决定菜单上的内容。我将优先考虑提款和余额查询等项目，因为这通常是用户最常用的功能。如果拥有使用数据、却不通过任何方式加以利用并将其用之于改进APP，是没有任何意义的。
接下来，我将进行用户体验研究，以了解用户使用这款APP的目的是什么，并据此来呈现选项。根据我过往的经验，APP的设计并没有考虑到正在使用的平台（USSD）的性质。
这是一个有趣的案例研究，我希望它能对你的下一次面试有所帮助。
原文作者：Kipkorir Kirui
原文标题：Product management application case studies for your next application— case study #1
原文地址：https://kiruik.medium.com/product-management-application-case-studies-for-your-next-application-case-study-1-e2f3fad00db5
译者：许绮博，人人都是产品经理实习生
本文由人人都是产品经理实习生 @许绮博 翻译发布，未经许可，禁止转载
题图来自Unsplash，基于 CC0 协议
给作者点赞，鼓励TA抓紧创作！
来源：http://www.woshipm.com/pd/5424827.html
本站部分图文来源于网络，如有侵权请联系删除。