无题

对于低频服务来说,价格是个很重要的因素,因为总有些人会因为那几百块钱转而选择其他家——但这里有一个前提是:价格是影响用户决策的唯一因素,但事实便是价格显然并非唯一因素,因为如果可以多花些钱享受到更好的服务,那么相信价格的影响并没那么大。只有当你其他方面乏善可陈的时候,用户才会在价格这个问题上反复纠缠。

而对于服务质量,我们所面临的问题是,服务的质量随着订单量是成正比还是反比增长,如果是正比,说明基于我们的业务模式能够保证让用户的体验得以保证;如果是反比,那么意味着我们的业务模型上并不足以Cover我们想要达到的服务质量标准。

原因何在?是人的因素还是说供应商的因素还是说有其他影响因素?很可能我们并没有拿到真正的答案,这也就意味着我们在相当长的一段决策时间里面是抓瞎的,干着自以为重要的事情却不足以改善提升我们的服务质量。

今天关于小米的这一则报道《小米首次闭门会议,雷军说已跌到谷底的小米即将反弹了》举了Costco的例子, 雷军总结了其商业模式上成功的4点:

第一,精选商品,只卖4000个SKU。

第二,要有惊喜。

第三,互联网金融。

第四,服务员很少。

单单来看,好像并没有什么了不起的,但实际上能够15年坚持克制自己,这其实非常难得。我们常常说创业的过程中,要聚焦要专注,这样的道理并非创始人不清楚,而是这样的坑注定难以跳过,区别在于在同样的时间里面,比拼的是谁能最快意识到问题并从坑里面爬出来——这意味着创始人or创始团队内部有没有这样的反省机制来促使自己去回顾过往的决策上犯了错误,并需要及时作出调整。

回到文中开头讨论到的话题,我在想,承认我们犯了错误其实并不可怕,可怕的是明明是决策层面犯得错误,我们没有意识到,反而将错误归结为是人员执行不到位——这很容易招致2个结果:一是对于团队士气的伤害;二是错误仍在继续得不到纠正。

在创业这条道路上,团队的调整在所难免,不管是因为什么理由,创始团队从长远出发的决策思路肯定是公司的生存,因为的确公司的存活才是其他可能性的前提条件。但我们其实也有责任从一开始就避免这种情况的出现而非事后的措施:

1)当前的岗位是否急需新招一个人来Cover;

2)对于新招聘进来的人,其工作职责是否明确;

3)其岗位与现有岗位存在交叉部分,怎么来界定。

有许多诸如此类的问题,看着很小,但一段时间之后如果不够清晰明确,员工内心必定会有想法,这种想法也必定会反应到工作表现上来,最终为这个结果埋单的只是公司而已。

2C与2B

在互联网这个江湖,2C与2B就跟程序猿们争论哪种语言更好一样,是一个永恒的话题。

最近一个月开始在实践从2C向2B转的路程,其实内心还是蛮兴奋的,毕竟放眼望去,没有多少个业务的复杂性能够超过装修——在越复杂的是业务场景下,一方面对抽象能力具有极高的要求,另一方面对优先级的判断同样不容有失。这二者哪样出了差错,带来的都是后面的极度被动。而这二者对PM或者对研发同学来说都是有极高的锻炼价值,当然前提是看每个人愿意花多少时间来更深层次的思考问题。

从大方向上来看,在装修这个亿万级的市场,虽然目前互联网装修的兴起,有大量的传统中小装修公司遇到了经营上的难题,无论是获客还是施工都是挑战,但在可见的时间内,装修公司并不会马上消失掉,而是在默默寻找属于自己突破的方向,而这个方向如果仅仅依靠自身的力量其实是难以跟这个市场上的大玩家来PK的,市场需要有这么个角色来为他们的转型提供支撑。纯粹的流量型平台土巴兔也好,房天下也好,目前的焦点都还在获客端的改造上,包括爱空间等等其实也都还是在这个方向上去做突破。但这个其实只是解决前端的问题,对于装修公司来说,仍然面临着施工管理的难题,包括因为施工管理体验糟糕而无形中增加的获客成本。系统与施工能力的整体性输出目前来看会是一个比较好的解决方案。

当然,这个方向也会面临极大问题,对我来说,最大的挑战其实是时间跟速度,快速构建这套系统的体系去推广去接入更多的装修公司是我们必须跨过去的槛。

