标签归档:产品经理

整合比创造更重要

对于一个产品来说,没有错误的功能,只有没应用到正确的场景的功能;

对于一个产品来说,从来就不是一个创造性的功能就能成功的事情。

一款产品,往往是从一个相对创造性的功能开始的,他可能前期依靠这个功能能成长起来,但是,如果不具备整合能力,他所创造的功能就会很快被整合走,最终,产品走向死亡。

微信的整个发展历程,就是一个整合的过程。

语音对讲,附近的人,摇一摇,朋友圈,基本上都是整合来的。

以上这些功能,之前都是某个产品相对单一的功能,单一的功能具备一定的打击力度,但是,不足以支撑其壮大。

经过微信很强力的整合之后,很优雅完美的协作发力,威力大增。

整合,让系统更强大,整合,也让产品更成为一个体系与生态。

我们再看2014年的WWDC,Apple走向更强的整合。

iPod的时候,苹果实现了软件更硬件的第一次整合;之后的Mac、iphone都是这个整合的思路。

而这一次,Apple开始实现跨设备的整合。这种整合让整个苹果的生态体系更完整,更完美。

然后,我们把再放开一点看。之前搜狗的王小川提出「三级火箭」的思路,后来金山的傅盛提出「矩阵」的思路,其实,都是一种整合。

产品内部,通过功能模块的「整合」让产品更强大;企业内部,通过不同产品的「整合」形成更高的壁垒。

整合,不是简单的功能堆砌,而是一种有机的组合。

坊间经常嘲笑说,大部分的产品经理是功能经理,其根本的原因就在于,功能与功能之间不能形成整合。

堆砌,会让产品看上去很臃肿,臃肿且不具备相互作用力,那就不牢固。整合,让产品看上去更协调,协调且相互呼应,坚不可摧。

情怀,是一个生活方式

好吧,这是一篇没什么情怀的文章。

同时,在很大程度上,还会引发不少口水。

不过,这不重要。

我不是在乎输赢,我只是想说就说。

昨晚是1年1度的老罗单口相声,我每年都坚持听完老罗的相声,甚至超过了对郭德纲的期待。

最开始,老罗讲关于成功学的,之后,老罗砸冰箱,之后,老罗斗方舟子,之后,老罗讲用户体验,之后,老罗讲手机。

当然,我个人是很敬佩老罗的,这是真心话。这个人的认真,这个人的傲娇,这个人的幽默。

当然,我也是个有自己的价值观怪癖的人,这也是事实。

所以,我还是应了你们,写下一些关于这场单口相声的观后感。

1、我不想讨论锤子手机

手机,是一个整体,要看性能跟体验,更大点说,以及围绕这个手机形成的其他生态。

如果要说手机的体验,应该拿去给那些不认识老罗的人用。

当然,难以物化的东西,也是产品的一部分。

比如,拿出来就是为了装逼,比如,拿出来就是为了一种情怀。

2、老罗是个很乐于挑战与分享的人

他花了很多篇幅去分享他在进入硬件行业之后的研究,比如手机的拍照原理等。

这个,真心的要点赞,乐于分享的人太少了

3、会讲故事,真的很重要

我之前说,会讲故事的人才能做好产品经理;后来,我发现,做品牌就是讲故事。

这个讲故事的能力太重要了,比如我一直就不会讲故事。所以,我不会给团队画饼,也不会给投资人画饼,这一直让我很头疼。

老罗很会讲故事,并且,他很明确他的受众是一群什么样人,他们喜欢什么样的故事。这点太重要了

4、缺乏情怀的年代,很多人愿意为之买单

我的朋友圈里很多人盛赞老罗的认真,盛赞老罗的情怀,并因此购买老罗的手机。

这个逻辑看上去很自然,很顺畅。

从根本上讲,做事情认真,是最基本的属性。不过,奇怪的是,当有人把这个基本属性拎出来说的时候,很多人为之震惊。

因为缺乏,所以更显珍贵;因为有些人更内敛,所以站出来的更显耀眼。

很认真的做了,并且很认真的宣传自己认真做了;很认真的做了,但是坐等用户自己发现。这是2个不一样的境界。

5、老罗简直就是个营销的天才

这个不需赘述。

6、这是粉丝经济的时代。

这个,不需赘述。

7、固执的按照自己的想法做,固执的按照自己的想法活。总是会有人为你鼓掌的,因为,至少,你是独立思考的。

— 总结一下,

这是一个成功的发布会,极具风格的发布会,值得学习的发布会。

老罗收获了对2年前吹的牛逼的兑现;粉丝们收获的是可以用偶像牌手机;评论家们收获了点击量;像你我这样的旁观者,收获了更多的欢乐及欢乐后的思考,更得其所,挺好的。

三十而豪

28块钱,216页,还是算上了封皮之后的,一个晚上读完,直接失眠了。。。已经很久没有遇到读起来这么过瘾的书了!

这本书叫做《MBA教不了你的创富课》,副标题很装逼,叫做「我在30岁之前赚到1000万的经验谈」。作者「老雕」,本名孟醒,江湖人称雕爷。不知道之前是干什么的,但知道他搞了阿芙精油,直接占领了淘宝精油品类,他搞了雕爷牛腩,直接把吃牛腩搞成了个时尚装逼范儿,他又搞了个薛蟠烤串,前几天跟朋友去内测吃了一下,估计又会成为一个装逼地儿。

通俗来说,这是一本讲怎么做生意的书。

序言里说,「三十不豪,四十不富,五十将来寻死路」,这里的豪指的是「豪气」。一个人三十来岁还不思进取,那么到了四十来岁时,人生就只能混吃等死了。我承认,我是被这个序言一下子就吸引住了,然后顺着这种张狂又豪气的文笔一路读下去的。

创富成败的关键,往往不是资金,而是资源。

什么是资源呢?广泛的人脉、拥有的技术、积累的客户,等等都是资源。对于多数年轻人来说,这些资源,基本都不具备。激情是年轻人拥有的唯一的可自我支配的资源。勤奋、悟性、灵感、激情,才是年轻人真正的资源和优势。

在一个人激情仍在的时候去创富,是件多么幸运的事情!

如果你一直有饱满的,能将其他资源进行有效的整合,创富成功的概率将是很大的。 当然,这里有一个很重要的前提,你的创富目标,要设置的合理。也许,我要的不是创富,而是创造有趣的一生。

选个能互补的搭档

这世上,没有神。领导,最重要的是把复杂问题简单化;管理,急需要把简单问题复杂化。互补,很重要。

合伙人之间,开始就要用协议形式确立一个最终仲裁者,这是硬件;合作双方,通过换位思考,妥协让步,从而摆平大部分冲突,这是软件。

挑选合作伙伴时,对方的一个特质非常重要,那就是同理心。简单来说就是两句话,你有多不可替代,站在对方的立场,你该怎么做?

降低决策成本

在创业时,最大的成本消耗,不是来自人力,也不是来自物料,而是来自决策。

草创时宜专制,壮大后宜开明;战略上宜专制,战士上宜开明;发展才是硬道理!

可做、能做与想做

选有成长空间的行业,关键要看增长率。要么想办法提高利润率,要么想办法提高资产周转率。

可做,指的是在法律与道德范围内可以干的事情;能做,是你能力范围能干的事情;想做,是你兴趣所在的事情。选一个三者交汇点的地方,是创业的第一步。

价值链与产业链

