Posted on

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

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

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

引言

项目中存在各种看似「不可调和」的矛盾。 Continue reading 产品经理讲堂 (2) – 项目管理

Posted on

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

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

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

Posted on

计算机思维与用户思维

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

计算机思维

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

用户思维

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

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

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

 

Posted on

电商数据分析要点

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

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

一个原则

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

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

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

* 表单设计原则:有对比的数据表单才有意义。 Continue reading 电商数据分析要点

Posted on

关于企业服务

美国上个世纪前半叶是制造业的时代,因为供应链一致,所以那时候的企业服务是可以通用的。但中国的企业服务市场跟美国相差很大,中国现在最火的是各种服务业,像外卖、移动支付、网购、快递,所以有赞比 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 垂直市场)。

Posted on

微信小程序的生意经

如果要给现在的 App 分类,我大致上会分为几类:

  • 工具型:iOS 自带天气应用、Reeder
  • 媒体型:Medium、好奇心日报
  • 专业型:医疗、科研
  • 商业型:Shopify
  • 服务型:外卖类、滴滴、58 同城
  • 游戏:Candy Crush、阴阳师

而在营收模式上,又分为几类:

  • 收费
  • 内购(IAP):增值服务/订阅服务
  • 广告
  • 服务费
  • 品牌收入

就 App 市场来说,目前更多的是关于功能/服务形态上的微创新,商业本质是不会变,就是「提供」以及「消费」。而现在正成为市场热门话题的「微信小程序」,如果我们要来看它的商业价值,有人把 17 年的机会都押宝在上面,也有更多的人不看好,抱着试水的态度。在看营收模式(Revenue model)前,我们可以先探索目前可能存在的商业模式(Business model)。

小程序商业模式

  • SaaS 平台:小程序自建平台、数据统计服务、资源服务
  • BaaS 平台
  • 既有产品的小程序渠道
  • 小程序「产品化」:在线培训、分享会、线下沙龙,把「小程序」当产品概念在卖

如果把 Software 理解为了一种「解决问题的能力」,那么不管什么 Platform/App/Human Resource,都可以归为 Service。商业受众:企业。

小程序的外壳是一套技术解决方案,所以对于开发者而言,如果能有平台提供「全栈」的技术解决方案,不失为一种双赢的局面。商业受众:企业(开发者所对应的付费主体)、个人开发者。

现在没有看到完全基于小程序的产品出现(不包括那些玩票的个人开发者的小程序应用),更多为现有的产品的渠道拓展,例如大众点评、猫眼电影等。

小程序营收模式

在彻底否定某个想法之前,先尽量验证其各种可能性。回到运营需求:拉新、留存、促活以及变现,商业模式需要有对应的产品以及运营支持。目前小程序的封闭性,使得其在「拉新」这点上不得力。

留存/促活-> 变现。

所以不管上述哪种平台,针对小程序更多需要解决的是「留存/促活」的问题。

Posted on

驱动力与团队管理

驱动力

人的驱动力可以分成三类:

自主型——自我驱动是人的天生动力。那些靠自主驱动的人十分希望得到信任,不喜欢被别人盯着管教。
专精型——主动提升专业能力和职业水平(而不是随工作逐步提高)是关键。这部分人经常会问:“做这份工作如何让我变得更好?”
目的型——找到共同的使命或目标最关键。这部分人由做事的目的驱动,他们经常会问:“为什么我在做这件事情?”

最难得的是围绕目标做事,从中提升自我,从而实现自我价值的人。

在团队管理中,驱动力反映两个问题:

  • 自主性
  • 创造力
  • 成就感

自主性可以理解为责任心这一类的,这是自主型,同时创造力(也可以理解为综合能力)是根基,根基越稳健、成长越快速,这是专精型,而成就感来自对于目标的理解和实现程度,以及团队内外对其的反馈。

团队构成可以简单分为三层:基础层、衔接层、管理层,对于每个级别的员工抱有不同的预期管理。靠个人魅力的管理是无法复用,这意识着当团队成长到 10 人以上,「魅力」已经是无法传达到团队每个人的观念里,毕竟你无法每天都跟 10 个人开会、讨论、决策。从管理经验来看,核心是「心智管理」和「职能管理」。

心智管理

在心理学里,心智表示是一种能够理解自己以及周围人类的心理状态的能力,能力会有高低之分,这也是为什么说不是「人生而平等」,在生物学角度来看都会有身体机能的优劣之分。

心智的成熟度影响到个人的驱动力,我理解的对于「工作」来说必备的心智模型包括:

职能管理

职责与能力匹配,这是确保持久能力和新鲜感的关键,所以我更多关注团队内部员工的个人成长问题。

对员工来说,有自我驱动能力的往往在职业成长规划上做得更好,同时也会反馈给团队内部以及管理者,管理者也有义务去确认员工的自我驱动有正向的反馈。

 

