标题来自《精益创业》，我懒的想，就借用了。

产品上线了，必然的就需要一些指标来衡量这个产品的价值。常见的比如PV、UV、DAU、MAU、ROI等等。这些数字，一定意义上代表了产品的价值，也是里程碑的象征。因此，我们会经常看到各个产品在媒体上爆料自己的数据，以展示自己的实力。

然而，随着这种里程碑意义的被放大，越来越多的虚荣性指标充斥着互联网，充斥着各种产品的宣传。更有甚者，这些虚荣指标成为了产品的KPI，为了达成KPI，更多的手段被使出来，最终加剧了这些指标的虚假。

比如，将使用过跟这个产品相关联的功能的用户全部算入到这个产品的活跃用户中。比如，始终以累计用户来衡量，而没有去掉流失用户等。类似一周内有 10 万个新用户，单月 PV 达到 200 亿，300 万个会员总数，这些数据成为产品热衷于对外PR的指标。

从趋势上看，用户数量肯定是在不断增加的，随着用户数量的增加，注册用户、激活用户肯定也是增加的，所以，这些数字看上去很重要，但其实意义不大。

类似的虚假指标的出现，在很大程度上阻碍了产品的正常发展。除了对外吹个牛逼，对内基本上都是在玩数字游戏，自己骗自己。

每个产品都应该有属于自己的可行指标。这个指标能指引产品的方向、并帮助公司作出更好的决策，这样的指标能带给公司与众不同的竞争力。这样的指标才是每个产品都应该去关注的，而那些虚荣指标，交给PR部门去对外哄哄媒体和竞争对手就可以了。

比如，点评的可行指标可以是点评数量及餐厅图片上传数量；拍照社区的可行指标可以是每天的照片上传数量，一周内回来网站并上传照片的使用者百分比；社区的可行指标可以是最近30天都活跃的用户数量。

漏斗模型是一个比较合适的衡量方式的。通过漏斗的方式，可以很好的知道产品本身的运转情况及产品的业务模型。

比如从获取一个用户到用户最终下单的漏斗中，掐头去尾，计算获取一个用户的成本是多少，用户一单贡献的价值是多少，再计算出来用户重复购买的比率，大概就能知道这个生意是不是划得来。如果划不来，是漏斗出现了问题，还是模式出现了问题？

在快捷酒店管家产品的前期，我们建立了几个漏斗模型，新用户下单漏斗、老用户下单漏斗等，用来调整产品设计，直到这个漏斗趋于稳定。然后引入新的用户进来，不断优化这个漏斗。

我们需要一套可以看出来这个产品是一个可持续的产品的指标，用来衡量这个产品的价值，而不是一个总量的趋势。比如，用户总量是增长的，但是每个新用户所产生的收益是否有提高？在总量中，新老用户的比例如何？

另外，从产品的循环来看，实际上产品的过程就是一个“设定一个假设 – 用数据去验证这个假设 – 调整假设值，继续验证”这样的一个过程。在这个验证的过程中，虚荣性的静态数据并不能有所帮助，而能够揭示产品因果关系的数据更有帮助。

在产品设计的过程中，难免会碰到很多类似的模块设计。早前也许在某个产品中设计过，很想在这个产品中也搬出来用用，典型的比如首次进入的定位、找回密码、注册表单这样的。

但是，最近发现，每次当我有类似这样的念头的时候，做出来的东西总是很不能让自己满意，更会被团队的同学质疑。然后，重新开始设计的时候，放弃之前的想法和思路，会发现有完全不一样的更适合的方案出来。

比如，早前做首次进入的定位模块，会在检测到用户2次进入的时候城市不同的时候弹出提示，让用户决定是否切换。后来做快捷酒店管家，觉得这个设计好傻….干嘛要让用户再选一次，干嘛不直接就给出当前位置附近的东西，这不才是LBS嘛….

过去的经验这个东西，使的好了便是利器，放不下便是自残的凶器。其精髓在于，留下的经验里，是徒有其形还是已得其神！在一次次的同类型模块设计中，留下来的应该是对产品核心的理解，而不是其表现形式。

这似乎就是“重来”的力量。redesign是每个产品设计者每天都应该思考着的问题。

对约定俗成、司空见惯的东西提出疑问并思考是很好的思考方法。如果“质疑-思考”之后还是发现，目前的通用做法最好的，至少你知道为什么了而不是盲从，如果发现约定俗成的做法不见得合理，或许你就可以通过“重新发明”某件东西来获得成功。

后来，听一个同行聊近年很多大公司从互联网业务到移动产品业务的转换之艰难。

我觉得道理类似，对于移动互联网，很多的大公司缺少重来的勇气，始终在尝试“迁移”，用原有的业务经验和产品手法继续在移动互联网上运作。所以，总有那么一点差强人意。

从互联网产品到移动互联网产品，用户的使用场景、用户的使用对象、用户要解决的问题都在改变。这种改变导致产品如果继续用之前的思路来展开，无法胜任了。我们需要做的是，重来，重新从用户、场景、任务、设备四个角度去思考，去观察，去设计。

当然，从互联网到移动互联网的迁移，也会存在对已有利益的损害与博弈，这属于另一个层面的话题，我们只看产品设计的思路。

很多时候，最大的竞争对手总是自己，企业永远都不是被竞争对手打败的，而是被自己弄死的。不要让经验成为包袱，推倒自己，重来一次试试。

—— 以下是微信公号中最近比较有代表性的提问：

问：需求和功能之间的关系是什么呢？

答：口渴了是需求，而喝冰水、喝茶、喝可乐是功能。

问：你对罗永浩的锤子Rom有什么期待？

答：我只期待他更android一些。

问：做互联网产品跟年龄有关系吗？

答：没有。

问：你是不是很爱抽kent烟？还有，你胖不？

答：我只抽硬包红河，抽了8年。70kg，178cm，算胖吗？

这是马占凯提在知乎上的一个问题，属于美团章鱼计划的一部分。划章鱼计划是美团网的产品经理开源培训课程。

上一期“移动产品设计书籍推荐”之后，很多人留言想要我推荐一些关于PM的书。于是，我把这个问题的答案在这里再发一下。

（微信添加 iamkentzhu 为好友，搜索“移动产品设计书籍”可以查看上期的推荐书目）

如果只说三本，针对PM的，那就分别从设计、产品、运营3个方面选吧。3个方面正好也大致覆盖了一个PM的工作。

1、设计相关

《简约至上》，副标题：交互设计四策略

副标题注明是写交互设计的，但，实际上是适用于整个产品设计的。这书核心点就说了一个事情，如何做到，用最少的设计，最优雅的满足用户需求。

至少值得读5遍以上，因为，这些法则看似简单，看似读了就懂，但是，实际上还是会经常犯错。

（有本类似的书《简单法则》，这书有些老了，我是先看了简单法则才知道又出了本简约至上的）

2、产品相关

《启示录》，副标题：打造用户喜爱的产品

这确实是目前最好的关于产品设计的入门书籍了。

曾现场听过Marty Cagan的分享，涉及需求分析、产品设计、团队协作、用户期望管理、产品生命周期等部分，非常的精辟。

3、运营相关

《玩法变了》，副标题：淘宝卖家运营弱品牌时代

这是一个以淘宝卖家为主题与原型写作的，关于产品寄品牌运营的书籍，虽是专注了一个领域，但是可以触类旁通不少关于运营和品牌的知识。如何把产品养大，养好，如何策划一个成功的运营活动，如何去做评估等，我一口气读完的，很爽！

另外，还有几本也值得一读：

《金字塔原理》

金字塔原理是一种重点突出、逻辑清晰、主次分明的逻辑思路、表达方式和规范动作。

