PMCAFF社区产品分析

一、产品概述

产品定位

基于职业的垂直社区-产品经理交流成长社区

PMCAFF成立于2010年5月,由阿里的产品专家费杰的一个产品经理QQ群演化而来,旨在做公益的产品经理交流成长社区。其针对的需求即为产品经理的深度交流和学习。

目标用户

1、成长期产品经理:帮助其快速成长

2、成熟期产品经理:帮助其对接资源,包括人才及投资

3、互联网企业:提供人才(招聘)

其中,帮助产品经理交流学习是其产品核心,资源对接及招聘是在人才聚集之后衍生出的服务。

PMCAFF的核心用户定位在3-5年的产品经理。根据官方信息,目前社区用户中3年以上PM占到80%。以这部分用户作为核心的原因,我认为从两个方面来看,用户需求上,3年的产品经理已经经过了初期标准化技术学习的阶段(如Axure、Visio、xmind等软件、PRD等文档的撰写、技术基础知识等),对非标准化问题的需求开始大量增加,但线下沟通的范围有限。问答社区能够较好的解决这个需求。从社区运营需求来看,3-5年的产品经理已经有了自己的思考,能够提出比较有深度的、优质的问题,也能给出富含思考的回答,对整个社区氛围的建立来说十分重要。

需求分析

针对“产品经理”这一核心用户,我认为主要有如下需求:

1、学习需求(专业知识及方法获取、能力提升);

2、具体问题解决方案获取需求(问题原因及解决方案的探讨);

3、职业提升需求(拓展人脉及名气,以获取更好的职业发展)。

用户画像

百度指数没有PMCAFF的统计,在此引用“人人都是产品经理”的数据,相信有一定参考价值

1、搜索趋势

“人人都是产品经理”搜索指数

从搜索指数来看,搜索呈现明显的周期性。工作日搜索量显著高于周末,说明其使用场景之一是在工作中遇到某方面问题的时候,使用具有明显的针对性(解决当前问题)。但无法说明基于无针对性目的的学习场景的使用情况。

2、年龄分布

“人人都是产品经理”搜索人群分布

用户年龄集中在20到40岁,正是从初级到高级产品经理的普遍年龄。

核心用户画像

1、Grace  在二线城市工作的产品新人

基本属性:25岁,研究生刚毕业。喜欢互联网,但对PM了解有限。热爱生活,喜欢体验各种产品。对工作和生活充满向往和激情。

工作环境:传统企业的互联网部门,或成长期创业公司。缺乏系统培训体系,缺乏好的师傅带领。对自学有强烈需求。亟需资源和指导。

产品行为:平时浏览别人的回答及文章,积累产品知识。经常对回答发表评论,简单表明自己的观点,不时发表回答,并随着经验的积累提升频率。渴望与同行间的交流。

2、Tony 在帝都知名互联网公司任职的高级产品经理

基本属性:32岁,产品岗深耕数年。懂产品、懂运营、懂设计、懂开发。能带团队独当一面。有经验、有想法、有人脉。

工作环境:成长更多依靠自己形成方法论,有很多想法希望得到验证。但产品规划受制于公司战略。

产品行为:偶尔回答一些比较好的、自己感兴趣的问题。偶尔发布文章。有招聘需求的时候会来看看。

二、产品架构


PMCAFF-web端产品架构
PMCAFF-APP端产品架构

PMCAFF的产品架构及界面设计都非常简洁。主要以社区为主,包含“文章”及“问答”两种表现形式。其中,“文章”注重观点的展示,更偏媒体;“问答”注重问题、话题的讨论交流,更偏论坛。

社区板块中的分类tab又包含三种,发现及热门属于基于推荐的分类,其中“发现”默认停留,以feed流形式呈现所有文章及问题;原创及活动的表现形式均为文章,基于文章类型的不同划分;数据、UED、运营等其他分类基于的是话题的不同。

