研发团队的运营化改造 程显峰
快速的全功能团队才能适应互联网的节奏 《企业再造》对分工合作的否定 传统的运营、产品、设计、研发存在巨大的跨部门壁垒 为什么让研发团队参与运营 快速的全功能团队才能适应互联网的节奏 《企业再造》对分工合作的否定 传统的运营、产品、设计、研发存在巨大的跨部门壁垒
运营的目标是什么? 增加用户数 增强用户粘性 增加收入 NPS
一个SaaS团队 产品 设计 运营 研发 改造为期两个月 背景介绍 一个SaaS团队 产品 设计 运营 研发 改造为期两个月
因果性与相关性迥异 相信存在最佳实践 觉得思考能替代练习 做一个用户需要的产品 学习了怎么做是可以的,但从来没有学过怎么做是不可以的 研发为什么不理解运营 因果性与相关性迥异 相信存在最佳实践 觉得思考能替代练习 做一个用户需要的产品 学习了怎么做是可以的,但从来没有学过怎么做是不可以的
运营更像烹饪 看的遍数再多也不能代替动手 不断地调整 不断总结和刻意地练习(数据分析) 不能有任何假设 时刻准备颠覆自己的想法 相信数据而不是直觉(小火炖鱼)
没有产品能运营么? 写软文 做网站 开放注册 运营社区
数据说话-分析 倾听用户-调研 善于表达-内容 三个动作 数据说话-分析 倾听用户-调研 善于表达-内容
研发没有看数据的习惯,也不知道能看什么数据 AARRR PV, UV, CAC, LTV, DAU 跨越鸿沟 分析 研发没有看数据的习惯,也不知道能看什么数据 AARRR PV, UV, CAC, LTV, DAU 跨越鸿沟
用户从哪里来 用户的人口学属性 用户的关注点 数据分析能够回答什么问题 用户从哪里来 用户的人口学属性 用户的关注点
跳出率过低好不好? 停留时间过长好不好? 转化率过高好不好? 要优化数据,但不要过 跳出率过低好不好? 停留时间过长好不好? 转化率过高好不好?
工具大把大把 Google Analytics, clicky, optimizely, hubspot 分析世界天地广阔 工具大把大把 Google Analytics, clicky, optimizely, hubspot
研发每天查看运营数据 确保每个人对基本指标的理解是正确的 确保每个人都知道基本指标大致合理范围 讨论需求时考虑对运营指标的影响 养成习惯 研发每天查看运营数据 确保每个人对基本指标的理解是正确的 确保每个人都知道基本指标大致合理范围 讨论需求时考虑对运营指标的影响
用户调研遭到的误解太多了 研发往往特别不懈 其实产品经理一般做的也不是很好
调研的基本核心 问什么人 问什么问题
“你有什么需求?” “你看这个功能怎么样?” 只问不看 让用户思考 人口学属性假设 以为用户会为提出的需求买单 问问题才是调研 典型错误的调研 “你有什么需求?” “你看这个功能怎么样?” 只问不看 让用户思考 人口学属性假设 以为用户会为提出的需求买单 问问题才是调研
SONY用户调研举例
有什么功能 和竞争对手比有什么特色 你是怎么解决XXX的 你产品的大概原理是什么 什么是XXX,有什么用处 判断用户 有什么功能 和竞争对手比有什么特色 你是怎么解决XXX的 你产品的大概原理是什么 什么是XXX,有什么用处
让用户放松 《全能记者必备》 记录用户的行为,而不仅仅是用户的回答 设计封闭的问题 设计无需思考的问题 自己提炼总结 与用户一同工作 正确的调研 让用户放松 《全能记者必备》 记录用户的行为,而不仅仅是用户的回答 设计封闭的问题 设计无需思考的问题 自己提炼总结 与用户一同工作
为什么要直接面对早期用户 找到能与你一同成长的用户 和你的知识领域差不多 别人替代不了 5%的用户提供了95%的意见 初级运营人员常常忽视有价值的用户 不要在小白上浪费时间
不会写文章 90%没写过Blog Inbound Marketing 但谁才能最清楚地表述产品呢 全员写稿子,从翻译开始 学习内容营销
为研发开设了课程(洗脑) 如何撰写技术文章 运营基本模型 运营分析和优化 运营问题的技术化方案 如何有效分离运营需求和功能需求 用户调研和用户反馈 如何从运营的角度欣赏一个产品
SaaS的企业越来越小? 为什么不是把运营改造得更加技术? 探讨 SaaS的企业越来越小? 为什么不是把运营改造得更加技术?
感谢 感谢郑晔、张群英、杨海玲提出的宝贵意见