看任何企业问题,都首先站在产业链看价值链,然后站在价值链看核心竞争力,站在核心竞争力的高度上,看品牌、营销、成本控制。

你所处在产业链的位置,决定了你是否要做品牌建设;分析了价值链,才知道往哪儿发力。

蓝海战略的最大价值在于「加减乘除」

蓝海战略的企业,是基于对原有市场的顾客进行客户价值的重大突破,就是对原有成本结构的迅速重组。

蓝海战略的一大特征,就是把顾客不是很在意的环节,大刀阔斧的砍掉,或者极力减少。将节省下来的成本,狠狠的砸在目标顾客最能感觉到价值的环节。

成本链与核心竞争链

价值链对应的一定是成本链,每一个客户价值的产生背后,一定是有一个对应的成本。

消费者的消费链对应的是消费者的购买决策过程。了解购买决策的全过程,分析消费者在每个环节所关心的不同问题,并找出最能影响消费者决策的环节,重点出击,突出商品所呈现的价值。

核心竞争链关注的是,我突出什么?我藏拙什么?尤其是,我在打造这个链条时竞争对手是谁?

价值链不同,核心竞争力打造方式也不同,尤其是优势的定义也会不同。

随机应变

创业,往往是眼中看到了A,真干时候成了B,干着干着居然变成了C,结果最终赚到钱的还是靠了D。

创业最大的财富是想象力和第六感,对创业而言,分析太多反而误事,反而靠直觉更能成功,这种直觉,其实也就是「下意识能力」。

品牌建设就是讲故事

品牌建设就是讲故事,讲故事的技巧在于三个字,附着力。随手拿起身边那些你记得起的品牌,是不是每一个都有一个「妖魔化」的故事?

一口气读完,确实很爽,回味悠长。。。

真实的创业过程,琐碎、枯燥、乏味、重复…..所谓「激情燃烧的岁月」,更多是事后的加料回忆。

哦对了,这本书可以在豆瓣找到

spotify是如何设计产品的

:这是一篇翻译的文章。经过翻译者授权,转载与该博客。

原文:How Spotify builds products

翻译:@Omnibingo

产品开发并不简单。事实上,大多数产品开发努力到最后都失败了,并且最常见的失败原因就是开发了错误的产品。

Spotify是一个瑞典的精益创业项目,它同时保持着一个很棒的产品交付记录。他们的产品广为用户和艺术家喜爱,并且像病毒一样传播开来:他们有超过2000万活跃用户,500万付费用户,并且用户数量增速迅猛。举一组数字说明问题,Spotify在美国这样一个已经充斥着不少音频传播软件提供商的海外市场,只用了1年时间,就把付费用户数从0上升至100万。

Spotify的愿景是在任何时候给你带来对的音乐。这意味着它将无限地接入全世界的音乐,并且在Spotify中分享音乐会十分容易;并且音乐被分享和播放得越多,那么音乐的创作艺术家们就可以获得越多的钱。几年前,Spotify以一个音乐播放器的身份诞生,如今,他们的产品演变成一个发现新音乐和在艺术家和粉丝间建立直连的广袤的平台。

这个产品的设计理念是简单、个性、有趣。甚至连Metallica(美国乐队名),这支长期以来被认为是音乐流服务的死对头的乐队,现在都称Spotify是“目前最好的流服务”并且“被它的方便所震精。”

但仍旧存在一个悖论:就是像Spotify这样成功的公司当然只希望产出人们喜爱的产品,但是只有在产品上线之后,他们才知道人们到底喜不喜欢这个产品。

那么他们是怎么做的呢?

这篇文章的目的就是给Spotify的产品开发方法做一个高度的概括总结。

概要

我们的核心理念是:

  • 我们创造革命性的产品,同时通过早期低成本的原型设计来控制风险。
  • 我们直到品质过关了才会发布产品,即便已经错过了发布日期。
  • 我们通过产品发布后虐心地一次次tweak(可理解为“调整优化”)产品,来确保我们的产品从发布起就表现优异,并且到后来惊艳得令人称奇。

所有主要的产品计划都经历4个阶段–“Think It(思考)”,“Build It(构建)”,“Ship It(发布)”,“Tweak It(优化)”。下方为一个关于从产生灵感到形成产品的整个流,以及过程中的各个阶段会产出什么玩意儿的图示。

Think It.Build It.Ship It.Tweak It

  • Think It(思考) = 整明白我们在打造何种产品,为什么。
  • Build It(构建) = 开发出最小可行性产品(MVP)
  • Ship It(发布) = 将产品向全部用户逐步慢慢铺开,同时进行数据检测并不断改善。
  • Tweak It(优化) = 持续不断地提升产品。这是产品的最终状态,产品不断优化直到生命周期终止或产品重构(= 回到Think It)。

Spotify 拥有超过30个 squads (可理解为“小分队”,下同)和许多不同的产品,为了让公司的其他人都了解公司正在发生什么,我们用一种产品状态图来表示每个产品分别处于哪个阶段。大致如下:

Spotify.Squads

我们同时也面向一些squad试行预测机制,这些squad对产品何时将会到达下一个阶段有一个日期时间上的预期,并对提供的这个阶段晋级日期范围(日期X-日期Y)负责。

为什么是这4个阶段?

构建一个错误的产品是最具风险的事情–错误的产品无法取悦我们的用户,同时无法提升用户数以及用户留存等好的指标。我们称这个后果为“product risk(产品风险)”。

这个4阶模型帮助我们压低风险,并且快速做出产品。下面这个图表可以看出在每个阶段产品风险是如何被降低的,同时可以看到每个阶段是如何地成本密集。

Product Risk

我们可以看到,Think It这个阶段可以以很低的成本降低风险。同时我们也看到我们为什么要尽可能缩短Build It这个阶段(因为它消耗很高的运作成本却几乎无法带来风险的降低)。而在Tweak It阶段逐渐降低的运作成本表明,随着时间推移,产品并不需要进行尽可能多的更新,squad们可以开始继续去做其他事情。

每个阶段的周期变化多端,上面的这个比例只是一个例子而已。总的时间同样也是会变的;有些产品从孵化到产出也就是几个月的事情,而另一些产品可能要花去大半年甚至更多的时间。但是在每个阶段里,产出(即便只是内部的)都是在一个可持续性的基础上完成的。

好,现在我们仔细来研究一下每一个阶段。

Think It

产品灵感在任何时间,在公司的任何人身上都可能诞生出来。大部分灵感都是去提升现有的产品(也就是“tweaks”),这种情况squad们只需自己实施和发布即可。

这里说的“Think It”阶段指的是某人想出了一个全新的产品创意,或者说去重构一个现有产品。

Think It

如果管理者也认为这个想法是值得付诸实践的,那么一个小型的“Think It”squad随即成立。典型的“Think It”squad一般包括一个开发者,一个设计师和一个产品经理。他们的工作就是去完善产品描述,同时构建一个足够吸引人的产品原型。

  • 产品描述通常是一个用来回答如下问题的一个简短的文档:
  • 我们为什么要去构建他?谁会从中受益,如何受益?
  • 我们期望这个产品去提升哪些关键指标?这些指标可能关于播放了多少流音乐,下载量有多少,注册量有多少等等。
  • 我们的预期是怎样的?我们如何去判断这个产品是否成功?
  • 产品会带来“阶段性的改变”(阶段性改变指的是,在预期中这个产品将带来至少双倍的既选指标上的提升)吗?如果在我们的期望中,这个产品只是较小地提高了指标,那么要去构建它,最好有更强有力的理由,比如一些战略方面的原因等。