精选是PMCAFF编辑运营的重点,包含精选的文章及回答,由编辑从UED内容中选择。这一部分也是web端与APP端架构的不同之处。web端将“精选”独立出来,与“社区”并列,而APP端将“精选”作为一个与“发现”、“热门”平级的子分类,放在发现之后。我认为这种差异的背后是两种不同的架构逻辑。web端从运营角度出发,根据运营的差异,将纯UGC的“社区”和包含编辑筛选的“精选”区分开。而APP端将“精选”作为一个基于推荐的分类,放到了和“发现”平级的位置。这种设计充分考虑到了web端和移动端的使用差异。PC方便打字,在web端拆分精选,弱化了社区的媒体属性,加强了论坛属性,能够保持社区的活力;APP端方便碎片化浏览,整合“社区”及“精选”,使APP架构更轻,也更易于阅读。

社区、精选、脑洞、招聘四大板块的互补业务逻辑

从运营模式上来看,社区是基础,包含了PMCAFF最有价值的部分(智力输出),同时也是不断产生价值的地方。精选是流量入口,它降低了用户获取高价值信息的成本,容易从外部获取流量(这或许也是知乎、果壳等知识型社区会将知乎日报、果壳精选单独作为一个产品独立出来的原因)。脑洞是补充,包含于产品经理专业知识有弱关系的内容,是对于现有内容的扩展。同时,我觉得它存在的核心在于用户运营。招聘是对于变现的尝试,也是现有业务的延伸。

对于社区,初期的运营重点在于品牌的建立。这其中又包括品牌的定位和传播。专业化的定位和KOL的存在,能在内容不够丰富的时期给与用户对未来内容较好的预期。而在PMCAFF已经有了一定高质量用户和内容的积累的之后,社区的运营基本上只需要继续做好内容的引导就可以了。对于精选,重点在于内容的运营,保证平台中内容的质量。脑洞包含了与产品经理人群相关,但与具体工作内容关系较弱的部分。这部分运营成功的关键在于对于用户群体的把握。因为PMCAFF本身用户群体的垂直细分,保证了用户在一定程度上有共同的认知、行为和思维模式,使得“脑洞”的内容能够得到共鸣和认同,能够有活跃度。其本身对于专业内容的扩展,也增加了用户的粘性。聚集了某一领域的专业人才之后,自然就可以延伸出专业人才匹配相关的服务,所以也有了招聘。

三、运营体系

PMCAFF的运营将内容、用户和活动有机的结合起来,核心明确,是社区运营中的一大亮点。

首先说一下PMCAFF中传统的运营模块。内容运营方面,主要是对于UGC内容的筛选和编辑,包括精选集的内容维护和首页的推荐。活动运营方面,主要是线上问答专场或线下圆桌、聚会等。这些内容和活动的运营都是围绕“提升”这个关键需求来做的。用户运营方面,PMCAFF组织了“手摸手研究院”,做产品分析。

在三种运营的协同上,也可以说是对社区用户行为的引导上,我认为PMCAFF做的非常好。它会不时做一些干货的分享,但不是把这些活动作为拉新的手段,而是将报名的条件定为内容的高质量产出,如对主题给出高质量的回答(如圆桌活动的报名)或新发布一个高质量的问题(限时干货资源发放)。这种活动一方面对参与的用户有限制,即可以产出高质量内容的核心活跃用户,完成了对核心用户的筛选;另一方面促进用户提供内容,并对内容质量有引导,从而影响了社区氛围。在此基础上,这种运营的结合又增加了优质内容的来源,完成了以活动凝聚核心用户,产出高质量内容,从而继续吸引用户,发掘更多活动的闭环。可以看到,PMCAFF的运营逻辑是紧扣“为产品经理的学习成长提供价值”的产品核心的,每一步运营都在提供更多价值,也因此得以有一个良性的循环。

PMCAFF大咖私密分享获取要求

四、商业模式画布


PMCAFF商业模式画布

五、竞品分析——PMCAFF VS 人人都是产品经理

这部分暂时只进行一个简要分析。说明在已有产品经理领导品牌的条件下,PMCAFF为何还有机会。

人人都是产品经理web首页

1、产品性质

人人都是产品经理更偏向于媒体,其内容来源可以算作PGC,由用户投稿,编辑审核后发布。而PMCAFF是UGC模式,更偏向于论坛。媒体更多的是人和内容的交互,内容质量是其关键成功因素;而论坛更多的是人和人的交互,人和氛围是其关键成功因素。从《人人都是产品经理》上,用户可以获得经筛选的内容,但无法满足对某一个没有标准答案的问题的深入探讨。PMCAFF解决了这一需求,因而具备发展空间。

2、目标用户

