我为什么从丁香园离职?

首先恭喜丁香园完成了漂亮的C轮,希望老同事们有一天也能享受到高估值带来的红利。

我从2010年4约6日加入丁香园,适逢丁香园完成A轮不久、员工四十人的时期。我的工号是64。
2014年8约26日离开的时候,已经知道了C轮即将敲定腾讯入局的消息,加上一个家控股公司的员工,人数已经达到了300。但我还是选择了「合同到期不续签」。

感谢这几年的经历,让我从一个「生物技术」普通本科毕业生,转型为一个互联网产品经理。就像不后悔当初「转行」加入丁香园一样,现在也不后悔80%的期权被回收的情况下离开。

1、现实的原因

工资的问题,其他离职的前同事都说了。这个情况在过去的一年并没有改观;除此之外,公积金的基数也做了非常好的规避,采用了在「合法范围内」的最低标准;期权不值钱,至少是回购的时候,vested的部分很廉价。

2、理想的原因

和现实相比,我更多的是个理想主义者。只是对现实不满的时候,不足以促使自己离开服务了4年多的「舒适区」。然而,从理想的角度看,也不乐观。

理想中的组织架构应该是以产品为中心,跨终端的和职能的,因为这样能保证团队目标与产品目标的一致性。而即便这一点难做到,至少产品经理也不该被分割为WEB产品经理和移动端产品经理,都在说「全栈工程师」,但我觉得产品经理才是最应该「全栈」的。在将来,所有产品经理都应该「移动产品经理」才对。

理想中的商业模式应该是聚焦的

聚焦分为两种。一种是基于人群的聚焦,一种是基于场景的聚焦。

基于人群的聚焦,就是所谓的「行业垂直」。这种模式的特点就是,人群太小。靠一种服务或者一个产品是吃不饱的。然后就开始做很多产品和服务来满足这群人的尽可能多场景的需求。然后,本质上,这样就不聚焦了。

基于场景的聚焦则是通过一个产品或者一个服务来满足尽可能多的人群,用极大的用户/客户基数用尽量少的产品或服务把企业喂饱。比如360做安全这个场景,腾讯做聊天这个场景。先用一个产品把自己喂饱好之后再去拓展其他的场景。

回到丁香园。丁香园显然属于前者。如这几天丁香园融资后相关新闻稿的所述,丁香园的商业模式微分三部分。

  • 满足医生的工作流中的需求(社交、学习、求职、考试、试剂采购、发文章、自由执业)
  • 为药企(含器械企业)提供营销、数据服务和信息技术服务
  • 为患者提供健康服务

用我自己的话总结,就是3P战略:Physician – Pharmacy – Patient。

这个战略看上去的确很完善很全面。但他不够聚焦呀。且不说,他还要服务医院和生物世纪相关企业。而且随着工作中要做的事情越来越分散,我对「顾此失彼」这个词的感受越来越深。

理想中的变现模式应该是非「客制化」的

基于以上模式,Pharmacy 是丁香园的最大的营收来源。这些客户的特点是什么?

大而有钱(大部分都是跨国药企)。

为这样的企业服务,你要面对很多的同质化竞争,对客户来讲你是属于弱势的。很多营销和数据服务的项目,做的时候都是「客制化」(即客户定制化)而非标准化的服务。

一方面,做这样的项目,你很难享受互联网产品边际成本递减的红利。很多时候,项目就和外包服务差不多。要想更多营收就要做更多项目,做更多的项目就意味着更多的人力投入。而且,外包项目对作为产品经理的人来讲,实在是没有成就感的一件事。

而标准化服务是什么。举个不太恰当的例子,阿里巴巴的诚信通、百度的关键字广告、腾讯的QQ会员都是使用的标准化模式。供应商不需要为某个特定的的客户做定制,因为他们的客户要么是小企业甚至小作坊,要么就是消费者(天生的小客户)。这样企业既可以享受到边际成本递减带来的红利,对产品经理来说,也能够通过优化产品,提升整个平台的营收,满足自己的成就感。

另一方面,在不够聚焦的情况下为大企业服务,和诸多嗅着肉味而来的竞争者竞争。很大程度上,它是一件「销售驱动」的事情。
企业的商业模式