产品描述不是必备的文档,也不是所谓的项目计划。它不包括特性清单、预算、资源计划等等。它更像是一个用数据说话(数据驱动)的意愿陈述。

产品描述中最重要的部分就是故事性描述。我们要向世界讲什么故事?新闻稿又是什么样的呢?

举个栗子,Spotify的“Discover(发现)”标签是最近的一个产品。介绍一种发现音乐的更好方式。看!你最喜爱的艺术家刚刚分享了一首歌给你。我们让艺术家们和粉丝们从未如此靠近过。喜欢一个艺术家?那就去follow(关注)他,并与朋友们分享你的新发现吧。

另一个例子是有“Radio you can save(你可以保存的电台)”说法的免费移动电台。这种情况下,我们会用谷歌的关键词广告去尝试几种不同的描述,看看哪种描述最吸引人。

关键在于,这个故事性描述在产品构建前就写好了!这样我们可以在产品构建前就确定这个产品足够吸引人。

另外,“Think It”squad会构建许多不同的原型来传递产品的感官上的体验–同时会有“低保真”的纸面原型和“高保真”的可运行的原型(上面跑伪数据源之类)。这时几个内部焦点小组会用来辨别哪一个原型最好地传达了它的产品精神(那个故事性描述),直到我们不断缩小范围,最后只剩下几个胜出的原型。

“Think It”squad

这是一个没有截止日期的迭代过程。只有当我们可以拿出一个足够吸引人的故事性描述和能够传达出它的可运行的原型,这个产品才是值得去构建的。我们无法决定这个产品前期会花去多少时间。

完成的定义:Think It阶段直到管理者和squad共同认同这个产品是值得构建的(或者这个产品永远都不值得构建,故应该被舍弃)则标志完成。

这是一个主观上的决定,它并没有硬数据作支撑。Ship It阶段才会产生硬数据,所以我们希望尽可能快地到达Ship It阶段。

Build It

在这时,Think It squad开始扩张,以组建一个更加长时间存在的squad(有时是好几个squad),这个squad具备开发、测试、发布一个真实产品的所有需要的能力,这个squad会长期负责这个产品,不仅仅是在Build It这个阶段。

Build It阶段的目标是构建一个MVP(Minimum Viable Product,最小可行产品,注释见上文),即一个对于发布给外部用户,传达某些产品理念来说已经足够好的最小可行产品。这个最小可行产品利用一些例如Scrum、Kanban以及eXtreme Programming的敏捷开发方法迭代构建。

Build It

一方面,我们不希望在发布产品前构建一个十分完备的产品,因为这个过程会延迟我们获取数据的时间。在我们把真实的软件发布给真实的用户之前,我们是无法确定我们是否处于正确道路的,所以我们需要尽可能快速到达Ship It阶段。另一方面,我们不希望产出无用的或令人沮丧的产品。人们总是期待Spotify产出优秀的软件,并以此来给我们打分,即便我们说目前软件仅仅是beta版本或alpha版本。

于是squad需要找到可以实现最基本的narrative(故事性产品描述,产品精神),并且可以取悦用户的他们可以做的“最小的可能的玩意儿”。或许形容它的一个更贴切的词是Minimum Loveable Product(最小可爱产品)。自行车对于没有更好的交通工具的人来说是可爱的有用的产品,但是距离它的升级版,摩托车的差距还很大。但我们的确需要实现基本的产品描述,产品精神。否则,我们的判断标准就会被误导:“嘿,我们做出了一个轮子,并且没有人去用它,所以说这个产品是失败的,我们不应该去打造自行车的剩余部分了!”

Think It和Build It阶段的关键不同在于,在Think It中,我们尽可能快,可以走遍各种捷径并且不用担心技术上实现的质量;而在Build It中,我们要写产品级的代码并且需要保障质量。

完成的定义:Build It阶段,直到管理者和squad共同认为目前这个产品已经实现了最基本的产品定义,并且对于开始发布给真实用户已经足够好的时候标志着结束。

面对Moment Of Truth(真理到来的时刻),我们已经准备好了!

Ship It

Ship It阶段的目标是逐渐将产品铺开给所有用户,同时进行数据检测,确保产品在自然环境下,也能够履行它的设计初衷。

Ship It

Squad一开始只将产品发布给全部用户中的一小部分(一般1-5%),以便收集数据。
如何将这些用户的行为,相比于其他的95-99%呢?

还记得吗,我们在Think It阶段定义了一些关于这个产品的预期,现在我们可以最终测试一下这些预期是否依然保持正确,并且对产品进行一些必要的迭代提升。一开始我们应该不太容易一下就做对,在这个模型中花的力气也有不少是不必要的。

当管理者和squad共同认为产品正在小范围的用户群中发挥预期的效果,我们就可以逐渐地在更多的用户中铺开产品,同时仍旧需要做数据监测和产品提升。这可以给我们时间去处理一些业务方面的事物,例如硬盘容量,监测,脚本部署,扩展性等等。

完成的定义:当产品对所有用户都可用时,Ship It阶段完成。

注意一下,这时并不意味着产品已经“feature complete(特性、功能完全)”,完成了Ship It阶段只是意味着产品(最小可行产品+必要的改进)已经被100%铺开而已。其实并没有所谓“feature complete”的说法,因为产品即使在Ship It阶段之后还会持续进化。

Tweak It

这是最为关键的阶段,因为产品们在这里抵达重点(除非在路上他们被抛弃),并且产品在这里花掉它生命周期中的大部分时间。

Tweak It

产品现在已经产出成果,并且对所有用户可用。虽然在某种程度上它已经在Ship It阶段证明了自己,但总还是有很多提高的空间。Squad继续展开实验,在跟踪数据的同时,进行A/B测试以及改善产品,这可以包括重要的新特性也可以是较小的调整。

然而,未来的某一天,squad可能会到达一个产品的收益递减的点。这时产品已经很好,最重要的改进已经完成,并且改进新特性带来的收益率也将不再那么吸引人。转看监测数据,新特性和改进也不见得会带来很大程度的飞跃。

那么这就意味着产品已经趋近于一个“极大值”了。

local maximum

在这个时候squad和管理者就会讨论:我们是不是甘于止步于这座山的山顶,或者去寻找一个更高的巅峰?在前一种情况下,squad可能会逐渐地转移到其他产品的工作上去。在后一种情况下,squad可能会回到“Think It”阶段去考虑重构这个产品或者让这个产品去开拓国际化道路(或者至少是一个更高的山峰…)。

local maximum top

这种情况的一个实例就是spotify.com这个网站。该网站在2012年夏天我们决定去重构它之前已经修修补补了4年。现在这个网站已经在以一种完全不同并且出奇高效地方式来传达Spotify的愿景。

总览图

Think It.Build It.Ship It.Tweak It all

最后的话

希望你能享受这篇文章!

如果模型中的某些部分让你觉得“我去,我已经早就造这些东西了,我们已经酱紫做几十年了好伐”,那么你八成是对的。这个模型所述并不是新玩意儿,屌玩意儿。它只是在讲述那些有用的东西–这玩意儿新老其实并不重要。我发现这种实例的结合还是非常振奋人心充满能量的,我也希望你可以在期中找到在你的环境中也有用的东东。

