从微信的冷门服务，看产品如何尊重用户

　　优秀的产品经理要具有人文关怀，而不是一切以数据为导向。明确角色是谁？体验流程的繁琐程度如何？改变其中一点，也许就能让用户呈指数级增长。
　　“如果你根本不知道自己在讨论什么，那么对其强求精确是毫无意义的。”
　　冯诺依曼
　　在纷芜中梳理需求，判断取舍，对一位产品经理而言，有时比最后的交付更有价值。
　　一、需求分析：场景浸入式思考
　　“需求分析”的定义：试图发现用户期望的东西的过程，所以我们用“产品”去表示那些试图满足用户“复合的、一系列期望”的产物。
　　在我看来，需求分析是初、中级产品经理最重要的一项基本素质。
　　借鉴查理芒格的思维方法，如果你不确定一个需求的真伪，那么就去穷举一万个idea去证明它的不可实现性：
　　为什么TA有这个痛点？
　　这是TA的真实想法么？
　　如果我不做，TA能否忍受现状？
　　如果我做了，TA一定会使用这个产品么？
　　需求分析的方法论很多，浸入场景式思考，我认为是很关键的一项，且以港版微信为例，说明“场景化”的代入感，对于抓住用户痛点的重要意义。
　　案例分享：港版微信新服务WeRemit，支持菲佣汇款
　　移动支付的便利在这一刻发挥了重要的功用，通过WeRemit，帮助数以万计的菲佣解决最真实、最切身的需求。
　　她们身上有众多标签：中英文水平低、收入低、文化水平低、非互联网用户、薪水低
　　并且非常关注汇款通道的安全性、速度、资金安全，根深蒂固的观念是宁可腾出一下午时间也要坚持去银行汇款给在国内的家人。
　　我佩服微信团队的这项设计，透过背后折射出的是一种对用户的关怀。将自己摆在用户立场上去想：
　　我需要雇主给我提供更灵活的工作时间方便我去汇款么？
　　我需要更便捷的交通线路通往银行么，比如更快的巴士？
　　我需要银行更快的排队接待填写汇款单转账确认到账的服务么？
　　Nein！
　　对此，微信给出的思路是“汇款直通车”。
　　在demo完成后，团队又去实地做可用性测试，观察用户对MVP产品的接受程度，及真实场景下的使用情况，从而去优化流程和交互。
　　“浸入式”思考让产品设计者去深入探索用户想要的是什么，MVP输出后还要看用户的切换成本有多高。
　　同理还有淘宝的图片找商品，这是“搜索”的一大进步。对象在七浦路市场淘到一件宝贝，怕老板乱报价，需要去淘宝确认下价格，拍照图片搜索找到SKU查询价格即可，整个流程对于惯用淘宝的妹子而言，非常轻松，而这一项设计也是很巧妙。
　　如果大家去一个陌生理发店剪头发，会发现镜子旁有13英寸左右的led广告屏，轮播着广告、电影短片、歌曲mv、旅游节目等，这样避免了我们在疲惫、心情烦躁、内向害羞等情况下，不得不与理发师尬聊的处境。
　　思考场景化，是对用户的尊重。
　　二、尊重个体人，即使TA不是你的用户
　　优秀的产品经理，多半是个感性、悲天悯人的人，而不是一切惟商业价值为导向的冷冰冰设计者。
　　TA不必深谙心理学，不必会讲故事，但必须懂得尊重人，懂得与队友、用户和陌生人进行“非暴力沟通”。
　　摒弃你心中的功利主义，只有这样，你才能突破自己的枷锁。
　　明确角色是谁？体验流程的繁琐程度如何？他们心中不快却又不愿说出来的“隐疾”。改变其中一点，也许就能带来指数级的增长。
　　且看真实的2个例子：
　　1。体谅年老的用户
　　春节过年回家，看到长辈也能熟练使用微信，字体的扩大，方便了老人阅读。微信的老年用户月活超过5000万，极为克制的微信没有再去压缩用户路径，而是将通过视觉和交互设计优化，体现了对老人的尊重与关心。
　　同理还有滴滴司机版的大按钮，辅以暖暖的橙色，方便中老年司机去触碰，在车不熄火，在深夜光线不好时，安全有时超过便利。
　　最贴近生活的就是：交规规定机动车必须避让斑马线上的行人，汽车的前包围使用塑料而非铝合金等，也是为了保护行人。
　　2。体谅非互联网用户
　　笔者的小舅是名英文0基础的军人，喜欢跟外聘专家一位美国老外，讨论政治、枪支等话题，而微信的翻译功能则提供了一个良好的契机。
　　虽然时隔13小时的时差，但微信通过精确的实时翻译给两位跨国好友提供了一座沟通顺畅的桥梁，有时候，对于一位学历不高的非互联网用户而言，这是很温馨和实用的。
　　三、需求明晰在产品交付中的重要意义
　　1。敷衍需求，你的产品就没有生命
　　作为产品经理，那就是产品的owner，要知道自己做什么，而不是被动得去“接收需求”。我见过不少产品经理都是被老板or领导牵着鼻子走，沦为“产品助理”，失去了自己的灵魂，与扯线木偶有何两异？在自我怀疑中不断沉沦，最终也是曲终人散。
　　这样的你，不是PM，而是产品总监高级助理（画图，出文档，跟开发掰手腕）
　　2。追求效率，还是交付质量？
　　两者的极端，就是scrum开发流程（快）与漫长审批流（慢）的错误理解与应用。
　　很多创业公司会快速试错，每磨出一款MVP产品，就更换一位产品。为了追求快，我们轻评审重开发，看起来是“摸着石头过河”，其实这种方法蕴含了很大风险，既白白浪费开发资源，亦加剧团队动荡。
　　我们都知道：需求的更迭如果发生在立项早期，代价最小，而在测试验收前夕，则可能给整个team带来灾难性的影响。
　　也许你会问，如果评审本身就很敷衍和粗糙，仍然要坚持开发么？
　　“如果你根本不知道自己在讨论什么，那么对其强求精确是毫无意义的。”
　　冯诺依曼
　　所以，请立即回到原点，好好梳理下需求，决定做不做比做什么更重要。
　　须知：在不同阶段，变更需求对开发进度和交付质量的影响各不一样，在需求分析和梳理阶段，能以最小的代价稳定开发进度和交付质量。
　　笔者见过在UAT验收时，业务方需求再次变更，虽然最终强行上线，但开发拨出了3天的时间来debug，这一切都与需求立项阶段，需求方含糊其词，而产品经理也并未深究到底，给开发同学挖了深坑。前述案例发生前后如下：
　　背景：XXX公司财务系统开发前中期
　　Java：收付款后需要财务审批么？还是仅作“确认”？PRD里这段没有写清楚哦。
　　PM：这个我也不知道，你先做吧，我还要去问下业务。
　　Java：这伙计到底是不是专业的料啊？？？
　　像这样坑开发的案例，相信大家都遇到过。1，还是0，在给开发同学的PRD里必须明确，否则本模块不可用，还会影响后置流程的设计。
　　四、结语
　　好的产品经理疏导需求，有理有节地“分析”，明确哪些可以暂时放下，哪些暂时功用低但对后面的规划有重要作用。
　　产品不是功能的堆砌，大家公认产品也是有生命周期的，也许少折腾，把自己的想法克制住，对于产品的成长更为重要吧。