据我的观察,为强势大企业服务又能强势赚钱的企业,一般自己本身也足够大。如果自己本身不够大,还能强势赚钱的,只有律所、财会、券商、管理咨询这些。但前三个都足够聚焦于某一个分工啊。做很多事情还能赚钱的,那就只有管理咨询行业了。

可是你知道吗?我接触到的麦肯锡这类管理咨询公司的人,他们都是牛校牛人(比如普林斯顿的博士),情(商)智(商)双高。试问自己,我就一普通青年,还是服务小客户这种事更适合我。所以我离开了。

「我所说的都是错的」!

祝老东家更加成功!

不做让开发人员讨厌的产品经理

首先,没有人会无端讨厌一个人,除非你身上有让人讨厌的臭毛病。而有些臭毛病,自己是可能不认为很严重。这是由于人类自我认知的障碍造成的,无法避免。不做让开发人员讨厌的产品经理,需要首先弄清开发人员究竟讨厌的是什么?于是,我在知乎上问了一个问题:开发人员最讨厌产品经理的哪些臭毛病?

让人意外的是,这个问题引起了业界很多认识的讨论和关注,并跟风产生了设计师最讨厌产品经理的哪些臭毛病、产品经理最讨厌开发人员的哪些臭毛病、产品经理最讨厌设计师的那些臭毛病等问题。不难推测,在互联网公司,不同角色的人员在共同完成项目的过程中,实现天衣无缝的合作总是很有挑战的事情。

诚然,这些挑战可能是由于参与人员的能力问题,这无可避免。但我更愿意相信,沟通不畅、习惯不佳、缺乏换位思考等因素才是最常见的。知乎上的几个问题的讨论,可能会对各不同角色的人之间进行换位起到一定的帮助作用,无疑,这是一件对各方都有积极意义的事情。

产品经理作为贯通各环节的中心节点,避免一些让人讨厌的臭毛病显得尤为重要。从知乎的回答中,我将这些可能成为臭毛病的行为归纳为以下几种情况:

短时间内可以完全避免的:

需求不清晰,当开发人员问PM需求的时候,发现PM也弄不清楚,这样的问题是一定要杜绝也完全可以杜绝的,如果PM自己都不清楚需求,的考虑这样的工作是否适合自己了。

干预纯技术问题,例如:这个code应该这么写。避免之道:对于纯技术的问题不要干预,如果他的技术实现真的有问题,自有相关的人去负责,产品只需关注他最终是否实现了预期的功能。

交付的方案不确定,开发人员讨厌“其实这样也可以”,“要不就这样吧”的言论,他们需要的是一个明确的方案。在多种方案犹豫不决需要思考的时候,PM最好只是将这样的犹豫不决体现在自己的思考中。除非工程师无力实现你的第一种方案时,再将备选方说出来。

没有必要的预留时间,”这个我们修改一下,明天提交新的版本,一看,列了一大堆增加的功能,并不是仅仅是修改。coder真的不是神,增加的功能是需要测试的。pm给自己留时间同时,可怜可怜攻城湿,留点时间思考吧。”这是一位工程师的原话。Pm要对进度负责,压力很大,但是预留时间是一定要的。

不能完全避免但短期内可以改善的:

需求变更,这是回答中出现平率最高的一个词汇。但是,要让开发人员失望的是,因为种种原因,这个问题并不能完全避免,PM能做的就是尽量在交付开发之前将尽可能多的问题都考虑到,使可能发生改变的需求讲到最少;另外一个就是要杜绝需求的往复性变更,不要让从方案A改为方案B之后觉得不行,又改回方案A。

口交次数太多:要避免口头交代,显然不现实,再完美的文档也无法代替口头上的直接交流。但频繁的口(头)交(流)可能会打断工程师的思路,延缓进度。PM可以做一是尽量完善你的文档,第二个就是尽量在一次口头交流中集中讲完尽可能能多的事情,从而减少次数。

需要长期积累或锻炼才能改善的:

缺乏个人魅力:是的,缺乏个人魅力也成为工程师讨厌PM的一个原因了。但是个人魅力这个东西,确实很难在短期内得到改善。甚至,对于个人魅力的判断,不同的工程师会有不同的标准。

经验不足:或者说资历不深,要改变这样的现状,恐怕也非可立竿见影的。

以上 ,以自勉。