— 在Twitter上,有位哥们po了一张PPT的图,应该是这个主题的演讲,其中用一个更形象的图总结了什么叫「敏捷开发」,附录如下:

Spotify的敏捷开发

文化的冲突与产品的设计

我很幸运,一直在做的几款产品都是面向我这个年龄段的人的,所以,相对轻松。很多时候,我就拿我自己的喜好去评估用户是否喜欢,基本上就不会出大问题。

不过,我一直在琢磨另外一个问题,为什么有一些产品,外界的评论非常好,用户也很多,但是,我始终融入不进去。

比如,豆瓣的小组。用豆瓣的话说,这是一个能量超级大的产品,通过这个大容量的产品,他们分化出来很多小产品了,但是,我总是融入不进去。

我试图关注了很多很多小组,也在看他们发布的内容,可是我根本不知道怎么回复,我也看不懂他们为什么那么乐此不彼的刷屏刷回复。。。

后来,《小时代》这个电影上线,我去看了这个电影,我觉得电影本身拍的很烂,但是,题材很好,手法也很好,90后的心理抓的超级的准。

果不其然,这部电影在网络上的评价直接就是冰火两重天。说他烂的人觉得狗屎不如,甚至直接动用道德武器,矛头直指郭敬明;说他好的人觉得他很有水准,是个很成功的「产品经理」。

《小时代》及小时代续集的票房大卖,很直观的说明了问题。这是一个符合某一类人群的需求,且非常成功的将他们的心理表达出来的电影。

这2个现象放在一起,我开始明白了,每代人都有自己不同的生活环境,不同的生活环境造就了不同的价值趋向,不同的价值趋向引发了文化的冲突。文化的冲突表现在「产品」上,就引发了不同的好恶评价。

60后这代人是读张爱玲的,70后这代人是听邓丽君的,80后这代人是看杜琪峰的,90后这代人深受郭敬明的影响。。。

在百度风云榜的人群风向标里,抛开极度热点的关键词,不同人群的搜索行为差异很大。这是不同人群需求点的一个很直接的表述。

前几天,小米的副总裁阿黎在极客公园做了一个题为「年轻人在想什么」的演讲。

这个演讲里,阿黎分析了当下年轻人最爱玩的几种产品,暴走漫画、弹幕视频等。从这几种产品入手,阿黎认为「亚文化」是产品经理的必修课。

这种亚文化背后其实是当下年轻人的2种思想的外在表现,个性的表达自我和参与感。

阿黎认为,要做出让年轻人热爱的产品,关键是要到年轻人第一现场去。今天,亚文化群体年轻人很重要的现场,年轻人现在消费的不是简单的功能,不是简单的品牌,他消费的是参与感。

我们应该对未来的主流文化心怀憧憬、保持前瞻发现的激情。因此,亚文化是我们产品经理的必修课。

— 真诚的推荐大家仔细读一下这篇文章,看看这个视频。

文章地址:点击这里

视频地址:点击这里

我们真的需要一个「需求池」吗?

需求池,顾名思义,就是把很多需求放到一起的东西。然后,在规划版本的时候,从池子里捞出几个需求,排一排,搞个版本开发。

当一个产品一旦开始,就会有很多的需求冒出来。很多人自然就想到说,这些需求,先收集起来,然后,等有时间的时候再来排一排,算一算,做什么,怎么做。

这个思路,看上去很自然,也很科学。需求池这个东西,很多产品经理都想搞,很多团队也想用。

不过,我们真的需要这么一个需求池吗?

我认为,实际上,我们完全不需要这个东西。需求池,是一个看上去很美好,实际上意义不大的事情。

首先,任何一个产品,都是变化很快的。不论是市场环境,用户行为,产品演进。

这直接意味着,需求实际上是在不断变动的。就像我之前说的,「需求应该是自然而然的」。

换句话说,这个时间的需求,再过一段时间,已然变化了。

其次,我们一直在说抓重点,做亮点。这句话很好理解,也很好说出来,不过,核心难点在于,怎么判断是不是重点?

我有一个武断且奏效的办法,如果这个功能不能总是在你脑子里留着,这个功能就不是重点。

如果一个功能,这个版本排不上,下个版本的时候你又想不起来,这个功能,肯定不是重点,甚至是,可以放弃的。

这个方法,我一直用,看似很武断,实际上,很好用。

我之前说,不做什么比做什么更重要。很多时候,产品经理的困难在于,从100个功能里只挑3个出来做。

一样的道理,选择越多,选择就越困难,需要从需求开始的时候就筛选,而不是为了筛选去筛选。

当越来越多的工具出现时,你会发现团队使用的工具数量已经快要超过团队成员的数量了,其实我们需要的只是让团队成员之间能够很好的协作和沟通的工具而已。

就像一个朋友说的,「需求池,难道不是用来安慰那些提了需求却没被接受的人吗?」

……

再扩展一个,我们真的需要一个 GTD 产品吗?

设计是一种心态

我在北京租的那间房子是用挂壁燃气的,上面布满了各种按钮,水压调节、温度调节、模式调节….

刚搬进去的时候,对着说明书捣鼓了半天,终于设置好了。后来,每到换季,就又要捣鼓一遍….

在累觉不爱的情况下,我把常用的功能用纸条贴在了上面,以后就对着纸条调节了。

我们每天都会在生活中遇到很多让你感觉很累的设计,不知道是要推还是要拉的门、不知道往左是出热水还是冷水的水龙头、不知道挂个鹿头是男厕所还是女厕所…..

大部分的情况下,我们选择忍气吞声,因为,大多数时候,我们只跟他们交互一次。我们总觉得我们有更重要的事情要做去,所以,我们觉得这点不顺心,过了就算了。

然后,我们认为我们最重要的事情,是去设计我们的产品。我们信誓旦旦的要做一个所谓的体验好的产品。

然而,当我们来设计产品的时候,我们往往又按照我们自己的想法去「设计体验」。最后,当用户来用的时候,就向他面对那个不知道是该推还是拉的门一样….

有个同事负责一个后台系统,做完了让我去测试。

我看了半天,很多设计用的很不爽。我说的不爽,比如,操作完数据之后,要滚到页面的顶部去点提交、那些字段的名称连我这个很懂这个业务的人都不懂什么意思。

我就说,虽然这是个后台的系统,但是,也是给人用的。你要考虑审核的人的感受,你这么玩,明显的会影响工作效率啊。

同事到也明白的快,赶紧说,就把这当成一个系统了,没有考虑到设计和体验什么的。

这事儿让我蛮震惊的。

首先,这是一个后台的系统,他不需要长的很好看。按钮、线条、表单直接用最最原始的就可以了,只要你点击、你填写,他能录入,那就足够完美了。

其次,即使是一个后台系统,也必须有「设计」。这个设计不是说界面多好看,但是,必须操作要流畅,效率要足够高。

这个对设计的要求,跟他是一个后台产品还是一个前台产品,甚至跟他是不是一个产品都没有关系,他应该是一个人行事的基本原则。

这个原则就是,我们不能就那么接受了这个世界的不完美,我们也不能就那么囫囵的任凭这个世界不完美,而你不去做出一些改变。

要成为一个优秀的设计师,一个优秀的产品经理,最起码的一点是,你不能无视这个世界的不完美,即使你不能改变他,但是,至少你要去思考如何改变他。

