惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

雷峰网
雷峰网
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
大猫的无限游戏
大猫的无限游戏
Google DeepMind News
Google DeepMind News
V
V2EX
T
The Blog of Author Tim Ferriss
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Hugging Face - Blog
Hugging Face - Blog
Stack Overflow Blog
Stack Overflow Blog
I
InfoQ
博客园_首页
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Last Week in AI
Last Week in AI
Recent Announcements
Recent Announcements
Vercel News
Vercel News
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
T
Tailwind CSS Blog
美团技术团队
Martin Fowler
Martin Fowler
宝玉的分享
宝玉的分享
Blog — PlanetScale
Blog — PlanetScale
GbyAI
GbyAI
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
J
Java Code Geeks

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
开源社区运营经验分享(三)搭建用户体系之前的5个问题
板栗 · 2022-07-06 · via 人人都是产品经理

编辑导语:开源社区的运营离不开用户体系的搭建,在搭建用户体系过程需要注意的问题有很多。本文作者分析了搭建用户体系之前的5个问题,并分析了问题的答案。感兴趣的一起来学习一下吧,希望对你有帮助。

回顾一下,开源社区运营经验分享已经完成了两篇。《开源社区运营经验分享(一)》讲了为什么要做开源社区,做社区的价值是什么。

《开源社区运营经验分享(二)》讲了从0到1 运营开源社区的策略,包括梳理用户画像、完成社区定位、用户精细化运营(用户分层、用户分类、用户分阶段)。

其中,分阶段运营用户的本质就是用户生命周期管理。此前已经单独就「用户生命周期管理」写了一篇,还不太清楚这部分的同学,可以戳这里预习。

核心思想都浓缩在下面这张图:

开源社区运营经验分享(三)搭建用户体系之前的5个问题

随着用户不断深入了解、使用和感受产品,加深与产品的关联度,用户身份也是在不断变化的,比如导入期对应新用户,成长对应普通用户。

之所以这么划分,是为了更加清楚用户在不同阶段的核心需求。

在这个基础,运营利用已有的资源,引导用户进入或者更持久的停留在「运营期望的阶段和状态」,进一步提高LT和Value,完成产品从用户价值到商业价值的统一。

如《产品生命周期VS用户生命价值搞不清楚?6张图带你厘清基础概念》所提,为了达成这一目标,我们可用的手段包括但不限于「用户成长体系」和「用户激励体系」。

开源社区运营经验分享(三)搭建用户体系之前的5个问题

而不管是成长体系还是激励体系,都要先思考下面几个问题:

  1. 问题1:哪些用户行为是我们希望看到的?
  2. 问题2:判断用户行为是否值得被激励的标准是什么?
  3. 问题3:如何判断这些行为之间的权重?
  4. 问题4:用户为何会按照我们的预期行动?我们能提供什么价值?
  5. 问题5:这个价值要怎么给,给多少,多久给一次,给的形式,整个玩法要如何设计,才能更好地刺激用户完成既定行为?

答案1:

对于一个开源技术社区来说,我认为可以技术使用深度和社区交互深度两个角度去思考。

用户来到社区的初衷是技术互动,和同行交流并解决技术问题。一个人只要他提出的问题能够得到及时有效的回复,他就能留下来。

如果他还能解决别人的问题,得到来自其他用户甚至是社区官方的认可,他就会更有动力在社区活跃。但如果只停留在技术交流,那么就低估了社区尤其是开源社区的价值空间。

PingCAP 联合创始人&CTO黄东旭在采访中说到,对于社区运营者来说,最关键的任务不是让沉默者更多或更深度地使用,而是让他们和网络中的其他用户建立更多的连接。

将网络效应从使用者的网络效应转移到基于信仰的网络效应,将社区中心从开源公司内部转移到外部以获得更大的势能。

翻译过来就是,技术层面的交流,只能算是物理反应。当用户之间的连接程度超越技术转向共同信仰或者价值观的时候,社区才开始有了化学反应。