2C很性感,但容易死得快;2B很苦逼,但是有钱途。

系统的价值

实地感受过才真切的体会到,原来我们做的并不算太差——当然我们还远远达不到很好的要求,也不能因此而沾沾自喜。

只是今天借着给他们做培训的机会,深入的了解对方目前业务操作流程跟我们双方业务对接过程中,才更深刻的意识到系统存在的必要性以及它应该发挥的价值。有太多的事情不是说非得要依靠系统才能完成,但没有系统作为支撑,却是有太多的事情做起来无比费劲,无比痛苦,并且依赖人的因素取得的成果会很可能因为没有系统的规范而很快打回原形。

从这家公司的运营状况来看,这个庞大的市场里仍然有许多类似的公司在挣扎着,规模稍微上去点,施工跟不上,规模小点,对供应链的整合能力又很弱,施工同样是耗费大量精力的事情,也就是说,我们一直坚守的中央调度+管家的施工模型将会是解决这一问题的有效手段,但这个模型其实是对系统能力要求极高。

 

分答

不知道为什么,虽然还没用过这个产品,但是却特别喜欢它的idea。

早期的论坛、博客乃至现在的微博,实际上都在不停的改变人与人的交流方式。

在更早的时候人的活动范围其实是受到极大的限制,人交流的对象无外乎就是身边的人——当然非要纠结起来,书籍其实是个相当伟大的发明,因为它的出现,人类知识经验可以得到了更好的沉淀与传播,人的交流对象开始得以扩散——这种思想的碰撞是尤为必要的,这有助人类的思考与进化。这种交流方式持续了数千年,直到今天仍然在用,只不过书籍本身也已经有了新的表现形式,比如电子书,比如类似Kindle这样的产品。

网络的出现应该说是打破人类持续数千年交流方式的最大因素,因为网络,论坛、IM、博客等等这样产品的出现开始更深刻的影响着人类的交流。这些交流方式本身就是不断的拉近人与人的距离。比如原来,一个普通人怎么可能有机会跟他心中的偶像来说上几句话,即便要实现也是成本极高,比如追星族得到某个机场围追堵截才能看到idol一眼。但是今天,微博实际上大大拉近了这个距离,明星们微博的日常是在过去人们无法想象的接触明星的方式。

而在我看来,改变最大的其实是越来越多的人被这样的平台挖掘出来并且有机会让大家可以看到。知乎实际上在这方面做的尤其出色。只是这一类产品最终不可避免的要解决盈利的问题,这是所有商业行为必须回归的本质。

在我看来,分答实际上是在往这个方向的探索——用当下时髦的词语来说,是网红的变现,是分享经济的体现。我认为这是极其重要,这也是为什么我在仅是想这个idea就喜欢的原因。

哪天有空,可以好好梳理下类似在行、分答、知乎Live这样的产品。

最后,想说的是,在重业务领域摸爬滚打几年了之后,会发现已经不擅长去思考一个相对纯粹互联网产品的做法了?也许最终会殊途同归?

需求的细节

在找项目管理的一些资料,看到这么一个提问:产品经理在向开发同事提需求时,如何完善需求,让需求细节全面并且清晰? 其中安江泽的一个回答如下:

我们开发真正希望的是产品经理在交代需求时,不要求全面细致,但要重点突出。

其实工程师不仅仅要了解产品的方案的核心设计思路,还要知道工程上取舍的条件。这样我们可以集中精力解决对公司对整个产品有巨大回报的问题,同时在那些次要的功能点上做变通。

而面对那些重点不突出的需求,越是交代得细致,我们越是反感。因为不知道你真正想解决的问题是什么,我们就不知道一处设定是你重点关注的还是随便拍脑袋的,那我们肯定要到处挑刺啦。

此外,如果一个名产品经理知道自己方案的核心要点,也是不会为一些次要的细节被挑刺而乱了阵脚的。只要底线没被触及,完全可以让开发有些发挥的余地,降低下整体的成本呀。相反,越是不知道底线在哪的 PM,面对开发的反馈越敏感,越怕自己的方案有一点的变化。

所谓一流产品讲故事,二流产品列单子,三流产品哭鼻子,就是这个道理。

之所以贴出来是这段时间关于项目管理、关于需求的细节想了挺多,也许是时候总结了。

产品经理最怕的是落到自嗨的境地。