当你在一扇门面前为难是推还是拉,当你看着一堆按钮的遥控器不知所措,当你不知道到底怎么出热水的时候,你更应该思考的是,如果是我来做,我该怎么做,我可以怎么优化他。这,是一种态度!

你在书本上,你在工作中能学到的,只有术,而你的主动思考,和你的态度才是道。这个道会带领你走的更远,成就伟大!

很多朋友会在各种场合问,我不是科班出生我怎么做产品经理?我刚毕业,我要怎么成长为一个 XX?

你可以通过一些基本的工具,一些基础的教程来了解这个职业是做什么的;

你可以通过一些实际的项目去锻炼基本功,你一窥究竟;

但是,最最最核心的是,你一定要有一颗不把这个当成一份工作,而是一种爱好的心态。

概念性自我锁死

在佛经里,佛常用句式,「佛说 XX,即非 XX,是名 XX」

初读,觉得这不是在玩文字游戏吗,一句话颠来倒去的

细读,觉得在理,这颠来倒去的含义确实不一样

再读,醍醐灌顶

如来所说法,皆不可取、不可说、非法、非非法。
所以者何?一切圣贤,皆以无为法而有差别

如来说,我现在说法,就好比哄孩子,孩子哭了,我拿个落叶哄他,他不哭了,落叶也就该丢了。如果你还继续执念那片落叶,那我就白哄了。

修行也一样,我所说的,只是想让你懂得而所举的一个范例。你光盯着范例,不去理解范例背后的含义,那我就等于白讲了,你也自然学的都是错误的。

最近,常和一些做产品的朋友有私下交流。我发现,他们常常会把自己「概念性的自我锁死」。我举个例子,

一个朋友给我讲需求,说了一堆术语,然后描述了半天,我完全不懂。

我说,你可以考虑使用「用户、场景、任务」的方式来说。比如,我的一个用户,他在什么样场景下,遇到了什么样的问题,针对这个问题,结合我们的产品,我们做了这样的功能来帮助他。

他听完,一拍大腿,吖,这不就是那个,那个,那个故事板吧。我懂,我懂!

我说,那你试着来一遍

他继续开始,生硬的套着故事板的思路来说,磕磕绊绊的完全不得法。

这就是很常见的「概念性自我锁死」,把自己锁死在自己之前听到或者学到的那个概念里了,一心想对着那个概念插入,结果自己很疼….

写个需求文档,非要在前面加上很多的说明,很多的格式说明,实际的内容却很少;画个交互原型,非要把交互的动作搞的非常逼真;做很多事情,都在乎其形式。你把形式看的越重,就把自己锁的越死,自然而然的也就说明自己越是不懂。

不过,实际上这也可以理解。招式最好学,鸠摩智可以用小无相功遮掩,施展少林七十二绝技;咱们也可以照猫画虎的来一个。不过,如果不知其意,练不好内功,最多也就是个上不得战场的水袖功夫。

有的时候,是我们自己太过执着,太注重外在,而恰恰忽略了内在。

如果我们仔细的去想想,发现,其实很多事情又蛮简单,做产品这事儿,简单的就跟做饭没什么两样。只不过是,我们不愿钻进去,好好的看个内在罢了。

整部《金刚经》,佛祖说修行的最难之处在于「无所住」。无所住,就是不要执着,不要执着于佛祖说了什么,要参悟佛祖说这些背后的含义。

用句更直白的话说,你要简单,世界就对你简单。你放下的越多,你就得到的越多。

以上,共勉。

 

那些被大佬带进沟里的名言

每次大佬们出台露面,总会抛出一些武林秘籍来。只可惜,这武林秘籍大多数只有招式概要,很少有拆解详解,加之很少人去仔细研究这招式,所以,很多人就这样走火入魔了。。。

不信,那,我来举几个例子。

要注重用户体验

这个,不细说,你们都懂的。这些许年,用户体验这大棒子一直没有停止过被大佬们挥舞,只可是,到底什么是「你的产品需要的用户体验」?似乎,没有人仔细想过。

要小步快跑

姜文在《让子弹飞》里说,步子不能迈大了,容易扯着蛋。这无疑是对这句话最好的广告。纵观当前的互联网,这句话俨然已经成了圣经。然后,我们就一直跑啊跑啊,从来不顾坚守和经营。

就好比那些朝代里常出现的「旋风将军」,一天之内可以连下数城,所向披靡。但是,这些城池并不分兵把守,也不讲究治理。然后,又旋风般的被人夺了回去。

还有一种,就好比,你遇到一只恶狗,他旋风般的朝你跑来,眼看着就要奔到你眼前了,但是,又瞬间被狗链给绷了回去,你愣在原地,那恶狗则只能低声哀叫….

所以,小步快跑是有前提的。

你在跑的时候就已经要开始思考如何经营,大佬们只告诉你要小步快跑,切没把后面半句也说了,那就是,哪怕再小的功能,都是一个系统性的东西,开发出来永远都很简单,持续运营却是最紧要最困难的!另外,你要在跑之前把栓着你的链子锊一下。不然,要么就是跑到了沟里,要么就是跑的把自己蛋扯了。

要不断试错

这话原本是极对的,这世间原本就没有必然是正确的决定和事情。事实上,我们不管做什么东西,都是在试错。

但是,这试错却也是藏有前提的。那就是,你不能第一把就试的错了,也不能第一把完全就用试试看的心态去搞。

在《三体》里有一个很基本的法则,叫做「黑暗森林」法则。这个法则很朴素,宇宙就是一座黑暗森林,每个文明都是带枪的猎人,像幽灵般潜行于林间,他必须小心,因为林中到处都有与他一样潜行的猎人,如果他发现了别的生命,能做的只有一件事:开枪消灭之。在这片森林中,他人就是永恒的威胁,任何暴露自己存在的生命都将很快被消灭。

于是,很多产品死在了试错的路子上,但是,更多人死在了试错成功的路子上。

要做轻,要小而美

这是伴随着近几年兴起的移动互联网而兴起的另一句圣经。

你会发现,这句话对于一个新创产品非常受用,当你把很多东西抛弃掉,你自然会跑的很快。这就好比,不对在训练的时候,常常要求战士在腿上绑着沙袋跑步,战时脱去沙袋,速度自然很快。

只可惜,木秀于林风必摧之。木若要常青于林,只有1个方式,深扎根!所有的产品必然是走向「重」的。这个重就是说,要有纵深,要楔进去。

另外,不管在互联网的什么行业,做轻只是一个切入方式,伴随而来的必然是各种脏活累活。这种脏活累活的处理能力才是考验你是否可以常青于林的地方。

接地气

什么时候开始流传这句口诀的,已无从考证。约是始于2010年申音那篇撼动中国互联网的「告诉你一个真实的中国互联网:精英与草根」,从此在中国的那帮互联网精英的嘴里,言必称「接地气」,辩必出「小白用户」。

可是,不知道什么时候开始,恶俗开始成为接地气的代名词了。你看,有人的广告动辄湿了、硬了;有人的 APPstore 描述开始写同人小说;有人的移动站首页全部是少儿不宜的风骚图片….

说到这里,有人肯定会回击我一句,你们快捷酒店管家也好不到哪里去!呵呵,我不否认,不过,恶俗与挑逗就在一瞬之间,这根红线值得玩味。

