作为一个产品经理，我们需要经常和用户打交道：跟他们沟通，尝试理解他们的需求，向他们展示产品想法并获得他们的反馈。这基本是我们认为产品管理的核心问题。我们使用几种工具比如用户角色和故事，调查和可用性测试，A/B测试和实验法等，（使用一些方法）之后我们开始觉得自己是非常了解用户的。直到用户展示给我们看的观点表明有些事情是如此不同，让我们如此意想不到的以至于我们只能坐在那儿不动，盯着屏幕一边思考像“哦，真的吗？你是。。。”这样的问题。
我们想要告诉大家关于我们的产品和使用我们产品的用户的6个不同故事，先从Ru邮箱用户增长的三个故事说起：
尽管我们的用户基数是公认的庞大并且带有明确的地理位置特点（俄罗斯最多人使用的邮箱），我们仍然觉得我们故事背后的观点普遍适用于任一产品经理。我们清楚的记得那种“出乎意料”的感觉，并且我们想让你们参与分享——你们是如何思考你们自己的产品和用户的。在我们开始之前，让我们介绍一下产品：首先是Ru邮箱的实际主页——基本上它是每天有1500万用户使用的俄罗斯互联网主页（俄罗斯，TNS，不包括其他国家）。另一个是Ru邮箱的业务部分，免费使用电子邮件和合作商业解决方案。
接下来是故事时间。
意想不到的用户增长
Ru邮箱的主页用户是如此巨大以至于（我们觉得）几乎不会有什么事情会造成（用户）瞬间增长。这就必然导致有一天，我们看到了意想不到的和不寻常的用户在主页面上增长的数据表，移动和桌面版本的页面浏览量均明显增加：
我们赶紧检查什么原因会导致这样。一开始我们寻找各种类型的技术问题——是JS错误导致增加的？也许是页面平均加载时间增加？这是另一个对我们而言重要的技术指标。我们之前发现如果用户遇到技术问题她们倾向于刷新页面，并且保持刷新直到问题解决，所以我们也检查了刷新率图表。
我们花了很多时间来寻找潜在的问题，但是所有方面都是正确的——这完全难倒了我们。突然我们的一个同事经过办公室，非常情绪化地分享了他对俄罗斯足球队获得胜利的喜悦。我们再次打开了主页看到足球比赛是主要的新闻。很显然，俄罗斯足球队参加冠军赛是一个大新闻，并且在所有地方都是头条。
体育售卖
我们检查了这一假设，原来是主页上的CTR的新闻版块显著增长的同时浏览量显著增加。我们也看到到社会网络链接的点击在增加，并且主页也有一定数量的搜索请求。你可以领悟我们正在谈论的那种不同，下面你可以看到左边主页在足球比赛期间和之后的浏览数据，和主页上的CTR的新闻版块在足球比赛期间和之后的浏览数据。（右边）
原来在体育赛事中获胜是网络上最热门的话题之一，而这唯一的话题可能是一个失败的消息！我们可以直接确认用户数量的增长是一个很好的“兴趣温度计”—— 仅仅是通过关注我们图表中的峰值和低值，我们很容易在最近的冠军比赛中挑选出最有趣的比赛。
准备是一切
当然从我们的视角来看关于体育赛事最好的就是事实上你一直知道它们什么时候会发生，这样就有可能提前做好准备。在第一个不同寻常的用户增长案例之后，我们开始为主页创造不同的庆祝标志，它将出现在一场比赛取得胜利后，并祝贺我们的用户。
在我们意识到真实世界的事件（对网站）有多大的影响并会造成我们网站拥堵之后，我们开始以用户数据表上的峰值和低值作为人们对新闻和时事兴趣的更具体指标，（这个指标）教会我们在未来应该尝试什么事情。比如说，我们发现人们对总统在电视上的演讲有很大的兴趣。特别是在演讲期间网络使用的用户有个明显的下降因为很多人都停止了他们在网络上做的事情反而转向了电视。作为应对措施，我们增加了来自电视频道的在线广播作为我们的新服务，并且将它提升到主页。
我们学到什么
用户数据表上的峰值和低值既可以告诉你一些技术问题，同时（也可以提示你）什么在真实世界中是你的用户觉得有趣的话题和事件。并且这些话题和事件很有可能是发生在你的产品之外，甚至是（尤其是你的工作是基于数字或网络为基础的产品）在网络之外。
我们是如何尝试优化漏斗。。。并成功了
接下来让看看我们工作的另一个产品——Ru邮箱的业务部分。基本上它是一个为企业主连接他们的企业域名的服务——像greatstartup.com一样——对于Ru邮箱系统而言是为了给所有雇员创建一个功能齐全的邮件（比如 oleg@greatstartup.com）。为了实现这样的效果，用户需要在产品主页输入他们的域名，点击一个大大的绿色的“连接”按钮，然后核实他们是拥有域名权的。
那就是导致所有问题开始的。为了核实域名的拥有权，用户不得不花大量的时间来完成任务，比如添加新的DNS记录或者将具体的HTML文件上传到服务器上。这些任务是如此地难以操作以至于有些用户碰到这些任务后，他们连试都不试就立刻离开了。那么为了帮助这些遭遇困难或者觉得困惑的（也许仅仅是因为他们只是不明白DNS或者HTML的字面意思）用户，我们决定通过电话联系他们。
我们的想法是当（用户）点击连接按钮后在验证进程中增加一个额外步骤，就是我们问用户一些基础的个人信息比如他们的电话号码。我们决定尝试并对一小部分的用户测试这个额外的步骤，甚至没有实际联系他们，因为我们想了解这个变化对我们转化漏斗的影响是什么。
转化101？
有一个常用的产品管理工具——转化漏斗——帮助我们理解我们产品的用户数量以及用户在产品中需要的每一步操作的转化率。如果你对这个不熟悉，一个漏斗的比喻是用来描述在每个步骤中（用户）操作的减少（由于用户觉得受挫的，困惑的，不耐烦的或者任何其他）。那么有这个想法，似乎显而易见在操作进程中每增加一个步骤将会进一步降低我们漏斗和活跃用户的转化率。但是，到底有多大（影响）？
在测试前，我们有三个假设：
额外的步骤将会导致转化率轻微的下降——大概30%
（转化率）将会有个巨大的下降——达到2-3倍
我们完全看不到任何的下降
你觉得会造成哪种结果？
令人惊讶的大揭露
额外的步骤并没有降低转化率。相反转化率竟然提高了15%！通过要求用户多操作一点点就做到了，并没有真正打电话（给他们）帮助他们通过（验证）进程。实际上当我们开始打电话给他们并提供帮助后，转化率提高到了30%。
再一次让我们有了”哇哦“（不可思议）的感觉。当然我们开始思考“为什么？为什么在成功的连接中增加了额外的步骤（转化率）反而提高了？”
当它发生时，有一种关于时间投资的心理效应，被称为“登门槛效应”（ Escalation of Commitment）：当人们花费了时间和努力开始某件事情后他们倾向于继续做（这件事）。所以在我们的案例中，对于用户而言（他们的行为）解释变得简单了很多，推动（用户）完成复杂的过程以及在通过点击“连接”按钮并填写简单的表单来连接他们的域名。他们投资了一点点多的时间到我们增加到这个进程中的形式上，对他们而言只是放弃变得比拒绝完成更加困难。我们在做测试前考虑过吗？当然没有！我们完全没有期待过（转化率）会增长，反而以为会有个可测量的下降。
我们学到了什么
测量和测试一切并做好准备被证明是完全错误的。用户心理在产品成功上扮演了重要的角色——不仅仅是你的特点。去理解用户的想法可以做出伟大的（或者至少是“有粘性”的）产品。
验证过程中不必要的帮助
让我们继续回到我们“Ru邮箱业务”产品，我们的用户面对验证过程同时将连接他们的域名到系统中。在一个改版过程中（改版明显是产品经理喜欢做的），我们的设计师提议一种方式来提升我们的验证过程。现在的（验证）过程对于用户确实很难，因为他们需要去他们的主页注册网站并执行一些耗时的任务。在改版之前，我们已经决定通过发给用户一个注册类别的教学文章的链接来帮助他们，包括按步骤操作的文章，并说明应添加哪些域的具体记录。
所以设计师给出的建议很简单：如果我们可以确定一个域名的注册人，为什么我们不去掉教学文章的链接，替换成为用户呈现提供一套具体的一步一步的指示并立即注册呢？这个想法是如此的简单和明显，以至于我们的第一反应是立即执行，但它涉及搭配传输和重新写几十篇文章，这需要花一些时间。因此，在我们致力于所有工作之前，我们决定采用一种MVP-ish的方法，并用一篇文章对应一个注册人（在俄罗斯市场最大的），以及A/B测试，都是为了证实这种新做法实际上对我们的用户更好。
从一个开始
所以我们只进行了一个改变，只呈现给50%的用户并跟踪两组用户的成功连接的转化率。我们确信这个措施能提高转化率，但我们也好奇（这种措施）实际上的影响。会让转化率提高一倍吗还是仅仅会提升一点点呢？或者可能，只是可能，我们都错了它一点都没有改变转化率？
我们（再一次）被证实错的很彻底——转化率比之前的值下降了三分之一（比如，下降了66%）。我们是如此的震惊，以至于我们觉得自己运行了错误的实验，我们检查了两遍所有的东西。但是我们的结论是准确无误的——立即提供更多了解用户应该采取哪些步骤来验证域名的信息似乎吓到了用户，让他们觉得让他们完成整个过程是不值得的，并且彻底离开了网站。
显然，这与我们所预料的完全不一致，所以感谢上帝我们只是决定实施一个小范围的MVP和A/B测试！我们不仅节省了大量的时间和经理，关于我们的用户我们又新学到了一些。
我们学到了什么
即使你能正确的预测改变结果，为了更准备的知道产品改变的结果通过A/B测试来做一下测试总是更有用的。甚至开发人员都很高兴知道由于他们写的代码导致了用户数量的增加。记住你永远都是错误的。事实上是，大错特错。怀疑，测试和衡量一切。
到目前为止真正的教训
即使你认为你非常了解你的用户，他们依然不会轻易让你觉得惊喜。这一切发生的都是惊人的，甚至每一个惊喜都是有洞察力的，给我们展示了提高产品新的机会。
开放真实数据，真实的用户行为和外部事件是至关重要的。做好准备改变你的产品来应对用户新的期望，同时要能接受你犯错误的可能性。不要忘记检查两遍你的决定，并准备好测试任何以及所有可能的。用户新的现实生活知识，将永远引导一个更好的产品。
作者：Olya Kuritsyna And Oleg Parinov