这可以帮你很好的梳理思路，将你的观点表达给团队成员。

《应需而变》

这是一本讲同理心的书籍。同理心，就是最近盛传的“要将自己变成傻瓜，然后去设计产品”

《决策与判断》

这本书，我读的时候蛮吃力的，但是确实很值得读。分析用户的心智模型的。

《精益创业》

不要被书名里的创业2个字吓到或者吸引，它其实是一本讲述新产品如何更精益的开发的书籍。其中关于数据指标的量化体系很值得回味。

读书，不再多，有几本能启发思考即可，读书之精髓在于能够打通你的思路，引导你去思考。

读书，不一定非要是专业书。初期也许需要专业书引导入门，之后则可触类旁通了。

标题有点拗口。

首先，简洁并不意味着低劣或不注重装饰。

而是说，装饰要紧密贴近设计本身，任何无关的要素都要剔除。简洁的特征应该源自你所要表现的产品，以及用户所执行的任务。

其次，复杂是一种常态。

互联网，甚至于整个自然界本身就是一种复杂的存在。设计，从某种程度上来说就是要将这种复杂变的“有序”。

“有序”是简洁的一种外在表现形式。

比如，查找到附近的快捷酒店并完成在线预订原本是一件很复杂的事情。包括，如何确定距离最近、如何确定现在确实有房、如何确定不是虚拟预订等等问题。但是，一旦我们把这些条件做一些有序的排列处理，正如快捷酒店管家所做的，预订附近的快捷酒店只需要40秒而已。

第三，谁该面对复杂才是核心问题。

​设计简单的用户体验，不应该问“怎样才能把这个功能设计的更简洁”，而是问“到底应该把这个复杂性放到哪里？”

很显然，创造简单的用户体验，意味着要把复杂性转移到正确的地方，让用户每时每刻都能感受到简洁之美。

同样的，使用快捷酒店管家预订酒店，你要做的就是点击1次app，显示附近的酒店；点击第2次，选中1家酒店；点击第3次，提交订单。然后，去入住。你感受到的是简单快速，我们工程师们面对的则是复杂的程序请求，复杂的房态请求等等。

第四，粗暴化的简洁会让事情更复杂。

砍需求，做更少的功能，做更多的限制，这些看起来会让事情变的简单。

新手引导其实就是一种典型的粗暴化简洁。新手引导试图将一件事情分成几个步骤，达到简单的目的，但是，却让用户失去了控制权，事情变的复杂了….

减法或者加法，简单或者复杂，都不是问题的核心点。核心的问题在于，你面对的是怎样的用户，他所处的是怎样的场景，他要解决怎样的问题。这才是产品设计的终极三问！

最后，推荐大家阅读《简约至上》这本书。这是一本给了我很多启发的书籍，是一本我过一段时间就会重新读一遍的书籍。

关于如何做产品的事情，有无数的讨论，也产生出很多的理论，很多的模型，很多的体系。都挺好的，挺高深，我看了一会就觉得自己内力不济，看不下去了，挺烦闷的。于是，只好捡起《金庸全集》继续又看一遍了。看着看着，觉得心静了不少。

于是，回顾了一下最近见到的和自己犯的一些错误，杂乱的做了一个小总结。没有什么关联，我只信笔而书。

1、产品之要，首在场景感

产品之设计，无外乎3个因素：场景、人物、任务。即，是谁，在什么情况下，有什么问题，而你准备如何帮助他们来解决这个问题？

很多人，没有场景感。不知道他的用户会是谁，会在什么场景下需要他的帮助。还有的人，知道他的用户在什么场景下需要他的帮助，但是，不知道从何入手去帮助。你比如说，最近和流行二维码，看到别人铺，他也铺，但是，看这个支付宝的地铁广告二维码，人与二维码之间隔着铁轨，但是还那么小，怎么扫？还有网易新闻之前在地铁车厢里的二维码广告，二维码的位置在海报的最下方，基本上与看到的乘客的膝盖齐平，要蹲下去扫吗？….

没有场景感，就像是找不到龙，纵有屠龙刀，又有何用？

2、产品之要，次在聚焦纵深

所谓，棍扫一大片，不若枪挑一条线。只有愈深入方能愈得窥真经，方能立足稳当。之后再依次扩展当有可能。

这一点，很多地方，很多高人都做了阐述，不再班门弄斧贻笑大方了。

3、产品之酷在极客范儿

极客是一种行事方式。

微信4.5出语音聊天室，当时我问allen zhang，我说这是解决了之前微信群聊的时候，语音群聊连续播放的那个问题吧？allen说，不完全是。这是一个完全模拟对讲机的功能，基于VOIP技术的，多酷啊！

Apple火爆之时，因为大家都觉得不论Mac还是iPhone都是一个很酷的设备；Facebook发迹之时，因为年轻人觉得这是一个很酷的社交方式；微信成名之时，也是因为大家觉得这是一种很酷的沟通方式。

没有人愿意使用和传播一个不酷的产品！如果做产品，不增加一点酷的元素进去，那，跟咸鱼有什么分别！

4、产品之灵在于幽默感

幽默，是一种“活”的外在表现。是要传达给用户，这个产品是有“人”在做的，是去试图消除“我是在跟冰冷的机器交互”这样的感受的。幽默，是让这个产品看起来有爱，让用户能打破心扉去接受。

在很多产品人多脑子里，充满了理性的思维，到处是严密的逻辑，当然，这些都是非常的有必要的。但是，如果脑子里这些，只有逻辑，只有数据，那这产品人也无异于机器了，机器再去做产品，结果可想而知。

幽默之感，不一定在于主流程中，不一定非要轰轰烈烈。我的观察是，工程师往往比产品人都幽默，但是，工程师这种幽默又往往会被产品给浇灭。再快捷酒店管家的app里，有很多细节的让人看了觉得很欢乐的细节，都是工程师做进去的，倒让我惭愧了一阵子。

产品即产品人之线偶，你是什么样的人，便做出什么样的偶；你使什么样的心思，观众便感受到什么样的戏。爱之，慎之。

最近天干气燥，我是来吐槽的，如果误伤到了谁，那真是，恭喜你了，算是提前给你的新年礼物了！！！

如何做一个充满了干货且蕴含了一种淡淡的装逼范儿的产品经理演讲呢？

当然，超薄的MacBook Air最新款配上Keynote是首选；同时一定要运用多种高清的大图，注不注明图片来源不重要；标题一定要取的夸张，最好要结合最新的网络段子，最不济也要引经据典，一定要让听众第一眼就看不懂；动效很重要，一定要把Keynote里的复杂动效都用上，最不济的也要把PPT的动效运用纯熟喽！

然后，我们来看看要讲哪些内容呢？请一定要熟练记住并活学活用下面的几个句式，如果讲出来不够装逼，那，那，那肯定是你还没修炼到家。

1、“我自己就非常非常喜欢xx” ；

这里面的隐藏了一种淡淡的装逼，那就是，我就是用户。因为我自己非常喜欢这个，所以，我很懂喜欢这个的人也喜欢什么，我一定能把握住他们想的，然后，我从这个出发点出发去做产品。你觉得，这样还不成吗？

但是，你喜欢是你喜欢，你是给你做还是在给你的用户做，这是个问题。

2、“我们认为我们更专业”

这1条跟第一条有异曲同工之妙。因为“专业”这个词，本身就是一个金光闪闪的装逼了，再轻轻的加上一个“更”字，装逼于无形。

但是，多专业才叫专业？不专业的人他也不敢上场打仗啊。

3、“我们要做极致的用户体验”