这些年一路走来,开始觉得产品设计这事儿,设计最重要,要优雅要高效。后来才明白,这些设计只是一个很小的因素,最重要的大头儿是价值,是解决问题。价值像是内功,设计像是招数,以内功运招数,威力非比寻常。

再往后来才发现,自己理解的设计还是太窄。产品设计,仅仅界面和体验的设计只是其中一个很小的部分,更重要部分则是运营的设计,于是慢慢意识到要去构建一个产品循环,在产品中融入运营的设计

一个产品的壮大,是很多因素共同作用的,但是,运营绝对是占大头儿的。一个产品,往往起于一个朴素的创意,形成于一个产品形式,但是,必然成功于不断持续的运营。这里的运营不是说做做活动,发发奖品。从产品设计的初期就应该考虑融入运营的因素,在产品上线之后,不断的运营迭代,在产品运行到一定的时间之后,继续运营以保证发展或者调整方向。

扪心自问,有多少产品有始无终,有多少产品起时气势如虹,有多少产品浪费了多少研发的代码。。。

 

如何与设计师一起工作

本文译自Facebook产品设计总监Julie Zhuo 的文章,《How to Work with Designers》

原载:https://medium.com/the-year-of-the-looking-glass/6c975dede146

翻译:http://www.inside.com.tw/2013/08/16/how-to-work-with-designers

多年前,我曾当过产品经理,然后是工程师,而过去七年我从事的是设计工作。每天我都跟担任这些角色的人一起工作,每一天,我对产品开发背后的责任、挑战和艺术都有新的体会。对于想要搞经楚设计这个奇怪、锐利、helvetica-typed 世界的工程师和产品经理们,这篇文章正是为你们而写。

若想使用设计师语言,请停止说那些指标的事,改聊使用者。

其实大多数的情况下,「指标」跟「使用者」意思不会相去太远。举例来说,你或许是希望设定一个目标,让注册页面的转换率提高X%;另一种说法其则是:你想要扫除那些阻止使用者注册、使用产品的障碍。

但是你看,「说法」在这里就变得很重要——让使用者更容易注册vs. 优化注册流程的转换率。前者谈的是对使用者的价值,后者则是公司为了成功所产生的需求。设计师做事的心态一般来说是比较偏向使用者这边。

其他像是:
我可以增加这个按钮的点击率吗?=> 我们如何才能让使用者知道这个贴心的新功能用起来多么简单?

我们希望这个改变不要对指标带来冲击。=> 我们需要确保这个改变不会让使用者有使用上的困难。

来吧,提高病毒散播系数!=> 鼓励喜欢这个功能的使用者跟朋友们分享。

每个设计师都有各自的强项,而这些强项需要用来解决合适的问题

每个设计师都不一样,即便是「全明星等级」的设计师对于问题的思考也不一样,这是因为设计包含:

  • 视觉设计:这一类包含了字体、对比、阶层、「旧的东西看起来好吗?」等。你看对地方了吗?细节是琢磨过的还是马虎的?最重要的是,这个视觉设计是否系统化。
  • 互动设计:使用者要做X的话简单容易吗?导览系统做得好吗?转换和动画会让app用起来更加直觉吗?
  • 产品设计:这个设计有成功地解决问题吗?这个设计好用吗?产品有明确的愿景吗?有带来价值吗?

有些设计师在视觉表现方面技惊四座,但是对互动设计却没什么经验;有些设计师可以做出聪明的产品策略,然而在执行层面就比较弱。每个设计领域都有非常艰深的问题要解决,挑出合适的设计师去解决问题显得非常重要。你不能随便换掉一位设计师,却又期望新的设计师可以在专案上表现得跟前任一样。

一般来说,要做出好的设计,就得面面俱到。如果你只能有一位设计师,那么他最好要是个通才,而非在某方面很强,其他都很差;反之若你有设计师团队,能聚集各领域的高手也许就行得通。

愈是资深的设计师,愈是应该负责解决抽象的问题

为了更进一步说明,我用以下几个等级和对应的职责作为例子:

  • 设计师等级一:设计一个表格让使用者编辑他们的个人档案。这很明确——假设使用者有个人档案要编辑,而解决办法就是按需求设计出一个表格。
  • 设计师等级二:设计一个好的介面让使用者编辑个人档案。解决方案可以是一份表格、一个所见及所得(WYSIWYG)的编辑器,或是一个弹出式视窗。
  • 设计师等级三(广):设计一个编辑个人档案、发表文章、更改设定等等的系统。现在我们谈的就不仅是编辑个人档案,而是具备一定弹性、横跨整个app 运作的编辑系统。
  • 设计师等级三(深):设计一个方法让使用者「想要」更新他们的个人档案。在这里,我们讨论的是,设计师需要自问:为什么使用者应该去更新个人档案?何时更新?如何才能好好地传递这样的请求(请使用者更新个人档案)?
  • 设计师等级四:为app 设计一个可以提高使用者真实性的解决方案,此时「编辑个人档案」说不定根本就不是我们的焦点,或许一个让使用者互相检验(peer-review)的系统会更好。
  • 设计师等级五:要能发掘产品对app/公司/网站而言最大的问题在哪里,并且设计一套解决方案。到了这个最高层次,最顶尖的设计师将能推动一个产品的愿景。

换言之,如果资深设计师对产品的策略及愿景有很深的掌握度,那么他们将会表现出高度的生产力。反之,如果一个资深设计师被指派一个菜鸟等级的任务(例如:设计一个表格),但他打从心就不认为表格会是解决问题的最佳办法,那么他不仅会很不开心,说不定还会表现得很差。陷入这种紧张的状态是影响团队士气的源头:越是资深的设计师,如果不能完全认同产品的愿景或策略,那么他们感受到的挫折便会越深。

设计师花越多时间跟其他的设计师交流,作品也会变得越好(设计师本身也是)

设计师对其他设计师作品提出意见是推动进步的最佳方式之一。如果一个设计师老是独自工作,从未将自己的作品拿出来与同行交流,那么几乎可以保证他们的设计会比定期交流之后的结果差。这也是为何要鼓励设计师在专案开发阶段(设计还不断在更改的时期)多与其他设计师坐在一起工作,并且只在专案的执行阶段才被鼓励与工程师一起工作(当主要设计定案、执行变得更重要的时候)。

设计师为工作付出的努力与价值大多是很难被衡量的

这是因为一个设计师的目标是成就一个高品质的体验——并非仅止于产品的一个面相,而是整个体验,而且要能经得起时间考验。我们就谈谈杂乱(clutter)吧,从质来看,大家通常会认为杂乱是不好的,那么设计上要加东西加到什么程度才会变得「太杂乱」呢?这根本难以量化。同样的,那个刚新增的设计不太可能立即影响使用者,但是慢慢地,像海浪一点一点削去岩壁,东西越加越多,有一天使用者会发现你的网站变得乱七八糟。这时候,就会有其他显得更加清新、简约的app 冒出来解决你的app 所要解决的问题,这时就太迟了。

同样的,设计师常常会推动一个app 或系统不同部分之间的一致性。也许这看起来过于挑剔,因为在功能的层面上如果上传照片的流程一致,这样不就够了吗?

问题是,使用者不是只上传照片。他们也许还会上传影片,如果上传照片跟影片的方式设计得完全不同、两者完全独立,这很容易混淆。使用者上传照片或影片会很痛苦。想像一下,如果电脑的「档案」选项在每个程式的位置都不一样,有的在左上方、在右上方、底部或是任何地方,肯定会是一场恶梦。