Posted on

我对于微信小程序的看法

微信小程序是什么东西?

自从 1 月 9 号 0 点微信小程序正式上线后,“小程序”便成为风口上的猪,从百度指数我们就可以看到它在泛互联网圈的热度如大火般撩原。

我们看回微信官方对小程序的定义:小程序是一种新的开放能力,开发者可以快速地开发一个小程序。小程序可以在微信内被便捷地获取和传播,同时具有出色的使用体验。

要点在:

  • 开放能力
  • 快速
  • 微信内
  • 使用体验

关于小程序是否为“升级版的 HTML5 ”,对普通用户来说,可以这么理解未尝不可,抛开小程序内在的技术核心,用户体验到的是一个观感上运行得更快的类 App(利益于微信封装好的原生组件,同时第一波的小程序绝大部分使用了跟原生 App 类似的界面,或者使用了 WeUI 设计)

我为什么看好微信小程序

回到前面提及的要点:开放能力、微信内、快速、使用体验,关于小程序的利与弊各方都写得很多剖析的文章,在往前展望前,我们可以先往回看历史的路径。

作为前驱者,百度在 2013 年的百度世界大会上就提出了“轻应用”,之后 QQ 浏览器、UC 浏览器和 360 浏览器也推出了类似的轻应用平台。

LAPP (Light App) 即轻应用是一种无需下载、即搜即用的全功能 App,既有媲美甚至超越native app的用户体验,又具备webapp的可被检索与智能分发的特性,将有效解决优质应用和服务与移动用户需求对接的问题。 – 来自百度百科关于轻应用介绍

特别是号称有过亿用户的 UC 浏览器也无法推进这个形态的产品概念,无论是我们把它叫小程序、应用号还是轻应用,核心理念均是 App + LightApp,借助某个超级 App 的能力,实现给用户的“所见即所得”“所得即可用”,甚至到了张小龙的“即用即走”的状态,同时对于开发者来说一定是要降低开发成本。

微信小程序就是更换了一个 Runtime 的技术方案,我们看回 React Native 、Weex,这些在技术层面都更为成熟,但微信的小程序和之前的“轻应用”、通用技术解决方案又有很大程度上的不同。

解决了入口问题

以往的轻应用,得依赖于特定的“浏览器”,浏览器内的 App Store、搜索、或者通过插件的形式,而微信作为国民级的应用,在盘活“二维码”这种旧时代的互联网表现媒介的同时,在很大程度上也成为了“二维码”的代名词。目前互联网的实质是“内容+服务”,无论是直播、媒体、视频、还是一篇教你做宫爆鸡丁的下厨房的文章,都是内容形态,公众号已成为“内容”存在的暗黑森林,做为平台级现象,公众号已验证了微信力量,而微信希望二维码能连接线上线下的服务。

所以说,微信小程序不是技术产品,而一个“场景化”的解决方案。

什么是场景化?就是满足了用户预期的产品需求,例如在公车站等车时,扫码查看“车来了”小程序,即时了解公交车到了哪些站点。

又例如使用手机的场景已经是日常生活的常态。

微信的市占率+行之有效的线上/下入口(二维码) = 降低绝大部分人的获取成本

最大程度上保证了体验

为什么 Android 机器给很多人的感觉是使用得越久,就变得越卡,事实上也如此,回到官方要点,“开放能力”、“微信内”,这两点保证了在大部分设备中访问小程序的体验都类似,至少不会偏差太多。

这一点保证了小程序的使用“口碑”。

用户终于通过线下二维码,或者某个小程序商店的推荐,再或者某篇文章的介绍,访问了你的小程序(注意不是“添加”,也不是“关注”),得益于微信已预加载了小程序的框架,用户可以更快速得开始使用。

张小龙

很大程度上,张小龙的“创业故事”都在为微信所有产品背书,从 Foxmail 到 QQ 邮箱,再到接管了大部分网民日常生活的超级 App,从微信社交、朋友圈、再到微信公众号,张小龙完全经历了 Web 1.0 到 Web 2.0,再到 Weixin Web World。

开发者、厂商的关注和投入,才是小程序得以发展的关键,也许接下来开发岗位很快就会细分出一个“微信全栈开发者”。

要不要做小程序?

在考虑要不要做小程序,也许我们可以想想哪些场景不应该去考虑小程序,考虑到目前的使用场景及限制。

  • 内容产品
  • 平台型产品
  • 消息流通型产品

结论

我说的都是错的。

Posted on

某些方面

某些方面,自己是个很固执的人。对于不喜欢的人和事,即使迫于应酬,也提不上劲对待。

某些方面,自己是个很念旧的人。更多是因为“过去”能柔和了时光,那些极美好的,再被如放大镜般放开,那些痛苦的,会占更多的空间吧,只是都可以被藏起来。