这个就更牛逼了。你要问，现在整个互联网最差的是什么？答案一定是用户体验啊！你看，这个地方居然还要我登录，你看，那个地方居然不提示。一看就是用户体验太差了，这些做产品的都是吃屎的吧！你看，我们不仅要做，我们还要做到极致！

但是，等等，你理解的用户体验是什么呢？

4、“我们更灵活，迭代更敏捷”

这是一种更超然的装逼了。我们小，所以我们灵活，我们人少，所以我们敏捷。我们才不会一个项目100个设计师来支持呢。你们大公司用那么多人来做，我们就这么几个人也能做，这，就是牛逼啊！

但是，….，嗯，自信是好事！

5、“我们暂时不考虑盈利，只想着做大”

之所以把这句放在最后，确实是因为这是终极装逼的一招了。我们不考虑盈利，看，我们高尚吧；我们只想着做大，做大的另一个含义就是服务好用户，我们是把用户放在第一位的，我们洒脱吧！

但是，不盈利你拿什么做大？你都那么大了还不赚钱，还靠父母接济，你丢人不？

6、欢迎补充

——updata——

切忌不可随意使用的点：

1、不要随便摆数据出来装逼

摆数据出来，看似很高级，但是，往往装逼反被装逼误，最后死的很惨。比如，看了100万张照片，少了177米等等

击中用户的痛点

APP发展时期不同，获得用户洞察的方式也会随之变化。

任何一个成功的APP必然能够击中用户的某一个或几个痛点。帮助孤身一人的旅者、在最短时间内找到陌生城市的落脚之地，这就是“快捷酒店管家”最为核心的诉求，其背后是对现代人天涯孤旅况味的理解和挖掘。再进一步，它抓住的是移动互联时代人们缺失的安全感与日益减弱的计划性。各式智能移动设备使现代人的出行随意轻便，抬腿就走，这一趋势正是“快捷酒店管家”当日预订、当日入住模式的深层支撑。

准确地找到用户痛点，业内主要有两种方式：一种是以竞品分析为代表的数据分析方法，比如搜索引擎公司会设置指标，开展搜索，评估搜索结果，从而对用户需求做出判断；另外一种则是“答案在现场”，开发新产品的团队往往会更多地采用这种方法。我们公司CEO住了上千家快捷酒店；开发团队的成员每人每月都有3次公费入住快捷酒店的机会，亲身体验自己开发的产品是否靠谱；客服人员会通过接听用户电话以及社交网络搜索等方式实时收集用户的反馈；团队成员甚至会在周末去客户的酒店做前台，观察那些拿着手机到前台展示订单的住客究竟是怎样的状态。

发展时期不同，APP获得用户洞察的方式也会随之变化。用户样本量较小的初期多采用现场体验发现的方式，在用户量级达到一定水平后，则可以通过数据挖掘来更好地满足用户需求。比如可以通过分析，帮店长把握其周边客户群体的性质，分析每天有多少人看过他的店，有些人最后没有预订是什么原因等等。未来甚至可以据此探索用户预订酒店方式的改变。

APP不是规划出来的

基本价值定位确定之后，产品的改进、丰满乃至走向，在某种程度上就成为多方力量共同作用的结果。

在某种程度上说，APP产品不是规划出来的。也许听上去不可思议，“快捷酒店管家”永远没有产品规划，甚至不知道2个月之后自己会做什么。举例来说，“在线预订”现在是这个APP的核心功能之一，其实2012年3月产品刚上线时并无这一功能，用户仅能进行电话预订。上线后不少用户反映不爽，因为他们的电话会打到酒店前台，前台再转给400订房专线，因为APP的数据无法传输，400客服还会再问用户在哪儿、住几天、住什么房等信息，整个过程要多花费一两分钟。于是，只需点几个键就能完成整个流程的“在线预订”功能应运而生。

由于用户群体内部存在差异性，产品功能较为显著的调整往往会引发用户的不同反应，此时需要在准确判断主流趋势的基础上拿捏分寸，要渐进柔和地调整，切忌简单粗暴。就拿上面提到的从电话预订转为在线预订来说，其间也经历过“斗争”。一开始我们采用“硬掰”的方式，直接把电话预订的功能隐藏掉了，结果引起不小的反弹，因为有些用户就想打电话。为此我们又进行调整，只是将电话的位置弱化，突出下面的“预订”。

不仅如此，对于像我们这种连接用户与商家的“桥梁式”APP来说，基本价值定位确定之后，产品的改进、丰满乃至走向，某种程度上是多方力量共同作用的结果，需要开发者对相关利益方的需求进行捕捉与平衡。使用早期的“快捷酒店管家”，用户打开地图后能看到所有附近酒店，满房是红色，有房是绿色。用户就提出，我只是想找一间房，为什么把满房的也给我？其实，设为全部显示是为了满足一些店长的要求，他们可以通过APP查看所有酒店的预订情况，与竞争对手进行比较。但更好地满足核心用户的需求才是第一要务，于是我们就添加了一个可选功能，默认“只显示可预订”。

就这样，我们被推着一路前进，用户把“快捷酒店管家”当做预订平台，酒店则把我们当做营销平台，作为第三方的我们努力把桥梁当好。除了通过微博、微信、客服电话、关键词推送等方式对核心用户的需求不断揣摩外，“快捷酒店管家”也渐渐增设了不少体现酒店需求的信息展示功能，如是否有免费wifi，是否有停车场，附近是否有地铁等等，这些都是我们最初做产品时没有想到的。

 优秀APP的三个标准

设计APP产品必须学会放弃，大而全地绑定用户始终是一种诱惑，但当你想要的东西特别多的时候，得到的就会特别少。

一个优秀APP产品往往要具备三方面的特点：一是性能好，通俗讲就是加载速度快；二是用户第一眼就能够找到自己想要的东西，快速有效地解决问题；三是设计有人情味儿，也就是现在很多人常说的“有爱”。

首先，在当前的网络环境下，APP产品的性能好，用户无需等待与忍耐，这是判断一个APP好不好用的重要标准。微信的性能就相当突出，在网络环境很差、很多APP都无法打开的情况下，它还能够使用。但性能并不是一个纯技术层面的问题，也包括策略层面的考虑，开发者需要对速度与效果进行平衡。比如在点击查看微信的消息时，它总是会进入到消息列表，而不是只显示单个消息，此举虽然会牺牲一些速度，却可以使消息的到达率更高。“快捷酒店管家”同样如此，原本打开地图就显示方圆50公里内的酒店，加载速度很慢，后来考虑到用户很少会跑到那么远的地方去住，选择也无需提供那么多，便将搜索直径缩小到10公里，只有再次拖动地图时才会加载其他酒店，速度明显提高。

第二，必须学会放弃。大而全地绑定用户始终是一种诱惑，但当你想要的东西特别多的时候，得到的就会特别少。作为在手机等移动终端上使用的APP来说，简洁是很重要，因为设备屏幕空间有限，用户完成的任务也有限。但如何理解“简洁”？它其实是一种合理的整理。飞机驾驶舱里有无数仪表，你能说它不简洁吗？它必须那么复杂。所以并不是说少和简单就是简洁。APP的简洁应该指核心功能非常突出，不核心的功能可以找到，不需要的功能没有。

在产品设计时要在“用户想要什么”与“你想给什么”之间博弈。用户使用APP就像鱼在池塘中游弋，产品开发者需要通过搭建障碍来引导用户。某些通道的口会留得很宽，那是希望用户经常用的功能；某些口很窄，想通过要困难一些，适用于用户使用较少的功能；有的地方就是雷区，不能让他们过去。比如“快捷酒店管家”打开后的地图主界面默认为定位用户附近的酒店，这正是多数用户需要的；也有用户要找其他城市的酒店，主页面的某个位置会提供搜索按钮，可以切换到相应界面；在预订下单等关键点，就会要求用户必须输入姓名与手机号才能继续，以此保证订单的真实性。

