数据分析讲堂 – 开篇

在开篇前,在想要不要再起这个坑了,毕竟现在一来工作忙,特别是下半年,二来涉及到一些工具的使用,如果想入门学习,真不如直接看官方文档以及教程。

接着在整理下半年自己的个人成长计划时,还是把这块列到 ToDo 里来,抱有以下目的

  • 基础知识的整理,有助于加深对整个知识框架的认识,所以重点不会去讲一些官方文档可以获取到的内容
  • 常见问题的「备忘录」
  • 锻炼文字整理及表达能力

所以整个系列主要是介绍一些基础概念,然后尝试更加体系化去介绍一些数据分析的方法论,通过一些虚拟项目来讲实战分析。 工具方面,主要在使用 Tableau,所以在接下来的系列文章中也会以 Tableau 的使用示例为主,现在只是列一个大体的框架,再逐一拓展。

产品经理讲堂(4)- 需求分析之 Kano 模型

背景

看回 https://en.wikipedia.org/wiki/Kano_model上的介绍:

The Kano model is a theory of product development and customer satisfaction developed in the 1980s by Professor Noriaki Kano, which classifies customer preferences into five categories.

日本教授 Noriaki Kano 在 1984 年首次提出 Kano 模型,Kano 模型分成以下 5 个构成:

  • Must-be Quality(必备因素):当优化此需求,用户满意度不会提升,当不提供此需求,用户满意度会大幅降低;
  • One-dimensional Quality (期望因素或一维因素):当提供此需求,用户满意度会提升,当不提供此需求,用户满意度会降低;
  • Attractive Quality(魅力因素):用户意想不到的,如果不提供此需求,用户满意度不会降低,但当提供此需求,用户满意度会有很大提升;
  • Indifferent Quality (无差异因素):无论提供或不提供此需求,用户满意度都不会有改变,用户根本不在意;
  • Reverse Quality(反向因素):用户根本都没有此需求,提供后用户满意度反而会下降;

继续阅读“产品经理讲堂(4)- 需求分析之 Kano 模型”

产品经理讲堂(3)- 需求管理

我想,谈及「产品经理」时,大家头脑里首先嘣出的一词有可能是「需求」,离开「需求」去谈产品都是在耍流氓。

那么,如何正确定义「需求」,以及在执行层面上如何去管理「需求」?

什么才是「合理的」需求

“如果我最初问消费者他们想要什么,他们应该是会告诉我,‘要一匹更快的马!’”——这是亨利·福特的一句经典名言,也是常用于讨论「需求」时的引子,也就是从表层的需求描述中深度挖掘客户隐性需求。

在产品开发流程中,从产品策划到产品需求阶段,产品经理应该要去作的时候就是去发掘产品策划后真正的产品需求,「我想要一个 xxx 的功能」、「我想在输入一个 xxx,然后输出 xxx」、「我想一个能自动 xxx 的功能」,想必大家常能收集到这样的需求提案,小到想调整一个页面按钮的文案,大至改动整个产品的运作模式。

这是 User story,并不是说这种表达方式不妥,只是需要产品经理去进一步沉淀出来用户想要的东西。 继续阅读“产品经理讲堂(3)- 需求管理”

「智能家居」初体验

米 Boy

为什么要打上一个引号呢?因为我觉得就目前的整体联运性上来看,还没有哪家公司能提供一套完整通用的解决方案。和朋友打趣说,自己已经越来越「米 Boy」了,感觉上「米 Boy」没有以前那种违和感,前些日子和同事聊起小米时,大家都觉得它会是一家「伟大的」公司,回头再说说为什么小米会是家「伟大的」公司。自己买过或者拥有过小米家的:

  • 小米笔记本
  • 小米 4/5
  • 小米路由器
  • 小米摄像机
  • 小米摄影机
  • 小米智能插头
  • 小米排插

最近还买了小米家的「空调伴侣」,准备开始搭建初步的「智能家居」方案。 继续阅读“「智能家居」初体验”

产品经理讲堂 (2) – 项目管理