的确,有时候设计师对于轻重平衡掌握会失控。设计师会倾向于过度注重个人的经验而轻视整体。同样的,设计师有时候并非产品的目标使用者,却会以自己的个人体验作为指标,决定要把焦点放在哪里。(当然,我在这里讲的东西也未必适用于所有设计师。)然而事实上,因为设计一直在变化,短期内量化指标有涨有跌,难以评估,例如使用者的信任、理解,以及长期的情感和喜悦——都会因为设计师的推动而有正面的影响,然而这却是难以用数字去量化的。

设计师最在乎的,还是细节

真的,想让设计师脸红心跳、浑身飘飘然吗?把每个像素模拟到位,设定一个高标准,不收烂货,为了圆满一个小细节不惜更进一步,或是多花一个晚上去做那些摆明就是要取悦使用者的东西。

每一个我认识的设计师,都非常乐意与尊崇设计价值的产品经理和工程师一起牺牲夜晚和周末,共同努力去成就彼此所信仰、团队中大家都想做的、好用的、一流的、真正更上一层楼的产品。

P.s:在这篇翻译文章的后面,有一条神回复,「I’d like to know more about “How to Work with Designers Under Stupid Boss”.」

设计师,别着急打开设计软件

团队招了一个 UI 设计师,小伙子很年轻,也很勤奋好学。

不过,有个坏毛病,每次拿到需求之后,立刻就打开他的 Photoshop,开始吭哧吭哧的画。这点我非常讨厌和反感,因为,常常的结果就是,他拿他的作品来找我确认,我一看,完全不是需求想要的东西。于是,我就问他,你为什么这么做,你想表达什么?他支支吾吾的说不出所以然来。

我不知道有多少 UI 设计师有跟他一样的坏毛病,拿到需求就着急忙慌的打开 PS 开始捣鼓,而不是先弄清楚这个需求具体是什么样的,自己是如何理解这个需求的,有没有什么不明白的地方,找对方沟通清楚,然后,才是开始去「设计」。

我心目中一个优秀的 UI 设计师应该是这样的工作流程:

1、拿到需求,理解需求

理解需求是要弄明白几点:对方的这个需求具体是什么意思,他做这个背后的目的是什么,要想用户传达什么信息?

2、与需求方核对需求,将自己的疑问表达出来

包括2个部分,表达自己理解的需求,看是否是需求方想要的;对需求有疑问,表达出来,讨论清楚。 (可能会存在你对需求质疑,需求方无法说服你的情况,这属于另一个方面的话题,不展开讨论)

3、核对完需求,开始考虑页面逻辑

页面逻辑,简单说就是针对这个页面要表达的信息的排序与组合。每个页面的重点内容是什么,次要内容是什么,干扰因素是什么?对于重点的内容,应该怎么突出,次要内容怎么展示,干扰因素怎么排除。

页面逻辑凭什么这么处理?根本指导就是对需求的理解。换句话说,如果对需求不理解,页面逻辑就是可能完全是从艺术出发来搞的。当然,我不是说 UI 设计不从艺术出发,但是,不能只从艺术出发,艺术,只是一个次要的因素。

4、根据页面逻辑,选择合适的表现方式

这个时候,是一个脑补素材库的过程。我之前见过哪些表现方式,我们可以尝试什么新的表现方式,版式、颜色、字体等等

5、打开你的软件,开始制作

将这些经过思考的内容画出来,根据实际效果做调整,然后,在制作的过程中跟需求方沟通。

当然,你可能会说,需求方只给了我一点点的时间,我没时间跟他讨论;也也可能说,需求方只是告诉我做这个,然后给我一个例子,让我去抄;你还可能说,我不敢去找老板,那是老板啊。。。

那我只能告诉你,这世界有很多东西,是要靠自己去争取的,虽然现实很荒唐,但是,有些东西,不能丢,因为,你不会一直窝着这些傻逼地方。

 

其实,将以上的 UI 设计师换成产品设计师、运营、程序开发,这个思路依然适用,换句话说,这不是某个职位的问题,而是,一个职业问题!

1、搞清楚做事情的目的,然后再开始做

2、在做事情的过程中,不断跟你的上下游角色沟通

以上2点,是一个是否「职业」的问题,其实,很多人没有。

需求应该是自然而然的

一个产品一旦开始,需求都是自然而然发生的,似乎不需要什么玄幻的调研和推论,一切顺其自然。

有人的地方就有江湖,有用户的地方就有需求。产品一旦开始,用户会告诉你他需要什么。

最开始做快捷酒店管家,我们只是将快捷酒店信息通过移动互联网的方式做了新的呈现,这个产品就这样开始了。

用户告诉我们,我只需要看有房的信息,满房的我看了闹心,这个时候只看有房的需求就出来了;用户告诉我们,打电话的方式还是不够快捷省事,在线预订的需求就出来了;在线预订之后,用户还告诉我们,出差旅游的朋友经常需要我来给他找个酒店,替人订房的需求就出来了;用户发生了多次重复预订,他是我们的老朋友了,自然而然的,我需要给老朋友一些特殊的好处,这个时候,用户体系的需求就出来了。

这一切的推进,没什么规划可言,就是用户在推动着产品往前走。

再比如,很多时候导航设计也是一种自然而然的过程。

一开始,只有几个类目,就全部展示出来,再后来类目多起来,于是就开始对类目进行分类,只展示大类目,再后来,类目更多,就可以考虑分拆成不同的产品了。

当然,有的时候,用户可能推的有点猛,作为产品设计者,帮着纠正个方向就是了。

比如,到底要不要用户点评?这个需求看似很自然,其实不自然。作为一个工具类的应用,去做UGC的事情,对我们是个挑战,对用户来说也是个挑战,他需要的其实是一种对这个酒店的信任度的增强,点评只是个表象,未来,我们会用其他的方式来满足这个需求。

在做快捷酒店管家的过程中,给我的最重要的启发之一就是,产品不是规划出来的。永远不要试图去规划产品,就让他自然而然的发生。这样的产品有更强的生命力。

后续:

1、那老板要规划怎么办呢?

给他一个短期可行的规划,再长远的,给他一个愿景吧。

2、老板让我执行不自然的需求怎么办呢?

跟不靠谱的人在一起,是浪费青春。

“完美情结”是产品经理的敌人

观点:

没有完美情结的产品经理,往往更容易做出成功的产品来。

补充说明:

1、这里的产品,比较偏向于『互联网产品』。因为我只做过互联网产品,其他的领域不知道,也不便说。

2、这里的成功,指的是有较大的用户群,产品被用户认可,且有一定规模的收益。没有收益的产品是可耻的。

下面来完整的解释:

有一个好的点子,离做成一个好产品,相差着一万个对完美的妥协。

产品设计与艺术设计最大的区别就在于,艺术设计在某些程度上是不受任何外界因素的附加影响的。

产品设计则不行,用户的习惯、技术的发展、市场的容量、成本的控制等等无疑都在破坏你早期对产品完美的想法。

而完美的另外一个副产品则是,很容易陷入到细节没完没了的追求。当你深陷细节,就可能很迅速的忘记了全局,最终将产品设计变成了艺术设计。

我举个例子也许更容易理解这个,当你深爱着一个人的时候,其他人在你的眼里都可以被忽略,你的眼中只有他的美好。这种情况跟产品设计中陷入到细节的追逐类似。