第三，“有爱”是一个好APP的重要特质。APP总要跟用户交互，交互过程应当尽量让人感到愉悦。要做到令人愉悦，就必须认清自己的用户群体，根据他们的特征喜好不断增加细节元素。过去打开“快捷酒店管家”的地图，附近的酒店会一下子显示出来，缺乏特色又十分生硬。后来考虑到我们的核心用户群体是20岁左右的年轻人，他们的QQ皮肤会很花哨，微博模板也个性十足，也就是说，他们追求的是张扬、好玩儿、酷，于是我们将酒店的显示方式改成了从天上哗啦哗啦掉下来的有趣方式。 

 让用户感觉APP是活的

并非所有的用户流失都是不良的，相反，进行用户管理有时候还要故意“逼走”一些用户，“净化”用户队伍。

对于一个APP来说，用户的下载只是万里长征的第一步，下载后的用户流失是必须面对的问题。有研究说，APP产品在下载后三个月内平均会失去76%的用户，维系用户确实是个难题。

用户流失的原因各不相同。一种是3分钟效应，甚至有人说是60秒效应，就是说如果在3分钟之内用户无法找到你的亮点，或者说他急需解决的问题你无法解决，就可能会直接把你删掉，或者无限期打入“冷宫”。这是产品自身的问题，需要做出根本改变。第二种是用户确实在某个特定时段没有需求，比如订酒店就不是日常需求，如果APP因为这种原因被搁置，那就需要通过不断的运营让用户在需要的时候想起你。

APP的运营对于维系用户来说非常重要，业内常说的打榜虽然可能一时有效，但如果后续没有运营也没有意义。如何理解运营？我认为它包括产品运营与市场运营两部分，其本质是建立起产品与用户的关系，而不能仅仅理解为做活动。产品运营的方式很多，信息推送最为常用。在产品中增添好玩的细节、功能也是一种自我运营，比如我们会时常更换有趣的开机界面，圣诞节时将酒店图标变成举小牌子的圣诞老人，目的是让用户感觉你的产品一直有人在用心去做，你的APP是活的而不只是冷冰冰的工具。

维系用户固然重要，但并非所有的用户流失都是不良的，相反，进行用户管理有时候还要故意“逼走”一些用户，“净化”用户队伍。我们的团队有一个原则，即如果一个用户从来不进行搜索、预订等任何活动，他就被视为需要清除的“毒瘤”， 因为他不仅会让用户活跃度等数据变得难看，还会因其无视各类升级要求而增加不同版本的维护成本。“强制升级”是剔除“毒瘤”的方式之一，强制升级时用户打开APP，只有一个“升级”按钮，不升级就进不去。此举自然会因“激怒”用户带来流失，但这种流失是对无形负担的减轻。

此外，恰当管理用户预期也是客户运营的智慧所在。我们拒绝一个人连续给5个人订5间房的用户，尽管这并不违背行业规则，但对于APP产品来说，这种情况会让预订的验证程序变得更加复杂，从而影响其他用户的体验。为了让产品做得更简洁，宁愿牺牲这类用户。面对此类需求，我们会实话说自己做不到，或者请用户多等一段时间，而不是随便答应改变。为用户设置一个合理的期望值，在合理限度内为用户提供尽可能好的使用体验，这也是打造良好用户体验的重要方面。

——

这是跟中欧商业评论的记者聊天的整理，原文发在《中欧商业评论》2013年1月号上，题目是“一个产品经理的用户洞察法则”。感谢罗真美女的耐心整理。

这是一篇和科技博客“雷锋网”的聊天备忘录，简单分享一下快捷酒店管家这款产品的一些设计思路，以及快捷酒店管家团队在运作过程中是如何相互配合的。没有什么建设性的意见，只是一些犯过的错误的总结。

Q:酒店管家产品团队目前都有哪些主要成员，分享一下你们各自的经历吧。

Kentzhu：快捷酒店管家主要成员10个人，清一色的帅哥。

我在拥有中国最好的煤炭专业的辽宁工程技术大学学习，在一个理工类学校学习的经贸专业。上大学的时候发现自己其实对经贸并不是很感兴趣，偶尔接触到互联网，从此沾上极为严重的网瘾，无法自拔，于是，毕业之后直接钻入了互联网。

刚接触互联网的时候，经常会遇到很多功能自己用的很不爽，于是开始思考，如果是我来做，我会怎么做，怎么做才能让自己觉得很爽。之后，开始尝试自己做，在这个过程中一路跌跌撞撞，有一天，一抬头发现，哦，原来自己做的事情是产品经理。

我目前在快捷酒店管家的职位是产品经理，负责快捷酒店管家的整体产品架构与设计，以及客服类的工作，和部分运营的事情。

Q:谈谈你们的团队，如何形成这种扁平化团队的高效沟通合作的（相信绝大多数创业公司做不到你们这种标准），决策过程中如何走流程、解决问题，多给一些我们这样的效率低下土鳖开发者些建议吧。

Kentzhu：这个问题的帽子有点高了，哈哈，因为我们本身就是土鳖的开发者，也还存在很多可提升的空间。

如前面所说，快捷酒店管家的主要团队现在共10个人。其中，1个人整体负责产品，2个客户端研发（iOS、Android），4个服务端研发，1个运营，1个BD，1个CEO。当然，具体视觉设计的事情由公司的设计团队来给予帮助。

在快捷酒店管家，其实没有相对非常明确的分工，在我们决定要做什么事情之后，这个想法的提出者会跟所有人讲一遍，然后，大家给出建议，之后，他就全权把这个事情做了。

比如，我们最近基于微信做的“订酒店”，需求的基本想法来自于我，但是，研发同学在做的时候，增加了比如地图展示、输入数字给出更详细的信息这些更为丰富的功能，都是负责开发这个小产品的研发自己做上去的，非常棒！

再比如，我们的CEO会经常想出很多好玩的运营活动，比如之前我们为了庆祝十八大闭幕，做了一个“普天同庆巨蟹座”的活动，就是我们CEO的主意。然后，我们30分钟出来策划文案，直接就上线发布了。

说起流程什么的，在快捷酒店管家更加的简单粗暴。我们压根没有什么MRD、PRD什么的，只有几张流程图，稍微复杂的写个1，2，3，4说明以下就完了。更多的需求是直接在白板上确定下来的，大家直接在白板上把草图画出来，然后拍照记录一下就开干了，干的过程中如果有疑问再对着白板讨论一下。当然，作为PM，会有一个简单的存档，以便后续回顾与优化修改。

另外，我们每天都会有站立会，大家说一下昨天的工作及一些问题讨论，然后是今天的工作安排，这是一个我们一直坚持的传统。因为团队每个人的工作必须透明，这样各个角色才能最好的配合起来打仗。

在快捷酒店管家，我们比较崇尚的几个东西：一句话需求，用一句话把要做的事情概括出来；简单粗暴，只为90%的用户服务，暂时不考虑10%的用户；一定要让实际执行的人先搞明白为什么做，然后才是开始去做。

Q:为什么想到做快捷酒店管家款产品，做这个产品是想解决什么样的问题？

Kentzhu：做这个产品的想法很简单，我们无法重新发明快捷酒店，但是，我们可以改变人们在手机上预订快捷酒店的方式。

充分的挖掘智能手机自身所具备的特性，重新的去思考用户在移动场景下的需求与痛点，是完成这个想法的核心方式。整个快捷酒店管家的产品试图去解决这样几个问题：在陌生的城市，找不到附近的快捷酒店；找到了快捷酒店，但是不知道怎么过去；随时随地随手订快捷酒店，提升出差的效率与心情。

