任何一款产品都由两部分构成，表面的现象，以及背后的逻辑。
作为用户，我们看到的是现象，是通过界面、交互和功能体现出来的。作为产品经理，要看到逻辑，是背后的规则、机制和利益关系。
我一直说，现象背后总有逻辑，今天就继续跟你们分享一个产品案例。
平时我有一个习惯，会同时交叉使用互为竞品的不同产品，以此来测试和观察它们之间的不同。
在出行场景中，我是百度地图和高德地图的用户，按理说这种地图产品只要能提供精确的导航服务就能创造用户价值。
但仅仅是这样显然是不够的，也无法形成自身的差异化。
因此，地图产品经理们开始挖掘一些细分场景的功能和体验。
比如，同一个起点和终点的不同路线推荐，可以按照时间最短、不堵车、费用最低等方式来选择。
再比如，如果驾车导航到目的地，系统会自动提示周边可停车的区域。
这些设计都是在尽可能覆盖用户场景中的不同需求，前提是，产品经理自己得变成用户去获得那种现场体感。
我之前有个观点，坐在办公室的产品经理是设计不出好产品的，一定得去一线。
一线能带来真实的现场体感，能感受到最直接的问题，也能发现那些在办公室看不到的机会点。
好，对于地图产品而言，什么叫一线呢？
举个例子。
使用高德地图导航并开车在城区路上，遇到一个红绿灯，此时停车开始等待。
等待的过程中会形成一种感觉，那就是不知道红灯什么时候变绿，会有一种不确定性。
记住，这是一种用户感觉。
在现实中的红绿灯设计上，有些路口会在红绿灯旁边增加一个倒计时显示屏，上面显示了这个红灯还需要多久。
有没有思考过一个问题，为什么需要这个显示屏？
在我看来，就是给等红灯的司机提供一种确定性。
这就好比你在排队，告诉你前面还有几个人需要等多久，会比不确定的等待带来的感觉好一点，至少有个盼头。
如果你在使用高德地图驾车导航的过程中细心观察会发现，遇上一些红绿灯路口时，产品界面上也会显示一个红灯倒计时。
即便是遇到一些没有显示屏的红绿灯，在高德的产品界面里也能看到这个红绿灯的倒计时。
这个设计，就是为了解决前面说的用户感觉，提供确定性。
那么，高德是凭借什么能力来实现的这个功能呢？
肯定会有人说，高德是接了交通信号灯的接口，通过接口来实时获取红绿灯信号数据，然后在产品上展示。
可是，真的是这样么？
再思考一个问题，如果是通过接口方式来实现，是不是每个红绿灯都需要装一个数据收发模块？并且数据还需要统一收集到后台服务器？
假设按照这个逻辑，那一个城市那么多红绿灯，每一个的成本变高不说，关键是交通部门去做这种数据收集的必要性不大。
虽然现在有智能红绿灯和非智能红绿灯，但也只是在高峰期可以通过车流量自动调整时长来调控交通，对外提供数据接口的动机并不存在。
既然如此，那么高德地图这类产品到底是怎么实现的呢？
我想，大概率就是基于大数据的积累学习和判断。
用过地图产品的读者应该都见过这种界面，通过颜色来判断不同路段的拥堵情况。
颜色越红的路段，堵车情况就越严重。
同样的问题，这个功能是怎么实现的？是交通部门提供的数据么？
显然不是。
因为要做到稀疏程度不同的路况判断，就需要实现路段上不同点的数据收集，而能做到这种级别数据收集的只可能是用户的手机。
所以，当使用地图产品的用户经过这些路段时，高德的服务器就会收集位置信息，通过移动速度和手机密度来判断路况拥堵情况。
同理，如果正常行驶路段遇到红绿灯，那行驶中的车辆就会陆续停下来，以第一辆车完全静止到启动这个时间段为周期，通过大量样本的统计可以预估出这个红绿灯的时长。
基于这种预估，还可以衍生出一个功能，那就是预判需要等待几轮红绿灯才能通过路口，这个功能对于经常开车导航的人应该不陌生。
因此，这套功能的实现完全就是高德自己的逻辑，通过大量的数据去推测出的结论。
类似的功能设计其实还有很多，比如导航到某地址找停车场的时候，可以通过历史数据推测出大多数人选择的目的地，以此来判断合理程度。
这都是一些很小的细节，但正是这些细节的组合提供了满足用户预期的体验，从而创造用户价值。
这些细节的发现，需要去一线，去真实的场景中感受问题，产品经理自己要变成用户。
如果自己不是产品的用户，那这样的产品经理很难做出真正体验好的产品，因为他感受不到用户的感受。
就像我之前吐槽过的一些产品，我之所以觉得难用，是因为我自己就是用户。我之所以觉得好用，也是因为我自己就是用户。
所以，去一线吧，去获得那种现场体感，产品经理的机会在一线。
别成为办公室产品经理。
热门跟贴