那,一个没有完美情节的产品经理应该是什么样子的呢?

1、挑出核心,并牢牢抓住。

一个产品,只有一个核心,不然就容易出问题。这个核心一点确定,所有的功能与运营都应该围绕着他来进行

2、对不影响核心的瑕疵有足够的容忍。

Bug有的时候就像是韭菜,割完一茬还会再长出来一茬。在不断增强核心的道路上,需要对边缘的瑕疵有足够的容忍度。

3、顺手除掉瑕疵

不需要为10%的用户费太多的心思,当然,如果顺手的话,费点心思也无妨。

后续:

1、肯定有人会举乔布斯的例子反驳我

99.9%的人无法成为乔布斯。

在乔布斯的产品设计人生中,我并不认为他有完美情节,他只是有足够挑剔的审美罢了。你用过第一代iphone吗?

2、没有完美情结,不意味着没有审美

没有完美情结不是说产品设计就不追求美了。丑陋的,毫无美感的产品依旧很难成功。

看十六年前的乔布斯访谈

乔布斯访谈

七印部落的同学发出了一段视频翻译,是乔布斯16年前的一段访谈视频,我认真看完,做了一点笔记。

这个访谈的时间是1995年,乔布斯被赶出苹果,创建了Next,之后不久乔布斯重归苹果。

在这个访谈里,乔布斯讲述了他是如何开始进入计算机硬件行业的,是如何做出Mac的,他是如何看待产品、如何看待团队合作的,以及他对IBM当时处境的一些看法。

如何学会管理公司的?

生意场上有很多约定俗成的规定,我称为陈规陋习。因为以前这么做,我们就一直这样做下去。

所以,只要你多提问多思考,脚踏实地工作,你很快就能学会经商,这不是难事。

你的编程经历给你带来什么帮助?

编程可以帮助我们完成工作,它没有明确的实用性。重要的是我们把它看作思考的镜子,学习如何思考。

我认为学习最大的价值在于教会你一种思考方式,一种独特的思考方式。

IBM为什么会走下坡路,Lisa电脑为什么会失败?

公司规模扩大之后,就会变得因循守旧。他们觉得只要遵守流程,就能奇迹般的继续成功。于是开始推行严格的流程制度,很快员工就把遵守流程制度作为工作本身。IBM的员工是世界上最守纪律的,他们恰恰忽略了产品。

经验告诉我,优秀的人才是那些一心想着产品的人,虽然这些人很难管理,但是我愿意跟他们一起工作。光靠流程和制度做不出好产品。

Lisa是一款非常超前的产品,但是它过于超前以至于偏离了产品的宗旨。

什么对产品最重要?

我离开平果之后,发生了一件几乎毁掉平果的事情。sculley有个严重的毛病,跟很多人一样,就是盲目乐观,以为光凭创意就能取得成功。

问题在于,优秀的创意与产品之间隔着巨大的鸿沟。实现创意的过程中,想法会变化,甚至变得面目全非。因为你会发现新东西,思考也更深入,你不得不一次次权衡利弊,做出让步和调整。总有些问题是点子设备解决不了的,是塑料与玻璃无法实现的,或者是工人和机器人做不到的。

设计一款产品,你需要把数千个问题装进脑子里,必须仔细梳理,尝试各种组合,才能获得想要的结果。每天都会发现新问题,也会产生新灵感。这个过程很重要,无论开始有多少绝妙的主意。

那团队合作呢?

就像是一部磨石机。通过团队合作,通过精英们的相互碰撞,通过辩论、对抗、争吵、合作,相互打磨,磨砺彼此的想法,才能打造出美丽的”石头”。

这显然并不是某个人的成就,但是人们喜欢偶像,大家只关注我,但为Mac奋斗的是整个团队。我成功得益于发现了许多才华横溢,不甘平庸的人才。

而且我发现只要召集5个这样的人,他们就会喜欢上彼此合作的感觉,前所未有的感觉。他们会不再愿意与平庸者合作,只招聘一样优秀的人。所以你只要找到几个精英,他们就会自己扩大团队,Mac团队就是这样。

现在的微软是什么状况呢?(1995年的微软)

他们是靠跟IBM合作起家的,并且依靠windows打开了PC市场大门,同时契而不舍的跟进,完全占领。

微软唯一的问题是没品位,完全没有品位可言。只会一味模仿,产品缺少文化和内涵。Mac下字体的灵感来自字体设计和精美的书籍,如果没有Mac,微软永远不会想到这些。

让我难过的不是微软的成功,而是,他们只做三流的产品,他们的产品没有灵魂和魅力,太平庸。更让人难过的是,用户居然毫无感觉。

当然,乔布斯谈到关于团队合作的一些观点,我认为会有误导,所以没有单独列出来。

比如,他认为跟优秀的人合作,不必在乎他们的自尊,因为他们的全部心思都花在了产品上。只要你的观点是对的,他们会立刻改正。

——感谢的分割线——

关于七印部落

七印部落,微博@七印部落 是一群通过网络聚集起来的家伙,他们联合翻译高质量的外文产品材料与书籍,而且翻译的质量非常赞。

关于视频

地址:http://v.youku.com/v_show/id_XNTUxNDY1NDY4.html

别他妈老想着改变世界

今天的主标题『别她妈的老想着改变世界』,副标题『这不科学!』

也许是这个时代太缺乏信仰,也许是这个时代能人太多,所以,现在特别流行说『改变世界』。比如,『活着就是为了改变世界』、『设计改变世界』、『产品经理改变世界』….

仿佛是说,你要做点事情,如果你不跟别人说,『老子这是在改变世界』这他妈的就不像是在做点什么事情一样…..

朋友,这并不科学,你懂吗?

就我所从事的产品设计这个行业而言,能够做的很成功的产品,我从来没听他们这么说过。因为对他们来说,改变世界这个事情太小了,他们要想着如何满足他们的用户,让他们的用户爽,这个事情相对来说更大。

2年前,有个朋友从上海来北京,加入当时只有6个人的MIUI团队,做MIUI的ROM。

当时,他给我介绍他们的半成品,他说,你用android有哪些不爽?我说,1,2,3,4。然后他说,你等着,我们正在改,一定会让你爽!

他们6*12的疯狂专注,他们通过BBS收集用户的意见,他们不断想办法让用户爽。

我经常跟他们抱怨他们的一些地方做的不爽,每次得到的回答都一样,『好,你等着,我们这就改,直到让你爽为止!』

后来,我真的就爽了,妈的,真神奇!比说要改变世界神奇多了!

『改到让你觉得爽为止』,这是我迄今为止听到的,关于产品精神最好的诠释。也是我认为最朴素的产品精神。

注意,不是『我觉得这个很牛逼,你来试试』,而是,『让你觉得爽』。这里,主语不同,决定了做事方式也不同。

对,你会说,在我们心目中的那个神,乔布斯的眼里,从来就是『我做了一个很牛逼的东西』,我们的神说,不要听用户的,因为他们不知道自己要什么。我们只要按照我自己的想法来改变世界就够了。

可是,亲爱的你们,摸摸自己的心口,你真的觉得是这样嘛?你确定这不是一种意淫吗?

朋友,真的,别老想着改变世界,这真的不科学!不如听听用户的想法?不如,试着从小的地方开始试试?

朋友,心越大,世界就越小;口号越响,做的就越少;牛逼吹的越多,死的就越惨!