Q:以什么方式解决这个问题呢？产品的设计理念，产品都有哪些特色，能给我们一些具体例子吗？

为了达到这个目的，整个快捷酒店管家的产品基调是高效、时尚、好玩。这是一个很好玩很高效的快捷酒店预订应用，所以，你会发现我们很多的设计很多的细节都故意做了设计。

比如，我们用全日房/日房来区别2个不同的类型的房间，我们在全日房那里放了一张床，伴随几丝呼噜声；我们在日房那里直接就放了一卷手纸，简单直接。

比如，我们为了减少用户的输入成本，直接采用了地图拖动到什么地方就可以给你展示什么地方的酒店的方式，然后，在地图的正中央放置了一个小人，他就像是一个“准星”一样，很多用户觉得这个设计非常的好玩。比如，为了更纯粹一点，我们把很多不常用的功能，比如个人资料啊，收藏啊，搜索啊什么的，都放到了侧边的“抽屉”里。再比如，在用户的预订流程中，我们整天采用了“机打发票”的拟物化设计，模拟了在酒店前台付款订酒店的形式。再预订成功之后，我们再盖上一个钢印，提示预订成功。

这些都是非常好玩的地方，而且你会发现，这些好玩的地方丝毫不会影响我们的高效，相反的，在给用户一种很好玩的感觉的同时，也让用户记住了我们。

在快捷酒店管家，我们每天都在创新，在不断的体验创新带来的乐趣，看着自己的创新不断被大家接受，被行业接受。比如，最早的时候酒店预订app采用地图展示酒店的时候都只给个价格，我们认为这样很不友好，所以我们展示了酒店品牌、最低价、房态信息，我们看到越来越多的app在采用我们这个形式，行业老大携程的最新版也已经改成这样了。

Q:快捷酒店管家目前都有哪些商业模型，已有的和有构想的都可以跟大家谈谈

Kentzhu：这个商业模型其实也很简单粗暴，如大家都能猜想到的一样，与快捷酒店分成是主要的商业模型。同时，作为一个典型垂直的LBS应用或者说O2O应用，快捷酒店管家在商业模式上与其他O2O应用有同样可思考与扩展的空间。

但是，细节的模式我们没有时间去思考，因为，我们并不认为现在是思考这些的最佳时间。如何继续打磨产品，做更好的体验才是当务之急。

Q:你们有做竞品分析么，自己对行业趋势都有哪些判断？

Kentzhu：关于竞品，或许说出来你会觉得我装逼，但是，实际上，我真的很少关心和关注竞品，也很少去体验竞品。主要有2个原因，最主要的是因为我不希望自己的想法受到竞品的感染。当你看竞品越多，他们的一些想法和做法就会潜移默化的影响你，让你偏移你最初的想法，不经意间就很有可能被别人带到沟里了。另外，快捷酒店管家目前的模式，并没有在国内找到竞品，呵呵。

我不太清楚你这里的“行业”是如何定义的。如果这个行业指的是移动互联网，借用王兴的一句话，所有没有被移动互联网改造的行业，最终，都会被改造。

Q:给其他的开发者一些建议吧

Kentzhu：并没什么有建设性意义的建议，只想说，如果要选择创业，那就别有太多的想法。先问自己，这事好玩不，和这帮人一起玩爽不。如果觉得好玩，大家一起搞点事很爽，那就开始干吧！

当然，如果你一定要我再给个建议的话，那就还是2句话：千万别看任何国内关于创业的报道和专家的微博，当然，也包括我写的这些。千万别把创业当成一个工作，他首先是一种兴趣，其次才是一份工作。

Q:给一张你们团队的集体照吧，我们放在文章里

Kentzhu：现在的快捷酒店管家的开机封面，就是我们团队所有人咯。这也是我们团队文化的一部分，所有的成绩，团队所有人一起分享。

原载：http://www.leiphone.com/s-inn-team.html

阿福说，做社交类产品其实就像是在建国家。我没有那么高的觉悟，对我来说，做产品就像是在设计鱼池，用户则是游弋其中的鱼，运营和产品就像是水流和鱼池的构造，引导着鱼的活动。

设计鱼池，需要这样几个步骤：

了解你要放进鱼池的鱼的习性，我们把这个叫做目标用户定位；

根据鱼的习性，设计一个可以让他们快速成长，直到可以被卖掉的鱼池模型，我们把这个叫做用户价值定位；

设计鱼池，让鱼较为自然的在其中游弋，我们把这个叫做产品体验设计；

不断引入活水，控制水流方向与鱼池的设计一致，我们把这个叫做营销与运营。

我们单独重点来说说，如何设计鱼池。也就是产品体验设计的过程。鱼池的设计概括起来看就3点：

• 核心功能足够突出

在鱼池中，需要有一个足够宽阔的主干道，大部分的鱼都按照规矩游弋其中。当新的鱼进入鱼池的时候，要首先就能感受到这个主干道，然后跟随着鱼群在其中游弋。这个时候，还同时需要水流流向的辅助（运营引导），让新进入的鱼适应水流，适应主干道，最终形成一定的习惯。

这个就是我们在产品设计中经常说到的核心功能足够突出，同时，不断通过运营的方式去引导用户，去形成用户的习惯。一旦用户形成了习惯，很多事情就很简单了。当然，之后，再改变这个习惯也相应的很困难了。

• 非常用功能可以找到

在鱼池中，一定也会有一些稍微窄一点的道路，有一些稍微有“思想”的鱼会找到这个道路，去完成一些非从众性的需求。这个窄道没有必要被放置的非常明显，也没有必要去做运营，当鱼需要的时候，他扭头或者眼睛稍微找一下就能发现了，这，就足够了。

这个就是我们常说的，非常用功能，藏起来，只要他稍微一找就可以发现就足够了。长按一下、拖动一下、点击一个按钮，你需要的东西就呈现出来了，足够了。

• 禁止的功能封堵的足够彻底

在鱼池中，一定不能允许有鱼逆向游弋，因为有水流来保证；也一定不能允许有鱼横着游，因为有篱笆来保证。

这个就是我们常说的，产品需要有取舍，需要有足够彻底的底线。禁止的功能一定要封堵的足够彻底，以保证产品的纯洁性。

当一个鱼池运作一段时间以后，绝大部分的鱼都应该适应了鱼池里水流的方向以及鱼池中设置的篱笆。假如之前搭建的鱼池无法再承受越来越多的鱼进入，那么，需要做的就是改造篱笆或者在旁边新建一个更大的鱼池。这个就是我们常说的改版和开发新产品了。

常常会收到一些邮件，问题类似，就是说自己做互联网有段时间了想转行做产品问是否可以，如果要是转行做产品经理的话需要注意哪些东西，根据当前从事的工作还需要有哪些提高。给我写邮件的朋友描述各自当前的情况各有不同，但是归根结底的问题都类似，所以，我给归类拿出来回复一下。倒不是我懒，也不是其他的，只是觉得存在共性，为了减少重复沟通成本所以总结一下。当然，也欢迎继续深入交流

对于这些问题，我一般分成2个部分来回复

第一个问题是咨询转产品是否可以的问题。我的回答通常都很简单直接，可以，没什么不可以的！如果你想转那就立刻转，没有人天生就会什么，也很少有人能在职业开始的前3年就能准确的找到自己喜欢的且擅长做的事情。所以，喜欢就去尝试，尝试之后就可以知道自己是否合适，是否喜欢去做。如果尝试失败，那也是让自己更清楚自己的一种方式。只要不会因为转行造成生活无法继续或者其他神马原因的，就大胆的去吧，少年！