人人都是产品经理,针对该书的定位,目标用户为0-3岁的产品经理;PMCAFF针对用户为3-5岁的产品经理。产品性质的选择也是与这一产品定位相适应的。初级产品经理更侧重基础学习,中级产品经理更侧重非标准化问题的探讨。

3、影响力

下图为酷传数据APP下载量的对比。由于PMCAFF上架时间短,布局少,在此只对比日下载量,不考虑总下载。

PMCAFF及人人都是产品经理日下载量对比


PMCAFF及人人都是产品经理分类排名对比

从对比中可以看出,目前人人都是产品经理优势明显,但pmcaff也有明显的上升趋势。从两者的排名分类上,也可以再次印证两者定位的差异。

六、对于产品优化的思考

针对现有产品,我有三点有关优化的思考。

1、信息

功能上,PMCAFF现有的信息通知不包括他人回复或评论的具体内容,也不能够直接定位到对方的回复。虽然可以通过信息打开该条问题,但寻找具体的回复非常不方便。并且由于不能直接跳转,用户在收到信息后需要完整的阅读并记忆信息内容(谁回复的,回复的是问题还是回答,在谁的回回答下回复)才能找到对应的回复。在APP端操作的时候,除了寻找答案的不便之外,在有个大bug。在手机端似乎对于回复的评论只能显示最早的20条,并且点击进入详情页之后对计数的显示都会有误。这部分web端可以直接定位到回答。


APP端评论展示

界面设计上,信息内容强调回复人及问题,可能是为了代表其本身的可点击效果。但这种设计导致了两个体验问题。一是用户名和问题触发的链接跳转不同,导致触发区域比较小,容易出现点击没有反应的情况;二是在信息的强调上,我认为,如果继续采用不显示具体回复内容的方式,那么信息的类型(被认可或被回复)才是需要强调的关键。因为这个信息直接决定了用户是否需要继续操作以查看详情。现有的呈现方式需要完整阅读信息,信息获取效率是比较低的。

与APP端相对应的是,web的信息链接部分是又绿色标注的,视觉上非链接的黑色部分(即回复、认可等文字)更显眼,解决了信息强调的问题。


web版消息显示

消息推送内容及机制方面,可考虑根据不同分类设置tab及推送机制。目前推送的内容包含被认可(问题+回答)、被喜欢、被收藏、被关注、被评论、被回答、关注的人发表文章或问题、关注的问题有新回答等。从相关关系来看,分为与自己强相关的内容(自己的问题被回答、回复被评论或点赞等)及与自己弱相关的内容(关注的用户及问题的动态);从交互性上来看,分为存在进一步交互的(如收到评论、回答等)及不存在进一步交互的(包括被喜欢、被收藏、被认可)。目前的消息是以feed形式存在,没有区分,这部分可以考虑是否可以加tab。消息推送方面,目前所有消息均是即时推送。无交互的消息过多可能对用户造成骚扰,可以考虑对这部分消息在超过一定数量后设置呼吸推送。

2、问题

这个优化的想法来源于“脑洞”区 5age 童鞋的一个脑洞,关于问题的联合编辑。主旨在于由不同的人补充同一个问题,以获得更精确和深入的回答。思考之后,我认为可以对不同问题进行关联和引用。由于不同的人理解和关注的点不一样,单纯的联合编辑容易造成问题的臃肿的和混乱,也会对后期问题的拆分和管理造成困难。为了丰富和深化问题,可以考虑使用“引用”的形式,引用某一个问题的内容,再由题主根据自己的需求对问题做深化和补充,并作为一个单独的问题提出,并附上引用问题的链接。

3、链接

目前提问及文章中的链接,在APP端均是跳转到对应的H5页面,体验很不好,特别是对于已登录用户。单独页面包含了浏览器本身的顶栏、页面顶栏及固定的APP下载底栏,内容展示区域非常小。相同的情况在微信分享到朋友圈的文章中也存在,且微信中不支持在APP打开该文章,需在页面登录,虽然是想增加转化率,但方式个人认为并不友好。

移动端H5显示效果
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,080评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,422评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,630评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,554评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,662评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,856评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,014评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,752评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,212评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,541评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,687评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,347评论 4 331
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,973评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,777评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,006评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,406评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,576评论 2 349

推荐阅读更多精彩内容