这个时候社区的势能呈指数级增长,社区成员不仅可以自治,还能以共同体的身份对外发声与合作。

  1. 技术使用深度具体来说,包括但不限于使用技术产品、提bug、提issue、提PR等;
  2. 社区交互深度具体来说,包括但不限于参与官方内容转赞评,帮助社区其他用户解决技术问题,参与社区活动,在社区进行主题分享等。

答案2:

一个用户行为是否值得被激励的标准,一是用户行动以后会给社区好评吗,也就是说用户自己觉得舒服吗,有没有被满足;二是用户行动以后对社区有没有正外部性,也就是其他用户有没有因此受益。

因为符合这两个标准的才能让用户玩得爽,以及社区健康可持续地发展。不能说,这个用户爽了,其他用户都跑了。虽然我们经常说运营用户就是伺候上帝,但问题是社区不只一个“上帝”,更何况上帝之间的行为是会相互影响的。

答案3:

还是上面两条标准,优先考虑社区整体的健康发展。

其余行为,要结合投入成本来看。一般来说,用户投入越重的行为,我们越鼓励。

我们也很希望每个用户都能成为contributor,但很可惜达不到。对此大家也可以通过「官方投入」去观察产品和社区到底鼓励用户做什么。从某种程度来说,这也是一次交易。

答案4:

用户愿意听你的、按照你说的做,是因为他愿意这么做来交换你手中的资源。并不是因为你牛逼。

而我们能够提供的资源或者说价值一般包括以下四种:

  1. 物质:现金激励,购物卡,周边,苹果产品等硬通货;
  2. 内容:技术文档,经典QA,行业资讯,白皮书等;
  3. 服务:一对一技术专家答疑,与权威专家交流机会,企业参观;
  4. 荣誉:社区认证讲师、技术布道者等荣誉。

这里提醒一下,还是要学会通过荣誉激励用户去完成预期行为。

大多数时候,钱都是不够的,我还没有听过谁的预算是花不完的。

同时,人为了物质激励去做事是会疲乏且滥竽充数来薅羊毛的,只有内在动机才会让一个人真正优质高量输出(比如我现在一毛钱都没有,但心甘情愿在这里写内容)。

答案5:

这个比较复杂,需要具体情况具体分析。由于工作内容暂时不便公开,所以细节也没法说。但是有些原则可以和大家分享。

首先是有多大金刚钻,揽多少瓷器活儿。

一定要结合现有资源去设计整个体系,不要空头支票。钱不够的时候,一定一定要取舍,做好重点,而不是均摊费用!

其次是设计用户行为时,要时刻考虑降低用户行动成本,不改变用户本来的行为路径,除非真的有必要。

比如说一个技术用户进来,在部署安装的过程中大概率会遇到问题,在他解决完以后,你引导他写一个注意事项文档,这是OK的。

但你不要妄想一点点诱惑可以让用户专门为你创造一个东西。再比如,用户习惯了在GitHub上面提issue,用Markdown写作,你就不要非得要求别人和你一样用飞书文档交流。

最后要注意结合用户自然行为的特征(行动极限,行动频率等)去设计你的目标。

比如说,一般情况下一个用户每天也就是下午摸鱼的时候能够来给你当志愿者维护社区秩序,答上那么七八个问题,你就不要设计成每日答疑数量满50个可以获得XXX。

人又不傻,放在面前的胡萝卜才去够,放太远了就直接放弃掉了。你设置奖励的目的是让用户完成从现状到理想的跃迁,不是「我不玩了」或者干脆「跳他个粉身碎骨」。

具体的用户激励体系和用户成长体系搭建,可以自行搜索。由于这方面的内容很多,所以不重复造轮子了。

以上,over。

#专栏作家#

板栗,微信公众号:南有板栗,人人都是产品经理专栏作家,2019年年度作者。专注互联网营销/运营/增长领域,擅长内容运营/社会化营销/品牌营销咨询。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。