团队讨论和团队决策

几个观点:

1.团队讨论通常是发散性的,广度有余,深度不足。
如果讨论的是一个比较专业领域的问题,这种广度通常没有帮助,会是低效的。参与讨论的人需要在自己的专业领域内有深入洞察和实操能力,每个参与人的深度决定了整个讨论的理论最大深度,而活跃讨论人的深度决定了讨论的实际最大深度。如果参与的人对[……]

继续阅读

冷启动和内测

互联网产品(尤其是社区产品)不可避免的面临冷启动,找到这个产品的最初用户,将产品交给他们使用,聆听反馈意见。冷启动不是一件容易的事情,在最近的实践中我学习到几点。

1)定义最小可用产品(MVP)并及时地启动内测。在实际中验证产品设想和需求方向。大环境在快速变化、公司部门也在快速变化,时间越往后[……]

继续阅读

见树木也要见森林-产品和项目的缩放

回顾过去的几个“紧大重”(时间紧、压力大、任务重)的产品项目,有两个常见的典型挑战:
1)在这样的项目中你很容易非常忙,用户反馈的缺陷和问题、老板的意见、特性的PK、各种会议和邮件统统向你涌过来,还有各路接口人会经常性地中断你的工作、挤占本就少的可怜的工作时间。一旦被淹没在这些事项中,你可能很辛苦[……]

继续阅读

团队稳定的三角形

有一个问题曾经很困扰我:创业公司如何保持团队的稳定性。这是一个头痛的问题,创业公司规模小名气小、薪资和福利不如大公司、而且工作压力还比较大,经常出现招人困难、留人更难的情况。

随着时间的流逝,现在我对这个问题有了一些新的理解。

在几何中有一个基本定律:三角形稳定性。我慢慢感觉到在团队的稳[……]

继续阅读

问题驱动还是目标驱动?

最近我在思考一个问题:在团队中老是指出问题的那个人,他的这种做法是不是一种负能量,他会不会成为一个不受欢迎的人?

这个问题表面上看起来很简单,其实如果仔细想想问题背后却很有一些道理需要琢磨。

首先我们要看指出问题的人是谁,如果是具体的项目团队成员,并且他日常的工作很努力负责,那么大家会觉[……]

继续阅读

当我们在产品PK时,我们在PK什么?

互联网产品研发团队经常都会有各种产品讨论,大到产品方向、小到界面上几个像素,各种PK不断进行中。我个人是很支持产品PK,也常常喜欢和别人切磋一下。在一个开放的、相互信任的团队里,PK会带来各种想法的碰撞,大家会快速达成共识并把产品做的更好。

PK并非总是那么美好,在产品讨论的时候,也常常会出现[……]

继续阅读

培养、外包还是空降

不管是在大公司,还是在创业小团队,找人才永远是个头痛的难题。当我们想去做一件事/产品时,往往遇到第一个难题是没有人。

这个时候通常有三个方法:
1)把专业部分(例如:美术设计、功能开发等)外包出去,我们拿到结果来运营。但实际上:和外包团队的沟通成本高,交付以后的修改和完善没有办法跟上,也无法[……]

继续阅读

项目经理在“探索”前进中如何发挥作用

—–在下面的阐述中,把项目经理换成产品经理我想也是可以成立的—–

这个讨论主题是我为FY计划的小组练习设定的,在和小组成员碰了两次以后更明确了自己的想法,这里梳理一些要点出来。

*为什么要抛出这个一个主题?
项目经理在互联网公司其实处于尴尬的位置,传统的项目经理是项目负责人[……]

继续阅读

从迭代名称看聚焦

“用迭代的方式小步快跑”,这个话很多人都说过并且会觉得:迭代不是挺简单的么,一个迭代一个迭代的做,需求这个迭代做不完就排到下个迭代去咯。

所以经常看到各种团队需求很多、牛仔很忙,当2个月过去后回过头看,如果你问研发Team:“那个迭代我们做了啥?”。每个人的答案会不太一样:嗯,让

我想想[……]

继续阅读

投入成本与极致的冲突

极致是很多互联网大佬在对外分享中反复提的,极致很美好很酷,却遥不可及。做不到的原因也许在于极致对团队投入的要求上不封顶,而且即使投入了也不一定能做到极致。

对于小团队来说,在做一个新产品时谈极致是不是一件奢侈的事?

这想起来实在很纠结。在现今的互联网环境中如果所做的产品没有特色很难立足生[……]

继续阅读