抽丝剥茧,从运营的角度雕琢产品细节.pdfVIP

抽丝剥茧 ，从运营的角度雕琢产品细节 作为一个IT 老兵 ，做过多年开发、多年产品 ，现 又 负责地图的产品运营 ，经常仰望星空 ，扪心 自问 ：一个会写代码的产品会是一个好运营吗 ？怎样利用自己的长处来改善现有产品的体验呢 ？经 过一年的摸索 ，似乎找到了一种通用的方法 ，听我慢慢道来。目前常见的问题 作为一个产品负责人 ，你接手一个现有产品 ，可有遇到一些困惑 ：怎样确定目前产品有那些问题 ？ 应该优先解决什么问题 ？自己使用产品的感受真的能够代表大多用户吗 ？ 作为一个负责具体功能的产品经理 ，怎样确定用户 什么地方用得不爽 ， 概念认知、交互和技术 实现上有哪些问题 ？怎样来证明自己想的是对的 ？怎样来说服领导同意你的改进想法 ？ 作为一个运营负责人或运营岗位同事 ，有没有觉得产品体验的改进和自己几乎无关 ？你想发力 ，却 很难说服领导和产品经理 ，想帮助产品改进体验但是老觉得隔靴搔痒 ？ 如果你不存 以上问题 ，本文可跳过⋯⋯ 如果你对用户群体有着全面深刻的理解 ，本文可跳过⋯⋯ 如果你有更好的办法 ，真心欢迎赐教⋯⋯ 问题的成因 作为产品负责人 ，大部分时间 想规划、写材料、审核各种输出、开会、与各种人沟通 ，能够聚焦 用户反馈 ，和用户深度沟通的时间能有多少 ？每天能够看一看反 馈 ，有个感性的认识已经很不 错了。导致很多产品负责人太过依赖自己的感受 ，忽略了大部分小白用户使用我们产品的实际情况 。 作为一个产品经理 ，每天大部分时间 思考功能 ，写需求文档 ，了解行业信息 ，与交互PK ，与开 发PK ，还要推进各种事情 ，只有很少时间能够跟进用户反馈问 题。但对于体验问题的根因往往会不 大了解 ，对不常接触的用户群体也会缺乏了解。想做一些用户反馈的深度分析 ，这好像是运营的 事情 ；想找一些粉丝来当面沟 通 ，也要找运营来协调 ；想做个调查问卷 ，Q Q t ips大多也是运营掌 握的资源 ；想看看每一步的数据 ，也要找数据统计同事 ；想深入研究用户行为 ，这似乎属于用户研 究同事的工作 ，导致大部分产品经理没有 精力也没有资源来通过全面的手段来分析某一功能模块的 问题。 作为一个产品运营 ，按职责分工有数据统计、用户运营、渠道拓展、内容运营、活动策划等 ，事事 和产品相关 ，但是好像又都不能直接帮助直接改进产品体验。 1000 ：100 ：10的思考 广研率先提出了1000 ：100 ：10 ，个人觉得这是一种简单直接了解用户群体的好办法 ，还听过allen 半夜找用户了解问题的故事 ，整个团队都很重视用 户反馈。这种方法使得产品经理接触的用户面 扩大 ，经常和用户接触 ，对用户群体的特征、使用的机型、使用的场景和使用障碍自然会有相应的 掌握。随着时间日积 月累 ，从个体到群体 ，从点到面 ，从量变到质变 ，对用户群体的理解自然会超 越大部分人。 但 ，真正要和用户进行深度沟通 ，是非常耗时耗力的事情 ：花半天时间联系10个反馈问题的用户 ， 大致只有三四个能够回复 ，有一两个能够提供有价值的信息就很 不错了。还有很多产品 ，用户反馈 太多 （一天上万条 ），产品经理太忙 ，缺乏系统的方法来进一步分析 ，导致这个方法落实下来的团 队太少。 而产品运营反而有得天独厚的优势 ，但产品运营很少把这块当成自己的工作重点 ，得要老板认可投 入资源 （ 此也感谢支持我们这么做的睿智老板们 ），具体怎么做呢 ？ 方法要点 为避免产品经理看到的反馈不够全面 ，需要对用户反馈进行全面整理分析 ，量化分析出用户反馈的 问题包括那几大类 ，每一类占多少比例。让产品经理和领导对反馈这块有全面和整体的把握。先定 位出要解决那一个功能模块的问题。 为了进一步了解某功能模块存 的问题 ，需要汇总该功能一段时间内用户反馈的相关问题 ，并进一 步分类 ，把代表性的用户反馈列出来。 光看到用户反馈的表面问题是远远不够的 ，特别是地图这么复杂的A pp ，为了弄清用户的真实感受 和真实意图 ，还必须得进行深度访谈和可用性测试。这个思路和 汤姆 ・凯利 其著作 《创新的 艺术》、 《创新的10个面孔》中强调的是一样的 ，多接触用户 ，多观察用户 使用产品的实际情况 、实际感受才会明白根本问题所 。例如地图的用户 ，大多是使用各式低端手机 各种网络极差的 地方使用我们的产品 ，需要用的时候 ，大部分很匆忙 ，噪音大、户外光照强 ，和我们 室内吹着空 调使用高端机型 W I- FI网络的体验完全不一样。 对于更广大用户群体 ，我们可以Q Q t ips来下发调查问卷 ， 腾讯这是得天独厚的一个工具。通过 调查问卷可