终于抽出时间,把最近在做的事情系统整理一下。端午假期看了 caoz 写的《你凭什么做好互联网》,推荐在互联网行业工作有段时间的同学看,写得很「口语」通俗化,更像 caoz 个人的随笔记,所以整本书在结构组织上有些「混乱」,但加上「个人化」标签比较明显,所以得带着自己的「场景」去阅读,去理解。

上周在公司内部做了一场关于项目管理的培训,说是「培训」,不如说是一次分享会,把自己在公司这些年的项目实践,项目经验跟大家分享。同时简单整理一下当时的讲义为以下的文字稿。

引言

项目中存在各种看似「不可调和」的矛盾。 继续阅读“产品经理讲堂 (2) – 项目管理”

产品经理讲堂 (1) – 产品经理史

「教练,我也想当产品经理。」

「产品经理」这个职位真得越来越火,其实由来已久,在第二次工业革命前后,新技术以及资源的使用,使得劳动分工变得更细分,工业中心的人口越来越多,这时对于工作职能的需求也更明细,越来越多企业意识到需要有人去跟踪与了解市场需求,以及管理产品(实体)。 继续阅读“产品经理讲堂 (1) – 产品经理史”

计算机思维与用户思维

今日下班时开发的同事问我一个问题:在一些带有分页请求页面如果请求参数不对时,例如访问 http://example.com/?order=34,实际上这个分页只有 12 页,这时应该是返回一个 404 页面,还是有对应的提示,例如返回个「数据已全部加载完,请检查参数」等。

计算机思维

从计算机的状态来看,返回 HTTP 404 倒不为过,因为的确是「在服务器中查找不到对应的资源」,计算机是一个状态机,输入与输出与逻辑判断决定。

用户思维

但从「用户思维」出发,这样处理便觉不妥。计算机是为场景而服务,说直白些就是为使用者(人)服务,「找不到对应的资源」,那么原因在于何处,以及用户下一步应该怎么做?

「解决问题」是「发现问题」的本质。

从这个角度来看,返回一个提示用户操作的页面更为妥当。

 

电商数据分析要点

专业的电商数据分析前提是制定科学合理的分析维度,通过自动化或手动的方式搜集到数据,从而对数据进行针对性的分析,以指导实质业务。

最近在整理公司的电商产品的数据分析工作,纪录一些数据分析的统计要点。

一个原则

电商的本质: GMV = 流量*转化率*客单价

电商是销售,如果要选取一个最关键考核指标,那么会是 GMV (Gross Merchandise Volume),后者三个指标是过程指标,它们的有机组合决定了电商运营策略。

GMV 往往可以通过曲线的方式来呈现,曲线的好处在于可以看到整个变化趋势。为了增加对比性,可以把毛利和 GMV 同时在一个表单里呈现。

* 表单设计原则:有对比的数据表单才有意义。 继续阅读“电商数据分析要点”

关于企业服务

美国上个世纪前半叶是制造业的时代,因为供应链一致,所以那时候的企业服务是可以通用的。但中国的企业服务市场跟美国相差很大,中国现在最火的是各种服务业,像外卖、移动支付、网购、快递,所以有赞比 SAP 更有用;得益于技术的普及,中国的创业团队大都有技术人员背景,很多流程已经内部化,不需要综合性的软件服务。

所以不需要 ERP 了,像国外的邮件 CRM,在微信这个局域网里根本无法联通。进入 Mobile 2.0 时代,IT 服务个人化,因为现在的企业服务完全跑在个人移动设备上,例如今天公司某部门主管问人事部工作总结提交是否支持移动平台提交。

任何使用感受赶不上微信的 IT 系统最后都会被淘汰。

由于中国的人力资源红利逐步消失,美国出现的 Work Market 类似的方式可能更合适中国目前的状态:以企业的业务目标为己任,无情的去掉所有的中间层,在企业达到目标的时候获得扁平收益(订阅式)或者佣金。比如 Uber 和滴滴打车,实际上是为司机提供的一个具备 CRM 功能的 Job Market(评价系统、支付),在满足司机获得收入增长的同时,获得 20% 的抽成;或者像 ZocDoc 一样,为医生带量,但是通过订阅系统收费。这是我们定义的企业服务 3.0:授人与渔平台市场化(1.0 的企业是数据化的公司,比如 IOE;2.0 的企业是云服务;3.0 的企业是 performance-based 垂直市场)。