【产品思维】聊聊我理解的产品思维

闲谈

窝在宿舍床上,抱着一桶泡面啃,嘴里念念有词:再不更新文章别人会不会以为我这个号已经挂掉了,思来想去,觉得今天必须得凿一篇文章以证清白。公众号维护一个多月现在才40多个关注人,好丢面子 (´-ι_-`)。

说正经话

今天想分享的内容是PM同学经常会听到的一个词:产品sense。这里想结合自己的经历,讲讲什么是产品sense。阅读文章之前,温馨提醒:

  • 系个人产出,能力有限,内容如有偏颇,还望在公众号里面留言,必定回复;
  • 产品思维不单单是PM需要,我想对于所有从事非技术职位的同学,体验一下这类思考问题的思路,想必有些积极意义;
  • 人人都是产品经理?我觉得是;人人都能成为产品经理?就比较扯淡了;

从5个方面来表述一下什么是产品思维。

一、以目标用户诉求为导向

这个短语里面有两个关键词:目标用户和诉求。

先解释第一个,什么是目标用户?对于任何一款产品而言,不可能所有的用户的都是它的目标用户。快手短视频很火,可是它的产品调性让我不喜欢使用,我不是它的目标用户;基金定投能够让财富增值,但是很多学生并不会投资,因为学生群体也不是基金产品的目标用户。作为产品管理的参与人,尤其是在接手新产品的时候,找准产品的目标用户,显得尤其重要,因为它关系着日后的工作决策是否切实有效。

那什么又是诉求?咬文嚼字的文字游戏就不玩儿了,诉求指的就是用户最需要的解决方案,诉求并不意味着用户需要,因为很多时候用户也并不知道自己需要什么。比如我说“我想吃东西”,给我拿个汉堡我会觉得开心,但是给我一碗饭我也会很满足,因为我的诉求并不是我想吃什么,而是“我饿了”。用户的言语表达具有临时性和突变性,而更具有参考价值的则是用户的行为,这也是用户研究存在的一个很大的意义。

我们常规思考问题的场景,更多的是以个人或者既得利益方作为出发点,无可厚非,因为很多情况我们的行为都是服务于我们自己。但如果从职于产品方向,则在面临问题时第一反应需要站在目标用户的角度去思考,讲究同理心,也就是换位思考。这也是为什么说成为产品经理之前必须要先成为产品的目标用户,毕竟“知己知彼,方能百战不殆”。

二、用流程的方式回归问题

这一句话有点拗口,语文不咋地的我也不知道怎么用一个短语来表达自己的想法。其实质就是,在处理问题或者设计方案时,学会以第一人称视角走完产品流程,在体验流程的过程中去发现问题并从中解决。产品服务于用户,用户在使用产品的过程中就必定会产生前后环节的衔接,而产品在设计之初也需要明确,哪条线是我们希望用户去走完的。

流程回归和换位思考有相似之处,不过前者讲究落地执行,后者则侧重需求分析。其实这种思考方式在小学老师教我们看统计图时就有所体现,先看横轴,在看纵轴,然后结合两种信息再分析独立的点。这样有条理的分析思路能帮助我们规避无用功的投入以及避免落下一下有价值的要素。行为总是有先有后的,这不过这次,我们是换成了用户这类角色。

现在很多需求产出的场景,往往是在某个环节或者某个功能点进行优化,较多忽略了在全局流程的层次来看待问题。当然我说这句话很容易被打,毕竟产品越做越大,要是每次都重复一遍流程思考,也就不适合互联网“小步快跑,快速迭代”的模式。两者存在冲突,但是依旧可以兼容,比如制定迭代几个周期就进行一次回归复盘,减少不必要功能的累加。一些“死胡同”性质的功能不能说失败,但是是有缺陷的。

三、时刻保持成本收益意识

这一点对于老资历的PM来说基本OK,可能也是因为被老板怼多了,工作经历丰富,成本收益意识也就形成了条件反射。那么对于像我酱紫的菜鸟PM,起初经常会觉得产品需要为用户提供良好的用户体验,因此一味的想把产品上所有影响流程的不足一一修复,可是往往忽略了需求的收益以及耗费成本

其实多被RD小哥哥吼几次,多被设计小姐姐怼几下,多被老板骂几回,多学点技术设计知识,差不多就能形成成本收益意识的条件反射了(* ̄∇ ̄*)。

需求设计的成本大概包括以下几个方面:

  • 技术成本:大多数需求实现是需要RD小哥哥一行行代码敲出来的。因此PM就需要了解一些客户端、服务端以及数据库方面的知识,免得提出的需求毫无人性;
  • 设计成本:不要以为设计小姐姐长得好看就好欺负,怼起人来也是不落下风,如果提出一些稀奇古怪的交互需求,恐怕做个动效都得花很久,基本的审美意识和交互知识,还是很必要的;
  • 资金成本:这方面主要体现在运营活动,比如红包激励、H5抽奖活动等等,都需要初步计算资金预算成本是多少,花出去的钱,一分都不能浪费;

那么相对成本而言,收益的评估维度又包括哪些?

因为这个不同产品的KPI量化指标不同,也没办法去一一衡量收益的维度,不过大致总结就是三方面:

  • 为公司挣钱;
  • 为公司省钱;
  • 不挣钱也不省钱,但是是为公司主航道业务而服务;

另外需要强调一点,无论是描述成本或者收益,量化指标非常重要,很多情况下无论是RD还是设计还是老板,最关心的就是需求的凭据,而凭据最有效的呈现方式就是数据。因为这方面自己栽了不少跟头,所以想单独拎出来讲。

四、凭数据和事实说话

无论是做产品还是市场or别的业务型岗位,数据往往是逃不过的一个工作要素。在上一篇文章《【需求评审】谈谈产品需求如何被“接生”》我在结尾处谈到了数据作为支撑需求评审的重要性。可能是因为自己从小就比较恐惧数学的原因,过去很多场景下自己的需求都是凭借用户调研或者简单的数据分析就开始产出了,对数据的挖掘程度还远远不够。随着几次磕磕碰碰的需求评审,越来越意识到数据在工作当中的重要性。数据分析作为PM的核心能力之一,需要去不断强化。

这一部分内容自己很难给出具体的case,想提醒的就是,实际工作和在学校很大的不同,就是在工作时的任何一个场景,无时无刻都在付出成本,而说服上级或公司提供这种成本,则就需要给出凭据,PM需要通过给出凭据来获取公司资源,而凭据呈递最有效的方式,就是数据。

似乎回到了当年“学好数理化,走遍天下都不怕”支配的恐惧。

五、懂得协调资源分配

这一部分可能显得比较虚,什么是资源,怎样协调,这些情况都是根据自己公司的业务状况而定。而PM需要做的,就是合理的将大问题根据拆解为小问题,能够定位问题的原因并将其交付专业同学解决。比如定位问题属于交互类交付给设计同学,问题出现在客户端则就交付给客户端RD,如果服务器宕机那么就需要让OP同学去解决,如果产品需要新用户则就要求运营去策划活动。在整个产品生命周期管理的过程中,各种各样的问题会层出不穷,PM利用产品思维在问题面前快速有效的去推动解决就显得极其重要。

资源协调和推动很考验PM的综合素质,尤其是在面临具体问题的时候更加如此,而且PM没有管理层那样的具体资源调度的实权,就好比古代战争时筹划谋略的军师,能够利用各种军事策略跟敌军战斗,但是最终调度军队的只能是元帅。所以,想要当产品大军中的元帅,骚年们,努力吧。

复盘:

我认知下的产品sense:

1、以目标用户诉求为导向;

2、用流程方式回归问题;

3、时刻保持成本收益意识;

4、凭数据和事实说话;

5、懂得协调资源分配;

——欢迎扫码关注“滔滔有话讲”——

【需求评审】谈谈产品需求如何被“接生”

洗完澡盘腿在床上,思索着今天应该需要写啥。

自己出校门实习也有了一段时间,待过大公司,待过小公司,也待过不大不小的公司。在每一次产品的版本迭代环节,总结来看,PM工作流程大致可分为以下几个阶段:

  • 需求收集:主要是需求池的维护,产出优化的初步思路。需求来源可能是用户反馈、boss要求、数据分析产出等等渠道;
  • 需求分析:明确背景,量化需求收益和成本,根据团队开发能力和其他限制因素筛选需求方案,以及排定需求优先级;
  • 需求设计:此阶段需要产出落地页设计方案,明确页面跳转逻辑以及服务端策略;
  • 需求评审:在包括组内feature评审,详细策略评审以及技术评审,目的在于明确风险点以及开发排期;
  • 开发跟踪:跟进开发排期进度,协调设计和其他资源;
  • 跟进提测:包括组件提测和全量提测,跟进修复可能的bug;
  • 上线观察:主要就是上线后的效果观察,若有A/B测试则需要对比分析需求的ROI;
  • 产出迭代项目,重复步骤一;

篇幅所限,没办法在一篇文章内描述完所有的流程,这次针对产品工作流程的“接生”环节——需求评审,谈谈聊一聊。

一、需求评审的“地位”

为什么没按照工作流程从头开始讲,为什么自己会将“需求评审”称作“接生”。PM这块儿一直有一个段子叫做“产品就像是一个孩子,PM、RD负责生孩子,运营负责养孩子”。如果把需求评审之前称为“受孕”,那么需求评审也就是“接生”的阶段。因为需求怎么做,能不能做,能做到多大程度,多少人来做这个需求,都需要在评审环节完成结论产出。避免需求被拍死,就需要PM在评审环节做好充分准备。

另外,PM舌战RD撕逼的场景,往往会在这个环节体现的淋漓尽致。

二、需求评审的几个阶段

  • feature 评审:基本由PM组内参与,主要是核对需求要点,避免发生需求冲突;
  • 组内策略评审:基本由PM组内参与或者少数设计同学,评审需求的策略逻辑是否合理以及初步设计方案,明确待优化项;
  • 组内策略优化评审:基本由PM组内参与或者少数设计同学,明确上一版评审基础上需求疑点,本阶段评审结论为定稿方案;
  • 技术评审:参与需求开发的全员参与,完成需求讲解和排期确定;
  • 排期方案制定:包括明确各个各个承接方具体的工作安排和负责内容;

三、需求评审“评”什么

如果把需求评审本身当做是一个产品,那么参与需求评审的成员也就是这个“产品”的用户。这些“用户”大致分为:PM、客户端RD、服务端RD、运营、数据组、QA、UI、UE以及各自部门的老板。我根据团队内不同成员的诉求角度,先来拆一拆这些“用户”都各自需要什么:

  • PM:完成需求内容的讲解,完成质疑解惑,需要明确需求承接方以及排期情况;
  • RD:了解需求的技术成本,明确每个需求的确切策略以及需求背景和收益;
  • 设计:了解需求的设计成本,用户体验因素的考量;
  • 运营:需要了解该需求是否需要适配推广或者运营方案;
  • 数据:需要明确需求收益的评估维度和评估方案;
  • QA:了解需求存在的风险点,排查用户以及技术层面的风险;
  • boss:了解成本、为业务或者公司带来的收益以及评估策略;

OK,取上述“用户”诉求的并集,其实就能够得出在需求评审的环节中PM需要讲解的内容,也可大致作为撰写PRD的内容框架。

  • 需求背景:功能诉求产出的原因,最合理、最有效的需求背景就是用数据支撑。数据需要贯穿评审的每个环节,包括明确需求收益、数据评估等等;
  • feature list:也就是所有本次待评审需求的整理集合,需要明确需求的优先级,各个需求的story子例,评审成员能够通过list一览整个版本的需求信息,也方便整理开发排期。
  • 需求详细:RD需要明确每一个需求的详细策略,同时QA也需要通过策略来检验需求是否存在冲突和异常风险,为了便于策略沟通和理解,评审内容能上图就上图(用户流程图、布局框架图、逻辑跳转原型图等等),对于设计同学来讲,若有设计需求,则还需要产出基本的demo样例,方便成员在实际开发前了解需求的呈现形式。
  • 评估体系:包括客户端打点统计,明确打点评估维度,便于在开发上线后做需求收益的评估工作。

四、啰嗦几句

1、PM是需求评审的决策者

往往很多时候,由于需求准备不足或者思考深度不够,在面临需求PK或者答疑环节,很容易被其他成员“带着跑”,以至于出现最终拍板的需求并非之前组内通过的需求方案。面临此类情况,为了推进评审进度,最好的处理方式就是暂停该需求的评审,进入下个评审环节,待会后明确清楚再定夺是否开发该需求。

2、数据是支撑需求的有力工具

就如同每个人都遵守法律一样,做决策时数据往往就是最有力的的武器。当出现团队意见分歧或者不认可,PM需要拿出数据来为自己的观点提供辅助,基于事实和数据做出的决策会比靠感觉和经验更有力度。

3、学会团队激励

以前看过很多帖子都说,技术评审环节可以减少背景、收益等要素内容,因为RD只关心需求怎么实现。但是事实并非如此,任何一个合格的RD,包括设计、QA在内,都绝对不只是一个落地实现需求的“机器人”,他们都会关心自己的工作目的是什么,收益是什么。因此在上线评估阶段,PM可以根据成员分工排期以邮件形式周知收益状况,让实际参与落地上线的同学了解到他们的工作最终为产品带来了什么。成就感的建立,往往也能为PM的可信任感增分不少。

(其实上面的话很多是我老板教我们的~~~)

复盘文章内容:

1、需求评审是产品工作流程的关键环节,直接决定了需求能否从idea到落地实现;

2、需求评审阶段主要分为PM内部评审、团队技术评审和排期制定;

3、评审内容大致包括需求背景、目的收益、详细策略、落地页设计和收益评估维度;

4、PM需要利用数据增强话语权和可信度,另外也需要通过收益数据来激励团队成员;

欢迎关注“滔滔有话讲”

【数据需求】除了与RD、设计和运营,简要聊聊如何正确骚扰BI同学

基本上在产品岗实习过的同学都知道,PM在平时工作中最多沟通的对象,除了boss这个顶头上司,就是RD小哥哥,设计小姐姐和运营大大们,如果是业务产品,那么还经常需要和商务、市场以及客服同学合作。今天暂时不聊同以上几个角色的情感纠葛,说一个陌生一点的角色——BI。

BI也就是JD的title里面常说的数据分析师。百度百科里面是这么介绍的:数据分析是指用适当的统计分析方法对收集来的大量原生数据进行分析,对数据加以详细研究和概括总结并产出结论。在实用中,数据分析结果可帮助人们作出判断,以便采取适当行动。

简要概括BI的工作价值:提取数据(信息)——统计分析(加工)——概括总结(结论)。

那么一个问题就是:我们如何跟这群数理逻辑能力超强的人群进行合理的沟通,使得双方合作的价值能够最大化呢?

我在前面《今日思考:作为业务PM,如何将其他非本业务用户转化为自己的用户》这篇文章里举过一个自己实际工作的案例,如何将其他业务用户转化为自己的用户。其实在这篇文章里讲到的用户调研以及用户归类阶段,就需要用到数据分析作为理论支撑,因为我们无法通过简单拍脑袋和研读调研报告就轻易下一个结论。

OK,引导话说完了,本文就想写一个之前自己抓耳挠腮的工作内容:如何向BI同学写一份需求文档(针对业务产品,自己总结的东西定有遗漏,虚心接受补充)。提醒一点,需求沟通的时候时刻记住双方的身份,需求产出方需求受理方。

1、需求背景描述

与同其他工作角色沟通的场景相似,作为需求产出方,需要向受理方描述需求产出的背景,包括需求背景,需求目标,受众人群,需求收益以及可能存在的风险,同时还需要向对方描述为什么在本环节需要对方的协助,也就是因为需求所产生的源诉求

2、明确评估方案

在这部分,需要向BI同学明确清楚数据分析的评估周期,部分场景需要精确到分秒;然后就是明确分析对象,在一些场景下,需要归类用户群体或者本身就是A/B测试分组对比,此类情况下就需要明确“主键”是什么。其次包括地域、分发渠道等等也都是评估维度方案需要明确的方向之一,具体方法可以参考《【数据分析】写给我们这些实习同学,排查问题如何数据分析》。

举个简单的栗子:之前做打车业务时,曾经需要对用户打车数据进行梳理分析,了解用户对用车业务的诉求,因此考虑分析过去一个月内,按照“专车用户”、“快车用户”以及“出租车用户”类别进行统计分析,因为不同用车业务用户诉求其实存在一定差异,尽管都是优化打车服务,但是针对性优化才能更好提升收益。

3、产出评估维度

这部分是需求文档的核心所在。前两部分基本是明确需求范围,本部分则是描述需求究竟是什么,也是在文档时最困难的阶段(慰藉自己死去的脑细胞)。简单描述就是,作为需求产出方,需要在文档里精确每一项待分析的需求并描述清晰简洁,以防止BI理解有误从而得出不符合背景的结论。这部分内容自己目前也是意会多于言传,不过给大家一个建议,采用“脑图”描述需求是一个非常好的手段,清晰而且简洁,从大模块细分到小维度,既能保证在梳理思路的时候不会混乱,同时能让BI理解更为清晰。

温馨提醒:

明确数据需求绝对不是让BI去跑字段数据,如果刻意为了精确需求而直接产出数据维度字段,那么BI也就不叫做数据分析师,而是SQL编写员。需求产出者的价值是保证需求的精准和目标导向无误,而需求受理者则是在确有需求基础上进行延展分析,如此合作才能最大化双方的职业价值,各扬所长。

复盘:

1、描述需求背景,包括背景、收益、风险、受众等;

2、明确评估方案,可以按照逻辑树圈定需求范围;

3、产出需求维度,是需求不是字段!

我是厚脸皮分割线


最近这段时间真是有些头皮发麻,挂掉了好几个中意的公司,周围人都真的好厉害。不得不说自己在学校错失了很多锻炼自己沟通交际能力的机会,现在是一说话就很紧张,一面试就像口吃(╯-_-)。。。

都说我缺魄力,承认,,,可是都猥琐发浪了二十多年了,这一下子让我可怎么改,桑心。

路漫漫其修远兮,求大佬带飞!

曾经去过百度

昨天刚去百度大厦办理完离职手续,工卡归还完后,也就再也没办法以一个实习员工的身份进入大厦了,内心还是有点酸酸的。

听说在知乎上黑百度才是正确的政治方向?

不存在的,我只是一个普通实习生,能力所限,没办法站在战略高地挥斥方遒,碎碎念一会儿。

百度给了我什么?——自己目前见到的最大化的实习生发展空间

主动、勤快

我是去年12月份入职百度的,所在部门属于目前百度仅有的几款口碑比较好的产品——百度地图。我的职位是地图客户端的C端产品经理,听起来很高大上,嗯,我也觉得。

为什么说实习生拥有的权力很大,就我自己而言,我和我的主管在职责负责方面几乎是拥有同样的权限的,主管能够看到的,能够参与的,能够负责的东西实习生同样可以(前提是需要主动请求,对实习生而言,主动很重要)。我所能了解到的,百度产品实习生的主管大多属于P4-P5,基本上也就是一线搬砖员工,所以对于产品、业务方面如果能够有实习生协助会减少一部分工作量,因此也很乐于能够有实习生为此分担一部分压力。

因为自己属于不干活儿浑身不自在的那一款,所以从入职熟悉业务之后开始基本上能够参与到的会议、谈判、需求以及能够申请到的wiki权限我都会去尝试自己去跟进一遍。无论是评审还是平时的工作会议,无论是上级经理还是RD以及其他员工,如果自己有想法的话就可以很大胆的讲出来,每个人都会很认真的倾听(有理有据的话)。只是这一点我没能够做好,可能是先天的闷骚因素,我大多数脑瓜子里面的想法都在肚子里被否定掉了,虽然时长能够听到别人描述了和我想过一样的~~~

在百度实习学到的东西真的很多,对于一个初出茅庐的菜鸡学生来讲,无论是对于了解互联网公司的职位架构,还是了解PM、PO、RD、OP、BD、QA、UE/UI、FE、客服(不懂简称的出门右转问一下度娘)等等位置的人所负责的工作内容,以及自己所处职位如何与同部门、跨部门进行沟通合作,都是非常好的锻炼机会。

反正就实习来讲,百度确实是一个good choice,我自己是一个PM,然后就职期间我又内推了好几个我的同班、隔壁班宿舍同学来百度做实习,普遍反映还是很好,有足够的发展空间。在大公司,每个人确实是螺丝钉,但是选择钉在哪儿以及钉的多深,by yourself。

我给了百度什么?——尽其所能的优化所负责产品业务指标

产品sense、责任心

在我还没有成为PM之前,就听过这么一句话“PM是爸,负责养孩子;RD是妈,负责生孩子;PO是奶妈,负责把孩子养肥。。。”一方面形象的描述了互联网公司各个职位在围绕产品时自己所处的角色定位,另一个层次是,产品就像是我们的孩子(喜当爹?),尤其是我们PM,从用户中来,到用户中去,经常使用自己产品,去体验去思考,才能够最大化的去优化产品业务。

在地图,当然我说的是C端产品哈,基本上一线PM的职责内容大致就是:

需求收集–>需求分析–>产品需求和功能策略制定–>需求优先级评定,划分客户端和服务端需求–>需求评审,裁剪需求–>版本容量评估–>协同RD、UI/UE排期,研发跟进–>协同QA内部测试–>组件封包,跟进版本测试–>上线发版–>指标监控,迭代优化。以上流程,每个月发版一次就基本循环一次。有很有幸,自己能够完整的跟进多个版本的地图产品迭代,贡献自己微弱的力量。

作为一个实习生,你很难像正式员工那样如鱼得水的在各个部门以及各个流程环节之中切换得那么流畅自然,也就导致有很多PM实习生无法跟进完整的流程,或者跟进完毕之后不知道自己的工作价值体现哪儿,以至于认为自己属于打杂或者感觉没有意思,其实并不是啊,做产品是一件非常非常有趣的事儿。

那么问题在哪儿呢?

成就感。

成就感可以来自于多个渠道,可以分为可量化和非量化:

可量化:后台数据(比如直观的PV、UV、DAU等等)、业务投诉量

非量化:用户、同事、老板的反馈内容(可以用NLP切词工具对评论内容进行切词或者分组,改版前和改版后反馈内容的核心词汇应该会有很大不同)、亲身体验

写在最后

不过需要提醒如果去百度的实习生,除了研发实习外,还是比较难转正的如果是PM实习,部门的headcount基本会极少或者没有,这个情况需要考虑,当然是对于那些准备工作的,如果纯粹是为了学东西,那么来百度是个很好的选择。

简单可依赖。

不知道该说些啥~~~秋招要来了,我得去找下家接盘。

【转载】数据分析实战-共享单车产品数据分析

很多人都在问:如何提高数据分析能力?笔者(申悦)认为一方面要掌握基本的分析框架和分析思路,另一方面就要不断实践。一种很好的实践方式就是:分析行业内典型产品的设计、运营思路,假设自己就是该公司的数据产品经理,你会如何对其进行分析

前一阵在“在行”上就遇到一个案例,学员想了解共享单车类产品的数据分析思路,本文就针对这个案例整理一二,供读者参考。如果读者中有摩拜或ofo的同学,麻烦帮我参谋下思路是否靠谱哈^_^。

步骤一:明确用户是谁

以摩拜为例,其产品可能的目标用户有2类:用车方维护方。用车方就是车辆使用者,维护方则是车辆提供者。用车方的诉求是随时随地有车骑,且付费后骑行体验要良好。维护方的诉求则是以最少的车辆服务最多的用车方,并从用车中得到收益。

步骤二:明确用户使用场景

维护方角度看,其简单场景如下图:

用车方角度看,其场景如下图:

明确使用场景、使用流程的原因在于:第一,我们的数据都来源于这些场景中;第二,我们需要通过分析这些数据,让用户每一步过程都顺利进行,避免流失;第三,还要让企业利益最大化,从而进一步让利用户。

步骤三:明确分析目标

经过人群定义和流程梳理,针对共享单车,我们可简单将分析目标定义为:

  • 提高成功骑行次数——用户利益最大化
  • 提高毛收入——企业利益最大化

步骤四:拆解目标

数据分析的思路就是将目标层层拆解,从每个子指标中发现问题。基于以上目标,可拆解为:

  • 成功骑行次数 = app启动次数 x 每启动扫码开锁率 x 成功开锁率 x 成功结束率
  • 成功骑行次数 = 每人每日行程次数 x 人数
  • 毛收入 = 充值收入 – 投入成本 = ((每充值金额 – 欠费金额) x 充值次数) – ((每车成本 + 维护费用) x 车辆数量 )

注:以上拆解因人而异,因经验而异,从不同角度可得出不同公式,具体要根据实际运营目标进行调整。

步骤五:明确数据观察者角色

拆解出的子指标,需要呈献给不同角色的人群查看,以此来进行不同维度的分析,因此在分析前也要明确这些角色,例如:

  • 决策层:关注核心指标、交易指标、时段趋势
  • 维护组:关注车辆状态、位置、轨迹、故障率、用户反馈
  • 运营组:关注骑行次数、充值情况、押金情况、欠费情况、信用积分
  • 产品组:关注骑行流程、交互路径、用户反馈
  • 开发组:关注请求失败率、App崩溃数

步骤六:明确数据度量

依据不同角色,可将拆解出的子指标进一步汇总整合,组成不同的统计度量值。这一过程中有一点要注意:每产出一份度量值,都要给出目的。也就是说看这个度量值能得出什么结论。没有结论的数值是没有意义的。如下所示:

核心数据

  • 评估推广效果——注册用户数
  • 评估活跃程度——启动次数、活跃用户数
  • 评估业务健康程度——成功骑行次数、每启动骑行率(用车密度)
  • 评估现金流健康程度——总入账、总出账、充值金额、欠费金额、车辆总成本
  • 评估车辆健康程度——车辆总数量、故障车数量

运营数据

  • 评估推广效果——注册用户数、下载点击数
  • 评估活动运营效果——充值用户数、邀请注册用户数、成功骑行次数、积分增长/消耗量
  • 评估用户质量——行程次数排行、骑行距离排行、信用积分排行、充值排行、欠费人数、认证人数

维护数据

  • 车辆使用总览——车辆总数+车辆位置实时呈现——未使用/使用中/故障中/预约中
  • 评估车辆使用率——使用车辆数/总车辆数
  • 评估车辆故障率——故障车辆数/总车辆数
  • 评估车辆闲置率——连续N日未使用车辆数/总车辆数,以及闲置车辆位置

产品数据

  • 评估需求满足程度/车辆调度效果——每启动骑行率
  • 评估产品使用情况——成功骑行次数、异常骑行次数、平均骑行里程、平均骑行时长、日骑行频率、启动次数、平均骑行天数、预约操作成功率
  • 评估产品操作效果——充值路径、注册路径
  • 评估产品使用异常情况——平均每次开锁成功率
  • 评估用户骑行习惯——骑行轨迹聚合,为调度路线做参考
  • 评估用户满意度——用户反馈好评数/用户反馈数

财务数据

  • 用户金额:充值流水、充值次数、充值金额、充押金金额、余额不足金额、押金退款金额
  • 维修金额:车辆生产成本、车辆维修成本

注:以上数据仅为举例,要根据实际需求调整。

步骤七:明确数据维度

有了度量值,就要思考可以通过哪些维度查看这些值,也就是要定义数据维度。常见的维度包括:

  • 按时间:小时、日、周、月、季度、年度……
  • 按地区:按省、按市、按区……
  • 按渠道:邀请注册、扫码注册、广告点击注册……
  • 按类型:已认证/未认证、已充值/未充值……
  • 按位置:GPS地图定位

以上维度也要再根据需求不断调整、扩展、优化。

总结:

以上七步进行完毕,一个基本的共享单车数据分析框架就搭建完毕了。作为数据产品经理,一方面可基于此设计统计系统功能;另一方面可依此对不同人群定期产出数据分析报告了。但以上步骤只是完成了冰山一角,如何在观察数据后,对数据的变化合理归因,并对产品、运营策略的优化提出改进意见,才是真正需要深入研究的!

【滴滴2016校招】产品策划题目

2016.9.6笔者作为在校生参加滴滴出行校招产品岗的笔试: 请你设计一款公共自行车产品(2016.9.6)。在思考这个问题的时候,我发现了更多背后的故事,下面就来揭露隐藏在这道产品经理笔试题目背后的商业野心和隐忧。

滴滴出行校招产品岗的笔试对很多应聘者应该不难,公共自行车产品基本每个城市都可以见到,但是这个题目也并没有那么简单,因为这个题目绝对不是一个单纯的产品设计题目;以下对这个题目的解析分两部分,第一部分我会从互联网产品的角度,详细说明如何进行公共自行车产品的设计,第二部分主要深挖滴滴出行给应聘者出这道题背后的隐藏的用心到底是什么。

1.题目分析

考察点:需求分析,产品定位,产品设计,营销策略

2.回答策略

说明公共自行车的特点和功能分析目标用户的需求痛点找出目前城市公共自行车项目的不足特色化产品设计和运营策略

3.详细解析

一、公共自行车的业务特点和功能

1.主要功能:短距离代步

2.产品形态:便捷小巧,特殊标志,易于识别的室外共享自行车;

3.摆放位置:主要地点都在户外,比如人流量大的地铁口,火车站附近,科技工业园区,商场附近,小区门口以及高校校园内;摆放点一般有固定停车位和固定锁

4.借用和归还:个人自动识别卡刷卡,车桩锁打开,借车;用户把车上锁,刷卡,系统记录还车;

5.费用扣除:根据用户两次刷卡时间差定量收费;

6.如何办理个人公共自行车业务:到固定的公共自行车管理站(一般是公共交通部门,西安这边是各公交公司的服务站点办理)交押金和实名认证,即可办理借用

二、目标用户痛点:

1、目标用户和使用场景:广大的普通市民的短距离出行,上下班过程使用,一般骑行时间20-60分钟,路程2-8km

2、需求产生的根源:

上下班或短距离出行,车外交通拥挤,车内人群拥挤,开车或者公交速度慢,闹心;经常骑车出行可以锻炼身体;目标距离比较近,打车一是价格贵,另外可能需要等车;近距离外出开车的话,停车位不好找;体验新事物,感受生命的活力

3、需求列表:

随时随地的快捷借用和回归使用简单方便,舒适便捷价格合理,外观漂亮

三、特色化产品设计

1、目前各个比较大点的城市都有政府主导的公共自行车项目,其业务特点正如我前面描述的一样,其实在用户使用过程中发现了很多不足和缺点,列举如下:

办理自行车业务时必须跑到固定的办理点,还需要携带身份证和现金,办理流程繁琐;借用和归还都是使用自动识别磁卡,一方面用户可能会忘记带卡或者途中丢失卡,另一方面此刻可能会消磁,会给用户带来麻烦;停车点的每个车桩锁对应一个车位,一旦车位用完后来的用户将无法还车,比如下班高峰时期,小区附近的停车点经常会找不到空余的车位;公共自行车都是停放在户外的,接受一年四季的风吹日晒,所以在停车点经常能看到不少损坏的车辆;用户费用从磁卡中扣除,每次用之后都要到管理站充值,过程繁琐;

2、根据用户需求分析和现有产品的不足的分析,我们产品的设计要素如下:

(1)产品定位:简单便捷,随时借还的短途出行便民共享自行车

(2)产品解决方案:

产品解决方案图

(3)产品特色:

业务办理,借还车辆,费用查询,查找附近车辆均是在移动客户端App便捷完成;停放点自行车都设置GPS位置定位系统,可以实时查看附近停放点和车辆行驶情况;打造无桩停车区,车身设置电子锁,扫码开锁,特定按钮锁定;pp产品本身就是一个计步器,提醒用户每天的骑行距离,用户可以查看和分享,还有骑行用户排行榜,让用户找到骑行的自豪感和健康感;允许用户通过App提前进行约车,定点定时使用;一个用户可以同时在线借2辆车,即使同行的朋友没有开通业务,用户也可以和朋友一块骑行;

(4)产品可能存在的问题:

由于是车身自带电子锁,面临被盗的风险,解决方案:使用特殊材料和外形制造车辆,给公共自行车打造属于自己的标签,比如使用特制塑料制作,如果被盗窃的自行车不能公开骑行使用,也没有拆卸卖部件的价值,则偷盗会大大减少;前期可能面临有些停放点设置不合理,用户借还车距离成本高,这个可以根据用户使用App平台查看附近停放点的数据统计进行合理在规划;在用户上下班用车高峰期,可能会出现用户借不到车的现象,提前提醒用户可以在App里面进行定点定时约车,根据约车情况进行人为的调控不同区域的车辆:比如可以通过公司的运营人员从其他区域临时调配,或者通过信息鼓励附近站点还车的用户把车还到在预约车超额的停放点,并给与贡献用户奖励;用户也可能会把自行车骑到违规区,比如放到自己家或者骑到郊外,此时一方面要通过提醒信息提示用户,甚至可以设置系统电话告知/警告,另外一方面通过设置信用等级的方式限制低信用用户的使用;同时还可以通过用户举报的方式举报不良使用者和损坏者;不设固定桩的共享单车,很可能会出现在停放区域随意摆放的的问题,随意摆放一方面影响用户体验,一方面影响市容整洁;所以在用户停车的时候一方面通过信息提示用户文明摆放,一方面鼓励用户分享自行车停放区的图片,起到自律和他律的作用;公共自行车一方面要接受风吹日晒的考验,另一方面也会被高频强度使用,同时还会有一些用户故意破坏,或者故意藏匿,所以车辆的维护成本一定不小;所以在产品设计的时候,尽量要考虑防盗,防破坏,防损毁的方方面面;在运营期,公司一方面要负责车辆维护,还必须对不良用户进行追责。

(5)营销策略

由于这种公共自行车产品商业模式简单,市场容量大,前景广阔,所以很可能被其他公司复制出现激烈竞争,所以当务之急是尽快获得大量用户,形成规模优势和群体效应;公共自行车是普惠的商业项目,其实有很大的公益成分,站在政府层面来看,是个造福市民的惠民工程,同时各级政府都在倡导绿色出行,健康生活的主题,所以深挖当地政府关系和资源,取得政府的大力支持,在政策,资源和权限上尽量不受过多干预和束缚;自行车是跑在公路上,进入公众视野,接受公众的评判和价值判断,所以不仅要给用户提供便捷的出行功能,同时外观要漂亮简洁,特色鲜明,以吸引更多的用户体验;比如可以给车子图上纯绿色和蓝色,就比较容易在市民心里赢得认可,同时也提高了辨识度,在车型的外观设计上,考虑轻简洁的同时还要考虑美观。借势营销:开展联合知名媒体开展“绿色出行,健康生活”主题月优惠活动,邀请名人,网络意见领袖,政府官员体验产品,打造骑行上下班的新风尚,引爆朋友圈和生活圈;

以上第一部分详细讲解了公共自行车产品设计的多个方面,这个完整详细的答案是我在这几天不断的翻查相关资料和思考得出的结论。然而在思考这个问题的时候,我发现了更多背后的故事,下面就来揭露隐藏在这道产品经理笔试题目背后的商业野心和隐忧。

ofo共享单车

摩拜单车

相信很多北京和上海的同学应该都听说过共享单车(ofobicycle,小黄车)和摩拜单车,这两款用互联网思维打造的商业共享自行车和以前各个市政府主导的惠民自行车项目差别都很大,共享单车瞄准了高校校园,目前获得了不错的成长,据统计:共享单车已经占领北京和武汉的三十多所高校校园,车辆投放量达到5万辆(包括一部分同学自行车的加入共享),先后拿到经纬中国,金沙江等机构千万美元的两轮融资;而摩拜单车定位是普通市民,2016.8.16开始进入北京市场,由于其产品的特色性,操作便捷,美观靓丽,虽然质量比较重(25KG),骑行速度也不快,用户体验并不是特别好,然而还是因为其产品独特的视角和解决方案迅速刷爆朋友圈和各大媒体,虽然摩拜单车在京城也就不足4万量的投放量,但就目前的形势看,已经取得了用户的认可和口碑,接下来要做的就是快速投放和引流,扩大用户群体了。

我们设想这样一个场景:在膜拜单车彻底占领市场后,自行车停放点大多数情况下可以随时随地借用,并且沉重的车子也改成了轻便的车型,请问在交通拥堵的城市,对于3-8公里左右的短途出行,你还会选择滴滴的快车吗?我随机对实验室的五个师弟师妹们访问了一下,结果是大家可能都会选择骑自行车,即使打车很便宜,交通不拥堵,因为骑行给了他们更大的自由度和健康感,所以未来条件成熟的话,骑车可能会变成市民短距离出行的习惯交通方式。

再设想这样一种场景,政府和摩拜牵手,不仅从政策和文化层面倡导公共自行车,而且在基础设施上比如道路规划,城市建设上面给予支持,那么未来的摩拜单车会不会成为一种随处可见的基础性设施呢?如果便捷,美观,方便舒适的公共自行车成为了随处可见的基础设施,那么前文提到的盗窃,停放点设置不合理,借不到车和用户违规的为题也迎刃而解了。

从以上两个维度来看,公共自行车业务不仅是滴滴出行的竞争对手,而且在未来是有可能比滴滴出行能够接触更广泛的用户群体,更有可能实现全民便捷出行的目标,不仅商业价值巨大,社会贡献度也值的称赞。

所以,基于以上的设想,我们大胆猜测一下,滴滴公司目前应该是正在考虑要不要涉足公共自行车业务的问题;如果要做的话,怎么做会比较好,是自己打造一款产品呢,还是收购目前比较流行的摩拜单车呢,或者是对投资比较看好的公共自行车项目?以上三种猜想,不管是收购,自主打造一款新产品还是投资相关项目,都需要对公共自行车业务和市场有足够的了解,这也可能是滴滴的高层和产品经理最近在不断讨论和思考的东西,因此,对于校招题目,让应聘者设计一个公共自行车产品,不仅合情合理,而且暗藏深意。

【转载】App组件化和模块拆分那些事儿

前言

最近事情比较多,2个月没写文章了。看笔者圣诞节还在写技术文章,就知道程序猿的生活有多惨淡。

上几篇单元测试的文章,笔者已经把大部分思路讲给大家听了,如果在开发中有新的思路和技巧,以后给大家分享。

接下来,想给大家讲讲App项目的组件化与业务拆分。

如果上Google搜“App模块化”、“App组件化”,可以出现一堆文章教你“如何组件化”、“组件化用到什么技术”,笔者经常搞不清他们说的“组件”、”模块”、“业务”到底怎么划分,很多作者对这几个概念都有不同的理解。这导致笔者当初在搜集这方面资料,非常尴尬,每看一篇文章都有地方跟之前的文章冲突,也不知道谁对谁错。

本文会从业务的角度,给大家讲讲为什么要拆分App业务,如何拆分,以及优点等等。


为什么要组件化、模块化

项目存在问题

  • 代码量大,耦合严重
  • 编译慢,效率低
  • 业务开发分工不明确,开发人员要关心非业务的代码
  • 改代码时,可能会影响其他业务,牵一发动全身

优点

  • 架构更清晰,解耦
  • 加快编译速度
  • 业务分工明确,开发人员仅专注与自己的业务
  • 提高开发效率
  • 组件、业务独立更新版本,可回滚,持续集成

组件化与模块化

组件、模块,中文字面意思相近,在英文上都可以翻译为“Module”,加上Android Studio上,library被称为”Module”,这就不难解释为什么我们谈到“组件化”、“模块化”,两者之间的区别相当的模糊。

组件

App工程上所说的 组件,应该翻译为“Component”,意思是组件、部件、元件。在电子电路中,电子元件是电子电路中的基本元素。在App工程上,组件是构成业务或者功能模块的基本单位。原则上,组件与组件之间互不依赖。

组件,components

例如,图片上传功能,应该叫“图片上传组件”,而不是“图片上传模块”。因为图片上传从功能、业务上,已经不能往下拆了。图片上传可能使用七牛sdk,或者又拍云sdk。无论图片上传组件用七牛sdk,还是又拍云sdk,都不会影响这个组件的功能,因此组件具有可替换性;同时,图片上传组件可以被多个业务使用,因此组件具有可复用性。由于sdk只是技术细节,它跟业务并没有关系。在业务架构图上,也不会出现“xx sdk”,因此我们说图片上传组件不能拆分了

同理,日志功能,叫“日志组件”,不叫“日志模块”。

模块

模块翻译为“Module”,字面意思。模块由多个组件构成,它可以实现一个独立的功能,甚至业务。

模块,module

例如,大众点评的美食功能,是一个业务,可以叫“美食模块”,习惯上叫“美食业务”。它可以拆分更小的模块:搜索、签到、评论等。

两者关系

从上面的阐述可以得出,一个工程,由多个模块组成,每个模块由多个组件构成。但很多时候,两者界限还是相当模糊。例如“日志组件”称为“日志模块”,也没有违和感。

  • 组件从业务角度上不能继续拆分,可替换,可复用
  • 模块的定义比较笼统,可以是一个Business业务,可以是技术架构中一个业务,也可以是几个组件构成的小功能。

无论是组件化还是模块化,目标都是把臃肿的工程,拆分为更小的部分,解耦各种复杂的逻辑,便于代码管理。


业务划分

一个产品的业务,其实是在规划产品功能,或者做产品原型时,已经定好了(如果连产品或者老板都没这概念的话,我们还是算了);如果后端牛逼的话,他们也会做业务划分,每个业务部署到独立的容器、虚拟机、服务器。所以,我们做业务划分时,可以咨询后端,也可以咨询产品经理。

例如,大众点评,首页已经展示了好多个业务:美食、电影、酒店、休闲娱乐、外卖、机票/火车票….. 这种多业务APP,通常会把业务尽量展示在首页,这种APP大的业务很好划分。美食、电影这类看起来完全不同的业务,笔者称为Business业务

大众点评-首页

但并不是这样划分就OK了,好像大众点评这种超级APP,每个Business业务都能分成很多基础业务。例如,美食业务,可以搜索商铺、预约、使用优惠券、点评、签到等;同时,电影业务也有搜索、优惠券、点评等。所以,搜索商铺、优惠券、点评这种基础业务,可以独立出来,被多个Business业务使用

业务架构

组件与业务

上文提过,多个组件构成一个模块,当模块相当于业务时,就是说该业务由多个组件组合而成。

还是拿大众点评做例子,点评基础业务,发布点评需要上传图片、网络提交、记录本地日志等,那么需要调用上传图片组件、网络组件、日志组件等

点评业务-组件

不仅仅点评业务调用,所有业务都会调用这些组件。于是,业务架构如下:

Business业务 -> 基础业务 -> 各种组件

业务-组件架构

业务与业务

情景

场景:在大众点评订了酒店,入住之后,打开该酒店详情页,大众在“推荐列表”给你推荐若干大保健……
(不要问笔者大保健是什么,笔者什么都不知道)

情况1:

前端H(负责酒店业务H):后端D,麻烦给酒店业务单独做个推荐大保健的api。
后端D(负责大保健业务D):大保健业务api D,你调用api D

前端在酒店业务Module,写了调用api D,功能上线。

=============================================================
过了一段时间,大保健业务做了调整,数据变动、改域名等。

后端D:前端H,api调整了,麻烦调用api D改为调用api D1
前端H:现在好忙,我加班搞吧。

于是前端H加班改代码,还要做单元测试等一系列工作。

=============================================================
又过了一段时间,大保健业务再次数据变动。

后端D:前端H,api D1改成api D2
前端H:怎么又改…..

本来前端H是做酒店业务的,为了大保健的推荐列表,不得不因为大保健业务调整,而加班加点。再延伸一下,如果酒店业务H还需要调用电影院列表、美食列表…..每个业务的改动,前端H就呵呵了。

情景2:

当然了,要前端不改动,后端保持原来api D也可以的。只不过,会引发下面对话:

前端H:后端D,不过你一直提供api D给其他业务使用,当数据调整时,api D做好兼容我们就不用改了。
后端D:你傻逼啊,兼容多麻烦,我们很忙的,你们不就改一点代码吗?我们还要#&^@&#$”@*#……

维护兼容/对外开放接口确实是一种解决方法,只不过会加重后端开发、运维的工作量,长期来看并不科学。

情景3:

如果在前端业务与业务在独立的情况下,也可以相互调用,那就简单多了:

前端H:前端D,麻烦写一个接口,让其他前端业务可以请求大保健推荐列表。
前端D(负责大保健业务D),没问题,你调用D类getHealthCare(),就会请求大保健推荐列表,并返回你要的数据了。

=============================================================
过了段时间,大保健数据变动。前端D在前端大保健业务D做了api D->api D1改动,并对D类getHealthCare()做了数据兼容,前端H不需要额外改代码。

从上面3个情景看,情景3是最优的做法,前端H并不需要跟后端D对接,大保健业务D改动,后端D不需要通知前端H,只需要跟前端D对接即可。而前端的兼容工作,比后端兼容工作要简单得多。

业务之间跳转

业务之间跳转,这个话题老生常谈了。无论是Android、iOS,都是URL Scheme跳转这种解决方案。原因是url不需要任何依赖,而且可传递参数。

业务数据交互

无论前端、后端,业务之间数据交互,都是很重要的环节,选用何种合适的方案,就考验架构师的水平了。

未做业务拆分时,直接调用其他业务的代码即可:

数据直接交互,强耦合

但业务拆分后,就不能直接调用代码了。两个业务相互独立,代码互不依赖,必须用某种协议(常用json)用数据。

间接交互,服务中心做数据中转

如果其他业务需要获取大保健数据,首先大保健业务要注册大保健服务到服务中心,其他业务才可以通过协议调用这个服务。

业务相互调用-服务中心

如何注册服务,Android和iOS都有不同的做法,而且方法不止一种。本文仅提供思路,技术细节,会在之后的文章阐述。

其实组件与组件之间,也存在相互调用的情况,可参考这种做法。

P.S.大众点评没有“大保健”业务,只有“足疗按摩”业务。笔者为渲染气氛虚拟一个大保健出来,希望大众的朋友谅解。


小结

组件化、拆分业务后:

  • 单一职责:开发人员专注于自己的业务
  • 依赖倒置:上层业务依赖下层业务,业务依赖组件,业务之间、组件之间不相互依赖
  • 接口隔离:业务之间调用数据,通过统一的协议与服务中心交互,不调用业务实际代码

代码质量与规范程度明显提高,高内聚、低耦合。业务职责分明,单元测试也更好写。如果业务拆分做得好,可以一个业务一个单独工程编译,不仅大幅提高编译速度,而且业务代码还可以回滚、版本发布等。

一切为了更清晰的架构、更干净的代码^_^。

【转载】如何产出一份深度价值的竞品分析报告

竞品分析,是众多产品经理、产品运营,乃至设计师等的常规工作之一。进行竞品分析,往往需产出一份竞品分析报告,以阐述分析过程及结论。

若大家观察目前各大社区、论坛上发布的竞品分析报告,会发现该类报告具备一些共性特点:篇幅长而累赘、内容泛而空洞、结构僵化(多半是被《用户体验的要素》所影响)、结论浅显无力。

费劲心血撰写一份竞品分析报告,占用读者大量时间,最后却未体现深度价值,这是为何?怎样才能产出一份深度价值的竞品分析报告?

本文将从竞品分析的概念、价值、方法步骤等三个层面进行阐述。

一、重申竞品分析的概念

一款产品(广义概念,包括实物、虚拟物品、服务等等)在概念阶段、研发制造阶段、营销阶段、维护升级阶段前后,对同类型竞争对手的产品,所做出的的具有针对性(特定范围)的客观、主观分析。

二、竞品分析的价值

竞品分析全局上能带来两方面价值,一是公司产品层面的价值,二是自身掌控力层面的价值。

1、公司层面的价值

通过分析竞品在战略、市场、商业模式、产品架构、营销、技术、资源等维度的优缺点,与公司现状的优缺点相比较,借鉴学习、扬长避短,确定公司产品的核心竞争力、未来发展与运营计划,占领更大的市场份额。

2、自身掌控力层面的价值

一名产品经理从不进行竞品分析,因缺乏对整体市场的熟悉、对竞争态势的认识,相信他心中是颤抖的。通过在恰当的时机进行适度、针对性的竞品分析,会让你更加自信,对产品、商业有更深刻的认识,具有更强的产品掌控力,在评审、协调、申请资源时,阻力将更小。

三、产出深度竞品分析报告

在讲这一节之前,我先总结下网上大部分人写竞品分析报告的典型框架、思路。该类型报告更多的是参考引用《用户体验的要素:五层要素》的做法,整篇报告围绕战略层、范围层、结构层、框架层、表现层进行全面阐述(也不知道是谁开的头)。

采用这类分析框架,导致整篇报告篇幅过长、范围过广、内容浅显,缺乏针对性,无法体现深度价值。结论部分,更多是停留在表面建议、局部功能模块上,给受众读者模糊、突兀、甚至不知所云的感受。如此一来,报告价值大幅度降低。

在竞品分析的概念一节中提到,我们需要在产品不同的发展阶段,分析不同的维度,开展适度的、针对性的竞品分析。产品经理要在不同的阶段做不同的事。

为什么呢?因为竞品分析是产品在某个特定发展需要的场景下,才被提出来的分析要求,它具有极强的针对性。

例如,公司想拓展某一子功能试水,会提前调查竞品,研究他们做没做,做得怎么样,那就只需要分析这一子功能的状况;竞品某次营销活动赚足眼球,获得百万用户,对我们造成威胁,我们可针对性地分析下竞品的长期、短期营销模式、它此时的产品主营业务;公司产品视觉被用户吐槽,那我们在改进的同时,去分析下竞品的视觉设计,是否有汲取的地方。

这些例子,都是在跟随产品发展需要的场景下,对竞品进行特定维度分析、特定价值输出的。

只有贴近产品发展需求,针对性地选择竞品分析的维度,方可产出具有深度价值的竞品分析报告。大而全的分析报告无重点,也不符合公司竞品分析的前提场景(公司没有一次性需要大而全的竞品分析报告的场景)。

针对某个阶段产品或发展需求所面临的挑战/困难,缩小范围针对性分析,方可对症下良药,进而产出一份具有针对性的、深度价值的竞品分析报告。

1、产品概念阶段

产品处于Idea阶段。在该阶段,主要由创始人或核心成员通过对行业、生活等各方面的观察思考,而闪现出的产品想法(灵感)。产生了灵感,还需要从用户需求、市场规模/现状、商业模式等高度层面细化思考。

除了思考,还需要一番竞品调研(分析),以熟悉市场情况。注意,在该阶段,竞品分析务必针对市场(用户需求、市场容量、现状)、商业模式等维度进行深入分析,至于其余的产品架构、功能、流程、交互、运营等维度,请暂时放开,它们不适合在这一步被分析,也没必要在这一步被分析。

此时,你的竞品分析报告框架大致为:市场需求、市场容量、市场竞争格局[细化]、商业模式分析、结论(竞品的优劣势,相比竞品,我们是否具有优势打入市场、具备何等资源、主打哪一个细分市场、采用什么商业战略与规划、有什么风险隐患)。

你的分析报告应至始至终围绕这几个关键点深入分析、研究,只有在这一步得出高价值的结论,才能进行下一步:是否要进入产品设计、研发制造阶段?

 2、研发制造阶段

经过了产品概念阶段,进入设计、研发阶段。在该阶段,除了自身对产品业务的思考、设计以外,同样需要对竞品进行一番针对性分析。主要分析竞品的产品架构、核心业务流程、交互等维度,在必要的情况下,甚至只需要分析某个业务流程、或特定的产品架构,这样才能根据自身的需求,针对性分析竞品,得出结论。

此时,你的竞品分析报告框架大致为:竞品架构对比分析、某一个或多个功能点的比较分析(流程、交互或视觉等体验),一定要找准范围,深入对比分析,产出结论。禁忌泛泛而谈。

3、营销阶段

产品研发制造完成后,需上线运营推广(销售)。在营销前后,除了根据自身情况制定的营销策略外,同样可对竞品进行营销模式全链条分析,扬长避短,提高致胜的几率。

此时,你的竞品分析报告框架大致为:竞品的营销团队、营销口号、营销渠道、营销策略、营销受众、营销周期、营销成本、营销ROI等等多个细分维度

对竞品营销模式的全链条进行分拆、深度分析预估,不仅加深了你对竞品的熟悉程度和敏感度,同时也便于制定相应的有效应敌策略。

4、维护升级阶段

一款产品从概念到上市后,结合市场反馈与自身产品规划,需对产品进行维护、升级迭代。该阶段是一款产品比较漫长的阶段。在此期间,可能会不断跟进现有竞品、或遇到新的竞品,我们可根据自身发展需要、或就竞品亮点部分,进行深入分析,例如单独分析其商业模式、核心业务流程、UED、营销模式、技术等维度部分,最终得出有效结论。

整个过程,同样需要克制自己,禁忌一次性全方位分析,这样产出的报告毫无价值。

另外需告诫大家:请勿过度分析竞品、使用竞品,以防思维固化,跌入竞品的怪圈而沉浸其中,导致失去自身产品的特色。

微信之父张小龙曾要求自己的团队,UI设计师禁止使用竞品,产品经理合理使用竞品。

四、总结

  1. 竞品分析具备两方面价值,一是公司产品层面的价值,二是自身全局掌控力层面的价值;
  2. 在不同的产品阶段,需针对不同的产品维度进行深入分析,方可产出深度价值的分析报告;
  3. 请勿过度分析、使用竞品;

最关键的依然是:根据业务发展需要和竞争态势,选择性地分析竞品的某个细分维度,方可体现分析报告的特定价值。

 

立场申明:《用户体验的要素》一书堪称经典,从五大层面系统性阐明用户体验的要素,让我受益匪浅。但我们在工作中使用从书本学到的知识时,需要考虑知识的融合度,不可生搬硬套,虽然我曾经也这样写过报告……

【转载】webApp和native App在交互上的区别

WebAPP和原生APP同为移动端,很少有研究这两项的交互区别,最近公司做了一次从原生APP到WebAPP(HTML5 )的移植,故总结一下期间遇到的问题及不同点总结。

(作者注:本文WAP经指正意为 webAPP ,many thx~)

从使用场景上,WAP用户面临比APP用户更严峻的问题:

1、页面跳转更加费力,不稳定感更强

思考点:如何减少跳转(扁平结构、页面布局技巧),增加数据及展示的流畅流程及稳定性(技术)

2、更小的页面空间(由于浏览器的导航本身占用一部分屏幕空间),更大的信息记忆负担

移动设备的屏幕要小得多。这种如同透过门缝进行的阅读增加了认知的负担。人脑的短期记忆是不稳定的,用户在滚动屏幕的过程中需要临时记忆的信息越多,他们的表现就会越差。

——《贴心设计:打造高可用性的移动产品》

思考点:排版更清晰、信息更简练 (可在APP基础上去掉一些丰富、复杂的视觉表现)

3、导航不明显,原有底部导航消失,有效的导航遇到挑战

思考点:如何有效的提供导航?有哪些形式?

4、交互动态效果收到限制,影响一些页面场景、逻辑的理解。

思考点:比如登录注册流程的弹出、完成及异常退出,做好文字提示。

针对以上困境,解决方法总结如下。

首先,从APP到WAP版,在产品上,最明显且核心的:

1、精简功能,只将核心的任务实现,非核心的枝节可考虑删减。

2、做好新的WAP导航.

3、补充从WAP站对 下载APP 的引导。

>> WAP导航怎样设计?

一、常见的几种WAP导航样式

1.1顶部底部导航的设计:

常见WAP导航设计

1.2导航快捷键设计:

美团:顶部栏固定位置

淘宝:悬浮圆圈–可展开的按钮

优酷:非首屏时页面右侧悬浮

导航快捷方式

二、有效的导航设计

1、基本的快捷导航中包括 返回常用页面(如 首页 我的 等)的快捷方式

2、出现深层架构时 及时补充返回重要层级页面的快捷方式

3、情境式导航,方便用户快捷跳转到ta想去的页面,如购买结束时提供查看订单详情的按钮。

ps:WAP页更加需要画页面跳转的流程图,摸清各个页面的入口,尤其是页面返回的流程;有些简化的返回按钮,可以特殊注明返回到的页面

>>怎样引导用户下载APP?

一、在哪里出现引导?

一般 首页、核心任务的页面(如 电商WAP的商品详情页 、视频WAP的视频观看页)

二、引导下载APP有哪些形式?

1、页面顶部放置下载条    2、页面底部悬浮层引导  3、融合在页面首屏中

4、下载按钮形式    5、底部foot里含: 客户端下载入口

下载APP引导

其次,在设计WAP版上,有以下小技巧可以参考:

1、从页面布局上减少跳转:使用交互技巧隐藏文字(eg 腾讯视频)

利用展开收起按钮 减少页面跳转

2、取消float浮层,增大展示空间(eg:大众点评)

取消float浮层,同时在详情尾部再次加上 “购买”按钮

浮层的转换处理

3、页面中对图片进行缩小(因情况而异)的处理、精简一些标签导航的视觉展现

视觉微调

技术上注意点:

1)各手机浏览器的兼容测试

2)底层服务的调取(能调取,但只有当其是核心功能时才保留 eg:新浪、美团等皆去掉了头像上传功能)

3)注意离线数据存储,减少数据请求频率。

4)考虑保存用户的哪些数据:设置、个人数据、阅读锚点、跳出页面等。

5)避免动效与浏览器的交互冲突

6)按顺序 异步加载  eg: 腾讯视频

腾讯视频 异步加载

扯一下= =:

虽然WAP页目前处于比较尴尬的地位,我们是由于APP中一些页面需要分享出去才开启制作WAP版。

但是不得不承认,基于WAP的轻APP 更新迭代起来更方便,随着H5技术的成熟和发展,也许以后就是基于H5的WAP APP的天下了0.0。r

不懂就问,阴阳师为什么这么火?


二次元手游又炸开了锅。


网易的二次元手游《阴阳师》在9月2日上线App Store之后一路飙升,最高排至畅销榜第7名,App Store评论超5万条,评分高达4.9分。除此之外,“网易阴阳师手游”公众号单篇文章推送的阅读量已超5万,点赞近1500,不管是业界还是玩家,对这款游戏都展现出莫大的热情和关注。曾经波折的二次元市场让游戏厂商精疲力尽,但如今却传来了好消息,手游那点事尝试站在二次元玩家的角度,对网易《阴阳师》手游爆红理由进行解剖,并分析二次元游戏市场的现状。

一、二次元群体是一个怎样的存在?
在谈论二次元游戏之前,有必要先了解清楚二次元用户,这个特殊的群体本身具备哪些属性及习惯,在游戏中更注重哪些元素。
二次元用户群体在不断扩大,泛二次元用户更是成为了主流人群,根据奥飞动漫的数据显示,核心二次元用户在2016年突破8000万,泛二次元用户达到了2亿+的规模。90后和00后是二次元用户的主力人群,90-95的占20.9%,95-00的占57.6%,00后占15.8%,也就是说,90后占据了94.3%的市场份额。二次元这个人群有着明显的调性,鲜明却又很难捉摸。

1.这是个“极度”的领域

Bilibili副总裁张峰的话说就是,二次元用户有着四个极度:极度挑剔;极度宽容;极度沉溺虚拟世界;极度信仰。
对二次元领域的人来说,如果产品得到他们的喜爱,就会无比宽容,会不顾一切地向着它;但如果在最开始就让他们产生厌恶感的话,就会变得极度挑剔,甚至对“无关紧要”的细节都非常苛刻。爱的前提是让用户感受到产品的制作符合或者大部分符合自己的预期,他们才会以常人难以想象的忍耐力忍耐一些问题,比如游戏最让人抓狂的无法开服,不断掉线等。
除此之外,当他们沉浸在一个虚拟世界里,他们对这个世界的认同,为捍卫这个世界他们所做的努力,会远远超过大家的想象。例如在各大渠道上进行游戏的评论,在论坛上进行细节的讨论等,二次元对自己喜爱的东西非常在乎和投入,不仅会在游戏中耗费大量时间资金,甚至会为此“兴师动众”地安利身边的人。

2.依靠自有传播的核心圈子领域圈内圈外
二次元用户的“归属感”很强,心中甚至装着另一个世界,在二次元圈子里,他们有强烈的优越感,活跃地探讨交流着每一个爱好和细节;而在圈外,他们有高度的排他性特点,认为别人不懂他们,不理解他们的文化。

在二次元领域中,用户具有强烈的表达欲望,有1%的用户创造内容,9%的用户传播内容,90%的用户消耗内容,因此二次元中意见领袖的作用非常重要。二次元圈子中的内容大多数是依靠自有传播,在意见领袖的引导下,逐渐形成议论的爆点。二次元人群是建立在相互高度认同之上的,在认同的过程中已然形成了一个圈子,圈子外的人由于没有接触过圈内人所崇尚的二次元文化,就与其有着较宽的认知沟壑。

 

3.游戏内,二次元玩家到底关注什么?
回归到游戏上,二次元人群在游戏中的焦点与一般的游戏人群相比有所不同。在这些人眼里,他们最看重的依次是人设画风占40%、玩法类型占25%、声优CV占20%和游戏剧情占15%。
国内二次元用户玩游戏的时长较长,属于中重度游戏玩家。若在游戏上增加动漫元素,将用户对二次元的爱在游戏中进行释放,将会有更大的市场空间。而在游戏中,这些玩家对游戏品质、游戏格调、游戏玩法、甚至是一些细节都有苛刻的要求,这给想要吃下这个市场蛋糕的游戏厂商带来不少难题。

二、网易的《阴阳师》为何能打动二次元人群?
在游戏中没有谩骂,没有撕逼,没有太多的广告和付费,玩家们其乐融融地在一起聊天玩耍,这是多么难得,而这也是《阴阳师》打动二次元玩家,使之为其买单的重要原因。深究下去,《阴阳师》主要是从品质、声优、玩法、剧情四个方面来打动二次元玩家的。

 

1.游戏品质:迎合“看脸”人群的需求
二次元玩家对画面、风格、人物形象等感官元素有非常强的执念,因为他们坚定自己独特的喜好,对游戏“颜值”要求高,而这是打动他们的关键因素。与阴阳师本身给人阴暗的感觉不同,《阴阳师》的美术风格定位为唯美、空灵,场景中运用灯笼、樱花、流萤等元素,渲染京都美感,为玩家们展现了一幅平安时代的浮世绘。这种摒弃阴暗选择唯美的画风也赢得了更多玩家的喜欢。
同时,这款游戏在细节上的处理也表达出了游戏的诚意。游戏中的角色比较倾向于在动漫中常见的展现形式,人物多样、服饰华丽、动作神态考究。式神的攻击招式遵循着人物设定,根据角色故事进行安排,如雨女哭泣、雪女冰冻技能;犬神身上的衣领到底应该是左边开还是右边开,都经过文化考究;角色走动时衣袂随风飞、鲤鱼旗三种颜色、阴阳师头上戴着的立乌帽子等细节都描绘得十分到位。

 

2.因声优而“入坑”的玩家不在少数

游戏中全程都由声优演绎,算上每个声优所扮演过的动漫角色,《阴阳师》这次几乎将半个日本动漫主角都搬过来了。日站万人票选的“男性声优人气排行榜2016”榜单中,入榜的泽城美雪、铃木达央、钉宫理惠均有在《阴阳师》手游中演绎主要角色,许多知名声优原本就自带粉丝,故吸引了不少为了收集喜爱的声优所配音的式神的玩家。声优的声线会传递出的性格特征极大丰满了《阴阳师》手游中各种传奇职业与人物。另外,知名配乐家梅林茂为这款游戏制作了49首配乐,不仅涉及BOSS战、剧情场景、过场动画,还为主要角色配置了专属角色音乐。剧情动画是以章节出现,搭配声优念白,在视听的双重感染下,让玩家边玩边有追番的欲望。

 

3.无缝融合多种特色玩法
《阴阳师》在卡牌收集和养成的基础上,加入了回合制战斗模式,这是网易最擅长的玩法。游戏中还加入了百鬼夜行、结界突破、攻打鬼王以及阴阳寮等非常符合平安时代特色的玩法。为了满足二次元用户的社交性,在结界玩法中加入了LBS功能,可以根据玩家的IP或者GPS地址自动将周围的玩家与阴阳寮标注出来,这样二次元玩家在游戏里玩游戏,在游戏外面也可以去建立社交圈。
《阴阳师》还有PVP内容,集中在12:00-13:00和21:00-22:00这两个小时,这样的设定一方面满足了一部分玩家的PVP需求,一方面为了避免与二次元人群出现冲突进行了限制。同时,在战斗中,玩家可以自由的观看战斗内容,自由度非常的高。

4.既是游戏,又能追番,还能弹幕交流?
目前市场上较热门的卡牌游戏和MMORPG剧情展现都不是那么强,但是二次元玩家群体是有非常强的故事诉求的。《阴阳师》总体剧情的文字量就在几十万级别,采用初始内容加升级解锁新情节的方式引导玩家“追番”。
《阴阳师》像是穿插了战斗场面的剧情动画,通过角色对话、过长动画等手段融入剧情。在游戏中每一张都会讲诉一个精彩的故事,如妖怪默默守护在世老伴、妻子桥头望夫、离世化为哭泣雨女的故事等,以妖怪故事贯穿收尾。剧情跌宕起伏的同时又细腻刻画了角色生死别离、爱恨情仇的体悟。为了进一步提升玩家的代入感,在观赏剧情是还能用弹幕开启交流吐槽,这也是二次元用户非常喜欢的追番习惯。

三、抢食者增多,二次元游戏市场并不易攻克

二次元游戏的市场一直存在,但在这么多厂商不断进攻下,依然起色不大。而这一次,网易《阴阳师》的突围似乎让从业者对这一市场又恢复了信心,更加笃定了这一市场的可操作性。成熟的玩法、打动人心的画面与细节、浓厚的交流感与参与感,都让这款游戏与一般的二次元手游有所不同。二次元游戏甚至逐渐变成一个主流的品类。

根据艾瑞发布的《2016年中国二次元手游报告》显示,2016年整个中国二次元手游的市场规模将会达到29.31亿元,2017年将达到41.22亿元。二次元用户游戏付费率达到75%,氪金意愿比较强烈。据统计,在二次元文化周边上,二次元用户每年平均花费超过1700元,消费能力也是可期待的。

动漫IP本身在手游中的使用率和成功率就比较高,而动漫IP中又以二次元风格的最为极致。随着二次元市场的不断被入局、探索和成熟,未来抢食的厂商会越来越多。至少网易在这一领域是有备而来,并且想要拿下巨头地位的。网易最早代理了日本的《乖离性百万亚瑟王》,近期推出的自研产品《阴阳师》和《异次元战姬》,由日本小说正版授权改编的《魔法禁书目录》,代理的《萌王EX》,由花泽香菜参与声优工作的《妖刀少女异闻录》等等,大规模的投入彰显了网易对这一领域的信心。

根据Bilibili调查显示,目前二次元游戏大多存在三个缺点:调性不足(画面创新不足),技术不足,用户运营思路和营销思路还是没了解二次元用户。IP可以说是二次元游戏的必杀技,二次元玩家对IP的依赖程度比较高,因为对IP的认可而进到游戏中的不在少数。

除了游戏本身之外,二次元的营销也是一大难题。一般的游戏营销的打法在二次元手游上并不奏效,渠道的选择、广告的投放、素材的方向等都需要重新细细琢磨。不少二次元厂商在推广过程中想展现自己的诚意,常常刻意去营造“二次元”的氛围,宣扬二次元元素,反倒容易用力过猛,弄巧成拙。


迷之二次元~~~