第二个问题是咨询转行做产品经理的话需要注意什么东西。这个问题的本源其实是想知道什么是产品经理，他做哪些事情。在回答这个问题的时候我会采用问问题的方式来回答，你想转行成为的产品经理是怎样的？你所在的公司目前对产品经理的要求是怎样的？如果真的要开始了，你准备给自己多久的时间来适应和校准？

1、你想成为的产品经理是怎样的？

这是最重要的一个问题，如果你对自己想要成为的角色没有一个概念，那么，后续的事情都无从谈起。所以，我常会先问这个问题，然后捎带上我对产品经理的理解。

产品经理，按照我的理解就是发现用户需求并定义客户价值，准确传递需求与价值给团队成员并达成一致，推动团队成员优雅的满足这个需求并持续的将产品价值传递出去。

这里面分为几个环节：发现用户的需求、定义客户价值、传递需求并提供解决方案、推动实现解决方案、传递产品价值、持续传递产品价值。

发现用户的需求看起来是一个很简单的事情，但是单纯的用户需求也是没有意义的，真正的意义在于这个需求背后隐含的客户价值。说白了就是，你不仅要替人解决问题，更重要的是自己要从中获利。除非你是一个非盈利组织，否则，一切无法盈利的产品都是失败的。

传递需求，提供解决方案，推送方案解决相对被提及的很多，不再赘述。其核心在于设计能力和项目执行力上。

提供了解决方案并不代表事情的结束，在我看来这个事情只是刚刚开始，因为，不为人知的解决方案是毫无价值的。所以，另外一个重要的事情在于产品的运营，如何让用户知道我们帮助他解决了问题是另外一个挑战。

而如何持续的传递产品价值是一个比发现用户需求并定义客户价值更重要的事情，这取决与产品可以走多远，可以维持多久。用户的需求是会随着产品市场等因素的变化而随之变化的，是否能够顺势而为持续跟进不断调整尤为关键。

所以，产品经理是一个相对比较复合化的角色，而且更重要的是，在完成以上工作的时候，你的行政级别上没有任何特权，有的时候甚至需要跟比你高级别的职位斗争。

2、你公司目前的产品经理状态是怎么样的？

你公司目前对产品经理的要求是咋样的，如果你朝着你想像中的产品经理迈步的话，他是否可以给你提供足够的空间呢？如果不能够，那，你是否会因此离开呢？

3、你会给自己多久的时间来适应和学习？

产品这个行当是个吃持久耐力饭的活计，需要不断的学习，坚持不懈的努力。你能给自己多少时间来尝试和学习呢，你能忍受多久这种每天都会有无数并发事件的工作生活，你会乐在其中还是会不久就厌烦倦怠呢。

以上，是我对类似问题的回答，欢迎交流

在产品设计的路上一路走来，经历了几个阶段：初入行时奉很多东西为圭臬，因为然，所以然；之后慢慢深入开始想为什么是这样而不是那样，对已经这样了的产品也少了很多指责，更多的是探究其之所以如此的原因，知其然，知其所以然；再后来是，知其所以然之后不禁叹息，如果努力是否可以做的更好，是否能够解决障碍呢？知其然，使其可以然。

1年前我曾经写了一篇《我理解的产品经理》，当其时深洋洋洒洒数千言以充满理想主义的呐喊居多，也没有什么体系，只是想到哪里就说到哪里，虽说法都无甚错误但是总觉得落不了地….1年之中结结实实的锻炼了许多次，经历一个产品从无到有、从上线后遇到瓶颈然后推翻从来找到一个新的方向。在这个过程中，有团队之间的磨合，也让自己学习到如何成为一个优秀的产品经理。今天写到这里，作为自己的一个成长记录吧。

产品经理的素质，从整体来看应该包括3个方面：对产品市场的感知与把握，称之为市场，占30%；对用户体验的追求与执着，称之为体验，占20%；对团队的驱动与节奏的控制，称之为执行力，占50%。三者合一，有虚有实，不断检验不断改进方能一举破之终有大成！

每个成功的产品都是特定时间段的产物，这个特定的时间段就是产品市场，在这个产品市场下，每个产品都以“独有的价值”作为驱动力。iPod的诞生与伟大就在于正确的把握了当时音乐市场的变化及技术的革新，而iPod自身的设计只是加分项而言，并没有起到核心的作用。一旦产品市场确定，就意味着找到了正确的航线，在这个过程中航道或有偏移，譬如忽左忽右，但只要始终以航线为中心，便不会有太大的问题出现。

一般而言，对产品市场的认知可以通过3个部分来把握，社会与文化的趋势和驱动力、现有经济状况与消费重点的转移、先进的和新兴的技术的出现。

当方向落定并不意味着就能成功，方向与目标始终要落地，体现在产品设计过程中就是对用户体验的极致追求，确保足够优雅的满足用户需求。可以认为产品市场其实是帮助找到用户的痛点，而对体验的执着即是对症下药。这个过程中，如何优雅的满足用户的需求却还是始终要围绕着“独有的价值”来做。优先满足大多数人的需求，之后再为少数人提供解决方案。

但是，产品设计从来就不是一个人的事情，也永远不存在英雄主义。一个产品的成功永远都是一个团队人共同努力的成果，哪怕这个团队再小。所以，上述产品市场与用户体验真正的落脚点其实是执行力，而执行力我认为是最考验一个产品经理道行的所在。如何驱动一个团队的兄弟又快又好的完成产品设计同时把握好节奏不断的快速迭代是一个产品成败之根本。

在这里有几个尤为重要的地方，让产品方向在整个团队得到认同，有计划有节奏的执行产品设计，灵活反应及时应对可能出现的问题与方向上的偏移。如果团队无法对产品方向达成一致必然不会使出全力，但是光有力道但是没有节奏往往会出现撞南墙的情况。

一个完整的产品流程简单来说就是，发现问题——分析问题——解决问题——验证答案的过程。在这个过程中，只懂市场无处着力，看似都瞧的透彻但永远只是看上去很美，多半会成为砖家；光靠体验容易被既得用户牵着鼻子走，往往深陷泥潭，要么成为理论派要么开始自我怀疑；兄弟同心其利断金，但是更多的时候问题不是出在断金上而是何处是金。唯三者合一方能大成。

三个部分看似简单，然每个部分拆开来讲都包含很多学问与技巧，每个部分也都有很多特有的门道在里面。以我当前的经历与能力尚无法领悟其十分之一，尚须继续努力修炼拿项目来磨砺与提高。

以上，为成长笔记，记录如此仅供自省自查。

在最早的时候产品设计大多采用瀑布模型方式做迭代，上一个流程完毕之后才进入到下一个流程。这种模式有一个最大的好处就是下一个流程的准备相对充分，但是缺陷也显而易见，那就是迭代成本太大且显得笨重。随着互联网行业的发展，“快”成了这个行业最重要的一个口诀，于是类似“唯快不破”成为大受追捧的产品设计哲学。于此同时，很多项目的设计周期被缩短。

在这个快字的指导下我们省去了对详细MRD的撰写，采用了列出功能点的方式向研发团队讲述整个产品的逻辑与核心需求点；因为要快速，所以我们采用初略原型的方式直接像工程师展示我们需要的产品架构和页面逻辑；因为要快所以产品人员在描述的时候很激昂的描述了我们要做的高优先级系统，并且说这些系统是我们最至关重要的地方，我们高优先级先把这些重点搞通；研发人员在听完整个的需求描述与初略的原型之后迅速做出评估，给出研发排期，于是群情亢奋的就开始干了……

这一切看上去很美好，不是吗？我们比以前快多了，我们也有突出的重点了。但是事情真的是这样吗？

当大体的排期做完了，需求也通过了。下面研发人员开始做后端的架构和程序逻辑的架构了，产品人员开始对之前的需求做梳理，对原型做细化，设计师也开始尝试视觉风格了。这次我们采用了并行的方式，我们要比之前进步多了吧。

很多时候，事情就是这样奇妙，不梳理不知道一梳理吓一跳。原来当时我们在考虑展示部分的时候没有考虑到不同的用户流导向的页面不一样啊；原来一个简单的数据提交过程有如此多的分叉口并导向不同的后端数据处理策略。产品人员认为，这些都是应该重新归纳出来的，于是之前一个展示页面被细分为N个不同的展示样式；之前的一个提交流程被分拆成M个不一样的处理策略。挨个模块的这么梳理下去之后原来简单的一个原型被弄的好生完美，原来一个看似美好的页面结构被修剪的异常丰满。而之前产品人员认为“比较简单，重点突出”的系统被证明是一个很复杂的很重的系统。当然，这个过程是后端工程师和产品设计师共同梳理完成。

这个时候，问题出现了。按照之前的需求描述和原型讲解研发工程师预估的时间在每个系统上都多出来了一倍多。产品人员在不断的“完善”页面逻辑和产品架构，研发工程师在不断的增加研发成本。最终，当研发周期过去大半的时候我们发现，靠！刚做完第一个阶段…..于是，大家都急了，咋办？！砍功能吧，把低优先级的东西先干掉，先做“核心”的事情。一阵的手忙脚乱之后，还是比预期的晚了几周，上线了一个勉强过的去的版本。

那么，在这个案例中整个产品研发过程的问题出在哪？自我反思，我认为是产品人员造成“细节黑洞时间”过长，导致工程师对研发过于乐观，项目开发周期评估失常。不过，问题的症结还是在于快的过头了，因为快所以忘记了一些虽然笨重但仍旧行之有效的方式。

在需求的初期，产品人员并没有能够很好的将业务逻辑转换成产品逻辑。整个业务的核心链条是什么？用户被什么动力所驱动，这些动力在产品上由什么来体现？围绕这个核心链条哪些是我们必须要做的产品模块？

业务逻辑的转换凌乱必然导致产品大的架构凌乱。按照我个人的习惯，在任何一个产品甚至产品模块开始之前都需要先画一张产品架构图，这个架构图会存在在MRD的最前面和原型图的最前面。这样有2个好处，产品自己可以很好的梳理整个产品的结构及每个支点如果有风险会影响的范围；需求被传递的时候下一个流程能够先很清晰的有所认知。

当大的产品架构出来之后接下来要做的事情是按照每条支线模拟一遍流程，使用流程图的方式来做，每个模块都需要。一般的处理方式是直接用相关的页面原型来走流程图，每个页面的下一个页面是什么，有几个支线，分别导向了什么页面。这样走一遍之后就能最大程度的避免“细节时间黑洞”。

是的，就是这样，因为要快，所以我们在赶进度，我们忘记了产品逻辑，凌乱了产品架构，忽视了页面流。这部分时间在排期的时候被忽略了，而这就是个大大的细节时间黑洞，这个黑洞影响着我们每一个产品。如果在研发过程中，我们发现之前的逻辑是错误的，那么问题将更加严重……

当然，这个案例中提到的情况还是相对可控的，因为产品人员有相对独立的控制权。如果再有权力高层掺合进来，不断的增加功能，不断的释放需求，那么，整个产品研发过程将更加糟糕了。最近微博上流行一张图，那才是真正的纠结（点这里围观）

最后，提到“唯快不破”，忍不住多唠叨一句。不要被“互联网产品唯快不破”带到沟里了，这句话原本没错，但是要注意2个前提：第一枪一定要打响，不然以后你就算再勃起的高也没人看了；在快的同时需要考虑自己是否有能力应对“快问题”并及时完美解决掉，是否有足够精力应付快之后被拉长的战线，不然就是快刀子也容易剌到手！

特别说明：细节黑洞时间这个词来源于一条微博，作者画了一张很大很纠结的一个产品研发流程。看完颇多感受，结合自己的感受写出了以上文字。

一直以来产品经理与交互设计师之间的话题不断，有人认为交互设计师可以算上是半个产品经理，也有人认为交互设计师的生存空间太过狭小，基本成了一个破画图的，等等说法不一而全。之前，我写过2篇文章大致来表述对于两者之间关系的我的一些观点，在“我理解的产品经理”中我认为产品经理需要同时关注产品设计、工程技术、产品运营3个方面；在“基于axure的PRD写作思考”中我简述了在没有交互设计师辅助的情况下产品经理如何做一个更像样的“破画图”的。今天，结合最近的一些项目经验，总结一下产品经理如何更好的跟交互设计师合作。

首先，我理解的交互包括2个层面的交互，单页面的交互和系统层面的交互。单页面的交互是最常见的对交互设计师的定位，比如把一个注册和登录页面做到极致，把一个搜索框体验做到最好；而系统的交互则是各个页面之间的交互，各个页面之间如何更好的联系在一起，目前显见交互设计师谈到这方面的话题了。

按照传统的瀑布模型，需求分析 – 产品设计 – 产品研发 – 功能测试 – 发布与维护 ，在这套流程中下一个节点必须在上一个节点完全搞定才可以开始。所以在大部分的情况下是产品经理先做需求分析，然后开始撰写足够详细的(注意这个程度)产品需求文档，交互设计师根据PRD文档开始做交互设计，完事后交付给视觉设计师做效果，最后交付给技术人员做开发。而在这个过程中，从最开始的需求到最终开发出来的东西往往很难保证其需求传递的准确性，也让交互设计师的生存空间大打折扣。于是，最常出现的情况就是“我明明想要的是齐天大圣，可是最后你却给了我一个孙猴子”。为了避免这样的情况出现，我们尝试将流程做了如下改进：

1、需求分析阶段

产品经理在产品调研及需求分析阶段产出一份调研报告，这个报告需要说明这个项目的项目背景、项目收益、需要满足用户的核心需求点、为了满足用户的这些核心需求，我们需要使用哪些功能模块。在这个过程中，产品经理只需要考虑如何最大程度最优雅的满足用户的需求，完全不需要去考虑技术实现难度。一定切记不要让某些技术思维使你的思维被僵化或者局限了！

在整个需求分析完成一次之后产品经理需要做的一个重要事情就是跟开发工程师确定需求实现的难度，哪些需求是立刻可以被实现的，哪些是需要长时间开发的，哪些时目前技术无法实现的，….。然后对需求做第二次的筛选与分析，同时试图寻找替代方案，目前无法实现的可以暂时存入需求池，排入工程师研发规划中。

2、需求第一次传递

需求分析迭代完成并通过评审之后产品经理需要开始将需求可操作化并做第一次传递。一般包括，需求的优先级排序、如何将这些需求衍化到一个可操作的产品中去、以怎样的形态进行展示等。在这个阶段需要输出2个东西，需求概述和产品架构图。需求概述主要对需求分析阶段得到的经过团队成员统一意见后的做总结，其实是继续准确的描述“解决什么人在什么情况下的什么问题”；而产品架构图则是该阶段最为重要的产出物，他是承载整个产品的根基，包括产品包括哪些模块，各个模块之间的关系如何等。

产品经理将需求概述和产品架构图交付给交互设计师，由交互设计师来完成需求的页面化,包括产品架构下的页面逻辑确定、单页面的交互逻辑确定。打个比方的话就像是产品经理提供给交互设计师一颗颗的珠子，并告诉交互设计师这些珠子的串联规则，而交互设计师需要完成的就是将这些珠子串联起来，以最动人的形式展示给用户。这个过程中，产品经理需要给交互设计师足够的信任，但前提是二者对于产品的核心需求点理解一致，由交互设计师主导完成珠子的串联，产品经理做方向把握。最终，产品经理和交互设计师共同接受原型评审，同时完成产品需求文档并做第二次传递。

在产品设计流程中，相对于其他环节的需求传递，产品经理将需求传递给交互设计师的环节最为重要，交互设计师对需求的理解和把握会直接决定后续需求传递的效果如何。

3、需求的第二、三次传递

经过上面的传递后产品需要满足的核心需求得到认同，产品的框架与产品逻辑都得到确认，在接下来的传递过程中，主要涉及到视觉设计师、开发工程师，问题已经不大，面临的一个核心问题就是排期。这里可以直接采用《用户体验的要素》中提到的方式“不能完整结束了这个阶段的工作，才开始下个阶段；在下个阶段该结束的时候，完成这个阶段的工作”

图片来源：用户体验的要素

另外，由于移动设备的特殊性，移动互联网产品设计较传统的Web设计又有其他差异，交互设计师、视觉设计师提供的效果不似Web设计可以在真机上完全模拟。所以，在移动产品设计中，必须要加入交互设计师、视觉设计师的真机效果确认。

絮叨了半天，其实总结起来就是这么几点：

1、满足什么人在什么情况下的什么需求之过东西，必须在每次传递的过程中被准确的传递，同时整个团队形成统一认知；

2、专业的人做专业的事，交互设计师是整个流程中最至关重要的需求传递环节，最好由产品经理提出初略的产品需求纲要，由交互设计师来完善这个纲要，然后向下传递

3、不能完整结束了这个阶段的工作，才开始下个阶段；在下个阶段该结束的时候，完成这个阶段这个阶段的工作

4、移动设备产品设计的特殊性导致必须要求各个环节最终效果都在真机上做一次回归

5、交互设计师是一个可大可小的职业，这，完全取决于你自己

前段时间千鸟写UCD概念在中国系列的时候，我跟他说你可以写个“产品经理在中国”，千鸟说这个事情太复杂没有经历去搞，等有时间的。于是，我一直期待到现在我想表达一下我自己理解的产品经理了……

首先，产品经理是个舶来品，业界普遍同意的是这个东西源自宝洁公司。其英文说法是Product Manager，中文翻译为产品经理，简称PM。我试着从这2个缩写字母来理解一下目前的产品经理流派。

1、产品的经理。P：Professional，专注于做（Design）；M：Management，专注于管理。
2、产品和市场。P：Product，产品设计层面；M：Market，市场运营层面。

第一种流派是目前几个大公司的产品经理流派，每个产品经理最终的发展方向不一样，有专注于设计的有以管理为方向的，然后P1、…、P12，M1、…第二种是我自己杜撰的，基于我自己的理解，个人为人第二种缩写的解释会更适合我理解的产品经理。

产品经理是永远从需求出发的立足于产品的有良好运营思维并擅于团队作战的狼首领。

记得早前在微博上有一条关于产品经理的微博流传甚广，被转发很多次，我是这样回复的：“我们只是：开发里面最懂UI的；运营里更注重用户的；战略中比老板更知道从细微着眼的；销售中比运营更了解产品的；比谁的权利都低但比谁都会运用权利的；产品做好了最容易被遗忘的那个小人物”。这是我对我理解的产品经理的第一次概括。下面详细说下

1、产品经理首先必须要对所从事行业充分了解，先是行业专家。深度了解这个行业的用户行为、行业规则、行业特点，或者至少是资深用户，才能培养自己的同理心，才能把握住整个产品的发展方向，最终去做产品。

2、产品经理是个立足与产品有运营思维的人。之前我说，产品设计师都是自负的，他们思考问题的方式在于这个事情应该是什么样子而不是他现在是什么样子；工程师同学永远都会先考虑功能实现然后考虑是什么样子；而市场运营同学考虑问题在于老板给我的预算额度是一定，我怎么分配这些市场费用能够达到收益最大化。所以，产品经理同学就必须兼备以上的思维，在做某个决定的时候同时“人格分裂”的从这三个方面考虑一遍。

在产品团队中，产品经理必须时刻记得问自己这样几个问题：我的核心用户是谁？他们在什么情况下有这个需求？这个产品的目标与期望值是多少？并且，要让整个团队的人都有问这几个问题的意识。需求，永远都是最根本的，如果产品经理搞不清楚这个事情，那么交互设计、视觉设计、工程师都会跟着错！产品经理草率的告诉交互设计师说我们需要上一个某某功能，交互设计师有责任有义务询问产品经理，为什么要做这个，给谁做？然后才是开始去做设计！否则就只是个工具。

3、产品经理要在团队中扮演寻找满意解的角色，而不是最优解的角色。如上图所示，产品设计、市场运营、工程技术3个部门关注的产品的点是存在重叠的，而产品经理就是去发现这个重叠的部分并很好的利用这个重叠的人。

满意解的意思在于，产品经理是基于“权益”的标准来进行团队沟通的，而不是基于权利或者权力，这个解需要平衡团队所有成员的权益。所以，我一直认为，“马化腾、史玉柱等是中国最好的产品经理”的说法是有问题的，他们应该被叫做“拜用户教”教徒以及“UCD型Boss”，他们算不上产品经理。

4、产品经理的核心技能在于沟通与控制。团队以及合作的观念必须时刻具备，当团队里每个人都受到鼓励、赋予了权利并且被尊重与信任的时候，团队就会有最理想的表现。从另一个层面上看，以团队意识为核心的结果往往会是没有核心，平衡了各方的利益之后，往往把本来最有利的部分完全抹杀了，敢于拍板和为自己的决定负责对产品经理来讲很重要，也就是要讲究控制，或者按照百度的话说叫做“和多数人商量，听少数人意见，自己做决定”。记得之前有位前辈给我推荐过一本书《只有偏执狂才能生存》，受益颇多。

你可以有某个领域不会，但是，你要有能力指使会的人去做。当然，也有必须什么都去做的产品经理。我把国内目前的产品经理分为两个类别：有UED支撑的产品经理（雌雄异体）、全能型产品经理（雌雄同体）。在有UED支撑的情况下，产品经理不太需要去关注产品具体的设计细节，产品经理更加偏重于如何去沟通，去解决问题；而没有UED支撑的产品经理更多的在于学会如何最大限度的利用资源，由于从设想到实现几乎都是一个人来做，所以，偏颇在所难免，寂寞是产品经理最要命的敌人。

5、产品经理一定是最爱自己产品的那个人，并且，我觉得只有自己一个人爱是不够的，同时还需要让整个团队的成员都植入这个观念。这种爱不是溺爱，我觉得有2个方面：擅于且敢于主动的自我阉割，开放的心态接受一切批评意见；不断的向大家介绍你的产品，并推荐之。为了爱产品需要有狼性，如我在微博上所说，产品经理应该明白，资源是靠“打砸抢”得到的，别指望别人施舍；社区的运营与产品设计者也应该明白，要做好社区就必须要有铁血政策，特别是在一个充满刁民的社区，当然，对部分意见领袖的怀柔也是必须的！

6、产品经理需要关注细节，但是不能纠结与细节。这点其实不用上纲上线，写出来只是警醒一下我自己。

没开始写之前我觉得我想的挺明白的，可是写着写着发现这些话好像是直接对我微博上说的过的话进行总结与摘抄，然后再读一遍发现好像都是废话…..不过，好吧，也许最难做到的就是那些正确的废话了，我还是记录下来了，我会不时回头看看我走过的路我思考过的痕迹的