[字数满，开新篇，8.3-8.12]《一条产品总监的日常》

公告：今日开始更新，都独立成文，不在同一文章内追加，该篇作为起始，留念！

 咳咳，前方高能，请戴上钛合金gou眼观影！同时注意观影文明！！！

（每日更新。。。内容涉及团队管理、战略规划、协作技巧、产品设计、交互设计、面试招聘等等等。。。分享来自于实践，但出于保密条例，很多会隐去和做艺术处理，大家自己体会就行。。。另外时间顺序未必真实。。。）

2016.8.12

题外话：观主，最近，忙着从产品狗leader退化回UE，所以更新和回答问题，不会写太复杂的内容，比如大家感兴趣的用户模型这类问题，观主等稳定点了再写。

另外今天写的两个主题，都是昨天有小朋友问的，观主呢，是个很懒很愚钝的人，最烦的就是思考写什么主题，所以，欢迎今日开始，大家在评论中留言，把你们想知道的告诉观主，观主会择机放入每日的更新中统一作答的，谢谢支持！

1.产品团队管理之：正三观！

作为一个团队管理者，你的态度和行为，很多时候，是在给下属树立榜样，所以，往往会发现，一个团队身上会有着管理者风格的影子，比如观主做事比较雷厉风行，团队也会被我天天赶着加速再加速！又比如，有些团队，从上到下，就是在推责任，这也是一种传承，那作为管理者，如何去把握团队的三观呢？

1）事业观——建立群体事业目标：

管理者有责任帮团队建立的第一个认知就是：我们这一群人，凑一起苦逼逼的，是为了做些什么？为什么要做？做了能怎样？

越是底层员工，往往接触到的信息量越有限，他们未必真正理解公司的愿景！不清楚公司的战略走向！更不明白他们每天努力改变了什么！

而leader不同，你的信息来源又快又多又全，你一定比他们理解公司的愿景！比他们清楚公司的战略！比他们明白每天的努力改变了什么！

观主一直喜欢把自己对公司业务的理解，形成一套整体的事业目标，并分享给团队所有人，甚至后来别的部门的人也爱来旁听。

观主始终认为：一群人，想要把心儿搁在一起，那必须有高于个体追求的群体目标，才能真正做到！而管理者之所以站在高位，是因为你有足够的眼界和判断，让你管团队，你就必须把你对群体目标，也就是事业的更高理解，解读出来，并分享给团队所有人，帮助大家从认知到认同，形成统一的事业观及使命感，从而更好的凝聚在一起，去完成这份事业！

而事业观，有微观和宏观之分：前者可能是上线一个新的商家会员体系，对商家用户分级的同时，又起到了激励和引导的作用，从而通过优胜劣汰激励商家自我改变；而后者在前者的基础上更进一步，可能是这样的优胜劣汰下，势必改变了整个市场现有规则，优化了市场自我调控，促进了整个世界商业的进步！

从上述如此小的一个功能，其实背后就蕴含了莫大的事业使命感和商业逻辑性！

观主从工作第三年开始，渐渐接触和明白，企业的最终形态，就在于“反哺”，取之于民用于民，从社会获得，就要反馈社会，这是社会责任的体现！

如何把你团队面临的工作和问题，转化成共同的事业目标，通过高度一致的“事业观”，去一起进步，就看管理者自身对事业的解读和传递了！

注意：

观主见过很多leader，纯把团队人当生产工具，让人不要独立思考！不要触碰业务！不要关心战略！长此以往，团队的灵气和精神都会磨灭殆尽！

2）工作观——工作认知、态度和方法：

什么是工作观？

顾名思义，即如何正确的认知工作？如何正确的开展工作？如何正确的对待工作？

即一整套的工作理念和态度和方法，覆盖面极广，观主认为，第二个需要树立和明确的就是“工作观”，作为管理者，以上三点你一定远胜他人！

所以在工作中，你需要以身作则，帮助团队所有人去学会掌控工作，让他们明白如何做是对，如何做是错，如何做能达到更好效果！这就是“工作观”，一种工作方法论的传承！

这个范畴牵涉很广，很多人容易和“事业观”混淆，观主用案例来说明：

a.问：运营做的方案不好，产品需要提出问题还是少说话不惹事？

答：正确的工作方式是，委婉的从本身专业给出建议，不恃才傲物，也不畏首畏尾，以事业观为大前提，在提建议的同时，让运营理解你们的目标是一致的，核心在于让大家的付出得到更好的回报！

b.问：遇到紧急问题，是互相推诿还是只处理问题？

答：前者是错，后者对错参半，正确的工作方法是：先快速解决问题，同时在事后追责，要让团队理解，追责的目的不是惩罚，而是找出问题，避免下次再发生！

c.问：没有交互就让产品自己画画原型？

答：核心问题是，交互这个岗位可以没有，交互这件事儿得做！对工作责任的解读，对工作事宜的理解，也是工作观的一部分，交互这事儿的核心价值在于统一规范体验，而不是执行层面画原型那么简单！

d.问：邮件发给协作部门了，就等结果吗？

答：当然不是，工作合规性上看，发完邮件只是流程的开始，核心在于问题得到解决和处理，及时跟进是一种很重要的工作方法和态度！

e.问：工作时间学习技术，能写进工作日志吗？

答：no！除非是上级明确安排研究某类技术，否则， 千万别犯傻，公司花钱买的是带有完整技能的你，买的是你的产出，你的学习和成长过程，公司可不买单！

相信通过以上几个问题，大家对工作观涵盖的点有了一定理解，观主在带团队时，往往会通过一些具体工作的分解，以及一些经验的分享，去帮小朋友们树立正确的工作观，去告诉他们，如何更正确的开展和对待工作。比如下面小朋友跟进问题不及时，观主会帮他理理工作流程；又比如下面小朋友害怕担责任，观主会帮他正正工作态度！

注意：

如果leader自己工作观都不健全，那团队就一定上梁不正下梁歪了！

想要提升工作观，得从很多方面着手，诸如：理解产品团队分工和组织架构、理解内外部协作合规流程、理解工作问责机制等等等，相信传统大企业的内部培训，已经把如何正确开展工作说的很完整了！

3）价值观——个人价值具象化：

如果说“事业观”和“工作观”，更多的与公司有关，那第三点“价值观”就更多的是在描述：如何帮助团队每个人建立一种认知——即我在这里，公司和事业变的越来越好，我获得了什么？

观主带团队时，经常碰到许多小朋友，缺乏自我追求和目标，这其实就是没有清晰“价值观”的体现！

想带好团队，除了给他们更远大的目标（事业观）和达到目标的工具（工作观），也需要“让马儿吃饱”，即给他们赋值，这里的值，就是帮助团队成员，基于前两观，判断自己的诉求是什么？并与团队目标相结合，把企业利益和团队利益和个人利益做捆绑，这样每个人才会有动力和追求，去一同完成群体目标！

作为管理者，要学会分析每位团队成员的情况，解读出他们的核心和次要诉求，并为他们找出清晰的路径，即如何在这个团队和事业目标内达到这些诉求的办法，让每个人在这个团队工作是有意义的，是主动的，是愉悦和满足的！

比如：对刚毕业的实习生来说，最普遍的诉求是——工作（留用）和成长（学习），那如何去帮他们明确这个目标，并用事实告诉他们在这个团队，努力工作，就能达到这个诉求？这就是在树立“价值观”，也就是高明的管理者需要去实现的！

只有将团队每个人的价值观具象化了，才能有机会去引导他们产生：我在这个团队工作是有价值的，我努力后获得的东西是有价值并是我需要的，这样才能进一步认同团队和群体事业目标！（大白话：给人家个为啥在你这苦逼的实在理由儿，事业那东西，太高大上，是精神层面需求，但是解决不了短期需求！！！）

总结：以上三观正的团队，怎么做都差不到哪去儿，这三观，一定程度上是相辅相成的，如果想管好团队，请一定先正三观！！！

最后给个完整忽悠流程：给人定个大目标，再告诉他能跟着大目标获得啥，最后告诉他如何去达成这个大目标！

---

2.团队管理小技巧（一）！

观主做了七年多产品，呆过各种规模类型的公司，运气不错，第四年开始接触团队管理，第六年开始经历从无到有的团队自建。

其实每个公司对产品leader的定义和职责划分不同，但是观主在的公司，基本会把UI、UE归入产品体系内统一管理，一般人数在20到30人不等。

今天应各位要求，说几个小技巧：

1）“进度不拖，项目不毁，投诉不来”——这是观主和团队所有人着重提出的三个要求，在这个基础上，观主一般只扛责任、协调资源、指导专业，以及带领攻坚疑难，充分给予团队自由发挥的空间，最好的疼爱就是手放开！

2）“学会给下属留面子”——团队大了，什么样的人都有，难免会有人捅娄子，也会有人急功近利，更会有人引起内部矛盾，观主一般不会当场下人面子，更多的是过了这阵风，私下推心置腹的找人谈，大家出来混，面子很重要，今天你下人家面子，可能明天人家也会下你面子！

3）“是害虫，就趁早消灭”——别妇人之仁，指望着害虫改变，害虫的产生，必然有着诸多原因，改造的风险过大，有这精力去改造一条害虫，不如迅速换血，以雷霆之势以儆效尤，切记：当断不断，反受其乱！

（PS：前提是你真的确定是一条真正的害虫，比如很多人懒散，可能是安逸的管理制度下造成的，这种对团队没直接伤害的，未必属于害虫）

（且看下回分解）

2016.8.11

1.产品团队管理之如何规划电商平台产品线？

今日聊聊：观主所理解的三种电商平台产品线规划策略（根据不同行业、类型会有细微差异，以下仅供参考；尤其要注意，不要拿某宝来比对，人家是最终形态下的产物，早期和中期的电商玩不起，还是先把业务做扎实吧）！

一、按使用流程分：

1.核心依据：

以用户使用的流程为依据做切割和划分。

买家线：从找到平台到找到商品到完成交易到售后环节再到二次购买的一整条交易主线。

卖家线：从入驻平台到成为商家到开店上传到接单卖货再到售后跟进的一整条服务主线。

平台线：从服务买卖双方到活跃激励整个平台用户到拉新推广到服务保障到财务结算等。

2.举例说明：

不分先后：

a.搜索线（分类管理＋标签管理＋推荐逻辑＋搜索算法＋排序、展示逻辑等）

b.展示线（内容、广告位管理＋首页＋落地页＋聚合页＋seo/sem支持＋专题、活动页、帮助中心等）

c.子频道线（按需设立：一般独立于平台主交易流程之外多子频道或者常态活动频道，都会设置一条单独的线来管理，如某宝聚x算、抢购功能、如某家居商城的装修资讯频道、如一些电商的论坛等，这条线相对较为灵活机动，类型多样）

d.主交易线（商品详情页＋售前服务＋购物车流程＋下订单流程＋支付流程）

e.买家后台线（会员中心＋信息管理＋虚拟钱包＋售中、售后服务＋订单管理＋收藏、历史浏览等增值功能＋用户成长和激励体系等相关延伸，不赘述）

f.卖家后台线（信息管理＋商品管理＋订单管理＋财务管理＋物流管理＋库存管理＋推广管理＋店铺管理等＋用户成长和激励体系等相关延伸，不赘述）

g.平台总后台线（平台总后台，功能在早期考虑到代运营和强管制需求，一般会包含并大于卖家后台功能，同时需要注意以下几点务必早做打算：权限切割、财务结算、客服系统对接、数据监控和埋点、用户成长和激励体系、客诉和服务管理以及商家管理等）

h.移动线（包含移动端app和微信和wap，如果是平台性质的，前期不推荐过早的介入移动端，当然看具体行业，移动线前期主要是将平台的功能精简并迁移，存在功能重叠严重，推广和开发成本高等问题，所以判断是否需要移动线应看公司战略，以及移动线的优势是否对业务有帮助，再做定论，观主经历过不少移动做个花架子或孤注一掷结果半途而废的例子）

i.金融线（主要两块，对买家的消费金融＋对卖家的供应链金融，大多数早期平台没有，因为授信和风控难以控制，但是b2b供应链想对容易，因为证照齐全，交易真实性保障度高）

3.人员要求：

按照分线策略，在招人时需注意，应聘人员是否有符合该线要求的相关项目经验，过往工作内容是否与该产品线的要求相近，在工作经验上可适当放宽，主要看对某条线，比如对商品展示的了解程度，因为该线是模块化切分后做前后衔接，所以每条线上的人能力不用太全面。

4.优劣对比：

优势：各线更为专注，各线间的关联性强，对各线的产品经理的能力要求相对较低，不需要过于全面，假设某条线的产品较弱，前后关联线可以通过协作，做很大程度的弥补，发挥整体优势。

劣势：一旦某条线出问题，衔接上会很混乱，同时产品经理对其余每条相关产品线需要花很大精力去了解和熟悉，一旦消息不透明或闭塞，就容易产生盲区，造成设计上的前后不一致。

二、按业务板块分：

1.核心依据：

以平台业务板块来切割和划分：

按品类：一般适用于全平类平台，不同品类之间差异化太大，会按品类来做区分。

按模式：一般适用于多种交易模式的平台，如b2b供应链大多会分三块：撮合、现货和金融。

2.举例说明：

用某化工b2b平台举例，分以下几条线（该线特点是出了移动线其余每条线对应到一个业务部门负责）：

a.撮合交易线（询盘相关业务：从采供信息展示、搜索、下询盘到撮合交易到线下追踪等）

b.现货商城线（类似一个小天猫，不展开赘述）

c.供应链金融线（类似p2p，不展开赘述）

d.用户体系线（用户管理与激励，招商和认证等等）

e.用户后台线（买家和卖家的管理后台，不赘述）

f.总后台线（整个平台的管理后台，对以上几条线形成管理和支撑，包含BI系统）

g.移动线（包含app和微信，将部分核心业务流程迁移到移动端）

3.人员要求：

相比上一种分法，这种方法人员数量和线对数量都会减少，但几乎每条线都会涵盖比较完整的一段流程，所以对每个产品经理的能力、经验要求会提高，需要每个产品经理都有较为全面的能力，同时对完整流程有足够的操作经验，招人的侧重除了不变的“项目经历契合”，改变的是“需要从专提升为全面”。

4.优劣对比：

优势：每个业务板块延伸的产品线，相当于一个独立的项目，各线之间更为独立，不容易因为某线出问题或者延缓导致联动性问题发生，同时每条线因为独立对一个业务板块负责，需求会更有针对性，支撑会更有效，更可量化。

劣势：任何一条线的人员要求都较高，否则就容易自坑，如上例，无论询盘线还是现货线，都需要独立完成用户的整个使用流程的产品设计，相比方法一，由于整个平台的在产品设计过程中被相对独立了，可能带来的问题就是容易过于沉浸，导致业务板块之间的协作和支撑缺失。在项目管理上，因为大家负责的实际设计会有很多类型上的重叠，比如询盘线和现货线，都要关注seo或者app或者微信，这种情况下，在需求到开发的过程中容易产生冲突和掐架。

三、按人力资源分：

1.核心依据：

这种分法，对于小团队（三无创业公司）特别好用，说白了，早期业务不清晰、人员预算不充足时，这种类似游击战的打法未必漂亮，但是至少高效和高能！

2.举例说明：

实际操作就是一拖多，大家读书时都知道先进带后进，帮困小组吧？

这个分法很简单，就是把现有人员按能力和经验高低分层，然后按金字塔形一层层排布：执行类往下推，决策类往上推；难度往上推，简单的往下推。

比如观主目前在的创业公司，就一个app，一个web，一个后台，三个产品，有2个产品助理＋观主，就能解决了，产品助理主要做些非重要的设计工作和文档整理，观主主要做需求分析和产品功能制定等稍微需要烧脑的部分。

3.人员要求：

至少一名全栈产品经理或20%的中高级产品（二选一）＋80%初级产品，不展开赘述。

4.优劣对比：

优势：省钱，省人，设计出来的东西，中规中矩，高度统一，不容易出大乱子。

劣势：但是一旦出大乱子，就是天大的乱子，因为决策层较少，点的错误容易瞬间扩散到面。

以上就是观主的一些拙见，与各位分享，举例中或有不详尽之处，敬请谅解，无论大公司、小公司，都可以按以上的方法来分，可能会有区别，无非最终划分到的颗粒度有多细致而已。

希望各位可以从这些案例上去收获规划产品线的思路与方法，然后结合实际的业务，规划出真正适合自己业务场景的产品线。

该篇不单适合产品团队管理者，同样的，产品经理想要有提升，必须对管理和规划有足够的理解！

---

2.观主其实只想安安静静的做一名交互设计师，有人撩吗？

有图为证：

哼哼！

哼哼哼！

欢迎大家加我微信（Jax-UX）沟通，想看什么主题也可以说！谢谢！

（且看下回分解）

2016.8.10

1.《独孤九辩》：掌握以下九点，就能在产品评审会上把控节奏！

（又装了一回儿武侠BI，这感觉倍爽儿！！！）

背景：昨日观主参加了好几个评审会，对部分产品经理的评审会把控能力，有着更深的期待，结合过去的经验，总结了以下九点，望各位注意（大前提：只教评审会把控节奏技巧，该如何分析需求和设计，以及如何做准备，依然是关键，本身准备不佳，就好比先天不足，再好技巧也无济于事）！

1）掌握叙事顺序：从大往小，从外到里，从远到近，从高到低，从粗到细。

错误：我们今天评审一个需求，先来看后台需要增加的模块。

正确：我们今天评审一个需求，它的设计背景、动机和场景是XXX，它由XXX部分组成，我们先来看XXX，它是核心，其余的模块对它起到支撑作用。

点评：叙事先搭框架，立条件，然后，就顺理成章了，听的人也会有脉络感，而不是听的东拼西凑的感觉，便于建立统一框架下的统一认知。

要给听着一种环环相扣、骨肉相连的紧密感，比如前台需要显示商家等级，后台需要对等级做配置，这就是一种骨肉相连的依存感，说起来也自然是：为了前台XXX，后台需要配套XXX。

2）巧借认知共性：见人说人话，见鬼说鬼话！

错误：我们做了个活动模板配置器，它能根据你的设置，生成适应各类场景的活动页面！

正确：（对一群地推人员）我们做了个灵活的设计，它就好比一个宣传包，里面有各种根据不同场景需求设计的活动DM，你们在推广时，根据需要取出不同的DM即可！

点评：找找你和听众的共鸣：用他们的视角去重新理解设计，并学会用他们的语言去阐述！让他们感觉你是懂他们的，是在为他们而设计！

产品永远不是高高在上的上帝，而是行走于最底层的行者，用你的设计去帮助大伙儿，并感动他们！

3）寻求情感共鸣：将心比心，渲染气氛，代入情景！

错误：我们设计了一个全新用户在地推时，从注册到卖家认证的流程，分为三个页面，每个页面分别需要用户填写一些信息。

正确：我们理解，在地推过程中，让卖家同意注册是非常难的，每一次说服都是一种突破，所以我们希望通过设计和流程的切分，为用户和地推人员减负！于是，我们把流程切成三个页面展示，这样每个页面，用户填写的信息都不是特别多，他能很快理解和接受，并愉快的完成！

点评：产品经理，要学会争取需求方的支持，这样才会降低说服开发的难度。

同时，无论你在设计时，是否代入了感情去思考，必须记得，在评审时，结合业务情景和客观的业务情况，重点阐述你的设计，将为业务带去怎样的改变，从而寻求情感层面上的共鸣，毕竟心要在一起共鸣，必须先让你自己和对方站在一起，别和需求方对立，你们都是为了公司好！

4）预演疑点答辩：和下围棋一样思考疑点，并进一步把疑点变成陷阱！

错误：（经常碰到）这个问题，当时也没想清楚。

正确：这个问题，在设计时，我就思考了，当时想到的解决方案有如下XXX，其实，在这个基础上，我更深一步的想到了XXX，不知道你们有没有思考过这个问题。

点评：第4招纯靠两件事：前期充分准备+转移话题技巧。

观主见过太多的产品经理，在评审会上，因为一个没确定的疑点被人“将军”，如果下过围棋，应该知道，这种运动耗费脑力之处在于计算和推演，做产品也一样，设计过程中遇到一个问题，刨根问底的找方案，评审时，如何回答就靠这了，同时要学会把问题缩小，不要回答了一个问题，引出更多不确定。

这个时候，可以尝试变被动为主动，主动跟着答案引出一个更深度的问题，去反问存疑者，同时也把话题转移了回去，一旦他答不出，而你能自问自答，高下立判，评审就是一个步步为营，慢慢建立优势的过程，让大家变得更信服你，很重要！

最后提下，何为预演？不是简单的想下答案，而是要提前准备好完整说辞，任何人回答问题时，语句是否有序，会直接带给人可靠和思路清晰的感觉！

5）展望进阶需求：现实如此惨，未来会更好！

错误：我们这个需求这次只能实现这些功能，其余的来不及做。

正确：我们这个需求，很大，一定很棒，但是时不待我，我们先把最基础的上了，后面再紧跟着上剩余需求，同时根据先上的，我们说不定还能进一步对之后的需求提出更好的想法！

点评：笨的人，永远爱抱怨现状，聪明人，永远对未来充满希望！

语言的美有时在于两面性，同样的话用不同的措辞和语气来说，给人的感觉是截然相反的，不要老把负能量传递给听众，多描述未来的美好，给所有参与评审会的人信息，让他们理解现在的克制是为了美好的将来！

还记得一个小故事吗？三个工人一起砌墙，唯一认为自己在为这个城市创造未来的工人，最终脱颖而出了，你要做哪个工人？

6）观察细微表情：察言观色，顺势而为！

错误：自顾自的讲，全程流水账，不看需求方眼色，不给存疑者提问，积压所有问题和质疑到最后一起爆发。

正确：阅读每个与会者的表情、动作，看看谁是支持你的观点的，谁分心了，谁有不认同和疑问，对支持的人，多问他是不是也这么想，对分心的点他名问问题，对不认同和疑问的埋坑给他跳，别让他按自己的节奏发难。

点评：人生如戏，全靠演技！除非老戏骨，否则一般很多细微表情动作都能看出以上的一些点，什么叫把控全场节奏？

顾名思义：别人的行为，按你安排的节奏触发，和做交互一样，他想思考全了提问时，你先打他一个措手不及！他对你点头，你就捧他，别人看到有人支持，也会更偏信你！要自己把控节奏，别被人先手！

当然，这点不是教你去不听合理建议，也不是去规避问题，而是更好的激发问题和建议的同时，别把自己主持人的角色变的被动，这样会影响你阐述需求和设计的效果，观主希望你们能通过把控节奏，100%的把自己的设计说清楚，这样的前提下，有则改之无则加勉！

7）学会狐假虎威：扯大旗，巧借势！

错误：这个我是这么想，所以这么设计的。

正确：需求方这么说，我分析后，觉得如果我们要达到他们目的，这样设计最好，他们也认可了。

点评：比较腹黑，不展开说，多借用你的需求方来佐证你的话，但是前提你先和他们达成一致！

8）建立业务关联：让开发更有动力，让业务更有信心！

不举例了，其实这点，更多的是对开发的兄弟们（第2、3招也一样对开发适用），你们要记得，评审会向前寻求需求方认可，向后寻求开发兄弟认可，把你的需求和设计，和业务场景以及目标做关联，让开发的兄弟们，清楚的知道他们的努力，为公司创造了什么价值，这样他们才会更认可你，也会更有动力，而不是写出冷冰冰的代码。

人和人的尊重理解，永远是相互的！

9）增加专业词令：装BI，给人不明觉厉之感！

哈哈，这点不展开说，就提醒大家注意一点，一旦你创造一个专业词汇，别下次自己穿帮，同时，专业词汇的使用，要用在一些不重要地方，千万别适得其反，给与会者造成不必要的认知障碍！

总结：掌握以上九招，你的评审会更顺利，但是前提是思考和设计本身的全面和质量，观主希望大家把《独孤九辩》用在正途，而不是拿来颠倒是非和一言堂！

---

2.今日感悟：

观主跑马拉松时，悟出个道理：人永远别和别人比，总有人跑得比你快，有人跑得比你慢，只要和自己比，确保今天的自己比昨天的自己更好即可！

（且看下回分解）

2016.8.9

各位！今天观主要使用洪荒之力来更新了！！！

1.如何做好需求分析？

今天谈谈产品需求分析的具体落地，不教大家怎么去辨别真伪需求，也不谈虚的方法论，客观说，产品经理这个层次，大多数是没能力和眼力去决定一个需求做与不做的，这需要的不仅仅是经验阅历，以及专业能力，更重要的是需要学会借势和博弈，观主有很长一段时间，关闭需求的占比保持在三分之二以上，连大BOSS的需求也照关不误，这并不是观主多厉害，而是引导了对方自己去关闭自己的需求，关于这点，之后有机会再说。

假设：在你面前有一个需求，是必须要做的，我们该从哪几个方面着手？

1）搭建设计框架：

框架越大越完善，需求置于其中思考，就越周全。

a.设计背景：

第一步：探寻需求本质，需求实现后，到底会带来哪些改变；

第二步：比较当前现状，需求未实现前，现状到底是怎样的？

第三步：在公司战略/商业模式/业务目标/用户痛点中，找到需求的价值立足点，说白了，要和公司大方向契合，两个产品经理做同一个需求，看的远的那个，才会真的把需求实现的更好！

举例：天猫的创立，在一定意义上，就是为了解决淘宝假货遍地的问题，用品牌来约束商品质量。

b.设计动机：

需求是一种目的，而设计是推动着业务向目的前进的过程和手段。

所以，设计动机，说白了就是为什么设计？即如何根据需求目标，去剖析得到设计目标，这个设计目标，是必须要起到支撑需求目标的作用的，在这个基础上才能进一步规划设计思路。

c.应用场景：

前两点完成后，大家往往会忽略应用场景，缺乏这点的设计框架，是无法形成闭环的，应用场景，简单的说，就是你这个需求，在经过设计实现后，在什么样的情况下被谁去触发和操作。

很多设计，有时本身没有好坏，要看用在何处，一个好的设计框架的作用就是帮你全面思考和分析，在这点上，应用场景是十分重要的一环，不以场景为条件的设计，都是耍流氓，通用型设计在这个个性化的时代，已经不再能让用户妥协和买单！

举例：比如o2o常用的关注公众号送礼功能，整个设计的框架，就是如何在线下快速地推的应用场景下，去实现所有人（用户和地推人员）的快速操作和反馈，降低时间成本带来的用户拒绝和流失。

2）确定需求抓手：

说白了就是设计的切入点。

a.涉及模块和流程：

需求的实现，会牵涉哪些模块和功能和流程，新增还是修改还是拓展？

b.影响模块和流程：

需求的实现，会影响哪些模块和功能和流程，新增还是修改还是拓展？

这点很重要，很多产品往往会聚焦需求本身涉及的部门，而忽略带给其余模块流程的影响。

这里说个原则：任何公司，不管资源多寡，原则上，尽可能借用现有的功能，尽可能小的去改动成熟体系，尽可能减少不必要的联动。

c.需求底线：

这点也非常重要！！！

观主带了那么多团队，遇到太多的产品经理，聊完需求，都不清楚需求方的底线在哪，作为产品经理，不仅仅是为需求方在服务，你要考虑方方面面，比如公司的资源和成本等等，同时，需求永远是做不完的，而需求方永远是急切的，如何去客观的根据一个需求的价值和投入来综合判断很重要。

为什么要知道底线？底线就是你灵活设计的余地，如果两个需求摆在你面前，资源永远是有限的，如何把一个更重要的需求做的尽可能完善，同时最低成本去满足另外一个需求，取决于你是否知道每个需求的底线！

3）提出解决方案：

也就是你的设计思路，这是产品经理的基本功，不展开说，观主一直习惯，做好解决方案后，先不和需求方沟通，先自己放空一下后，换个人格来自我质疑，把整个设计反案过一遍，确认每个可能存在问题的点，都可以对答如流，再去找需求方（傲娇一下：七年多产品生涯评审均一轮过，无反复！！！）

4）规划具体功能：

设计方案一旦确认，就是具体功能的设计，还是要在设计框架和抓手下综合思考，相信各位也看出来了，观主觉得需求落地最核心的就是设计框架和抓手，在前两点思考全面的前提下，后续功能设计这些，不会有太大问题，都属于产品经理的基本功了！

顺带插一句，在具体功能设计中，还是有很多技巧的，比如可以通过试纸测试去低成本试错。

5）制定核心指标：

在大数据时代，做一个需求，实现只是其一，要养成持续关注其成长的习惯！

所以，需求分析时，就需要考虑，哪些数据是与这个需求有关，或者能证明需求的价值的？同时如何去埋点获取这些数据？观主经常遇到产品经理，只想着分析数据，不思考如何埋点。

6）切分需求路线：

这一点，和需求底线有关，一般如果一个需求在初期，只实现最基础的目标（即只达到需求底线），那在其之后，会有后续的需求版本和规划，这就是需求路线，制定一个清晰的需求路线，让需求方可预见未来，也是让自己更全方位的去思考和规划！

总结：大多数产品经理喜欢关注如何设计功能去解决问题，殊不知，最重要的是动手（具体设计功能）之前的框架和切入点梳理，还是老话：站的高！niao的远！（想的远！做的好！！！）

今天七夕有点懒，言简意骇点，没展开，有问题加观主微信或者简信沟通！

---

2.七夕节是神马！！！

愿全天下的情侣，都在今日发现，原来是失散多年的亲兄妹！！！

自己体会！！！

（且看下回分解）

2016.8.8

1.为什么很多产品经理从来不做用户模型？

先表个态：

1）用户模型是不是好东西？肯定是！而且非常有用！

2）用户模型是不是必要品？未必是！要看具体情况！

既然说到用户模型，先对这个问题下的几类用户做下粗分——

1）从主观需求层面分：

a.新手：不会用，认知不全面，无头绪

b.懒人：知道，但是不想用，观望态度

c.高手：有自己的方法论，可以加速过程跨过这步

d.卢瑟（loser）：用过，没用好或认为没用，不想再用

e.叛逆：不相信，本质上否定和拒绝

f.迷徒：以为自己在用，其实没用对或者没用好

2）从客观资源层面分：

a.穷：真穷或者家穷，总之公司在这块儿上不舍得投入或者没能力投入

b.急：项目时间短，认为这块儿时间成本过高，收益低

c.傻：公司或者团队决策层脑子上有点偏激，对这块儿理解不够，把一个雪中送炭的事理解为锦上添花

d.利：整个行业急功近利，以用户为中心常常是挂在嘴上的，而行动上更追求kpi和满足既定目标

e.少：公司人少，团队人少，没人陪你玩，一个人瞎折腾结果“正事”没干好

f.傲：全公司从上到下以为自己对行业和用户理解多深刻，见人就bala bala，人在自以为是的时候，还需要去深入了解吗？

以上就是观主认为的主观和客观两个层面粗粉的用户模型，描述也写了，基本上躺枪的应该众多吧！

哈哈哈哈！

至于说为何会出现种种？观主认为原因有三：

1）中国人的心性往往急功近利，缺乏工匠精神，这是一个社会问题在行业内的映射；

2）中国互联网的特点带来了很多断层，有学术上的断层，有管理上的断层，有传承上的断层；

3）中国互联网的发展阶段尚在初级，虽然有诸多独角兽和bat，但是不可否认在发展上，有点一蹴而就，而非健康的自然发展！

那为什么观主认为用户模型很好，但是未必是必要品？

在用户体验设计中，有一类情况，需要为中高端用户提供特殊路径，帮助其可以凭借经验和技能，快速的跨过初级繁琐的常规操作，来直接达到目的！

观主认为，部分高级产品经理之所以不用，其实也是符合这点原则的，但是经验之谈：如果你在带团队，你可以加速过程，不过不要完全跳过，给孩纸们留一条能赶上你的道路，也是为了项目好！

---

2.向“创业狗”们致敬！

今晚，和一位创业两年多的朋友小聚，席间，观主很不厚道的戳了人家痛处：你那小破公司，别呆了吧？就算上了新三板有什么意思？

朋友是这么回答的：从开始创业，行业里属于中游，仰望着当时很多做的好的同行，到今天，他们做到NO.1，虽然很艰辛，到今天还是省吃俭用的，但是那些当年做的好的，都在资本寒冬下死的差不多了，剩下的只有他们，虽然在外人看来，不明白他们图什么，甚至会误会他们是一群为了创业连生活都可以抛弃的人，但是他们的内心，其实有着属于自己的骄傲和坚持！

观主，突然懂了，回想自己参与创业的这两年，突然很怀念过去的那些战友，你们还好吗？

向所有坚持创业的人们致敬！勿忘初心！

（且看下回分解）

2016.8.7

1.送给交互新人们的“五字诀”：

一曰“点”：每个控件本身属性和触发方式；

举例：比如一个输入框，本身属性需要考虑可输入的字段类型、长度和输入前中后的视觉形态等，而触发方式需要考虑切换焦点到输入框内和如何离开等（这里的控件不一定是输入框，可能是按钮， 也可能是文字链接等等等），第一要点，是希望交互设计师们，先仔细的思考清楚每个控件的本身和存在价值。

二曰“连”：控件和控件之间的关系和交互；

举例：最常见的比如注册界面，用户协议，复选框没有勾选同意时，注册提交按钮是灰色不可点状态，第二要点，说的就是控件与控件之间的先后、从属、交互关系。

三曰“面”：页面本身的主题或主流程目标；

举例：任何一个页面，都是为了一个或多个目标而存在的，哪怕如会员中心首页这类聚合页，它的目标是聚合和承载，以及快速的链接各个功能点，第三要点，说的就是在交互设计时，当你研究清楚每个控件本身和空间之间关系后，需要着重思考的是，这个页面本身的目的是什么？文案和信息结构，以及控件，是否可以清楚的暗示或明示用户按你设计的走下去，并达到目标？比如注册页面这类目的比较唯一的流程型交互流，我们要做的是，确保用户可以轻松和准确的一步步向下，不要中断、返回和跳出，这样的交互思考下，交互的轻重强弱，自然随着第三点页面主题而清晰明了。

四曰“地”：主要控件触发后本地交互校验；

举例：继续拿注册页面来看，假设第一步页面是手机号的校验，在点击下一步时，其实交互上没有第一时间和服务器端做连接，而是先对手机号的输入框做了一次本地校验，校验的是输入框内的数字是否满11位，开头是否为三大运营商号段等，这次校验，就叫本地校验。

为何设置本地校验？

a）降低不必要服务器交互成本；

b）提升交互出错时的反馈速度。

所以，第四要点告诉大家的就是，在交互设计时，一些涉及向服务器交互的重要按钮（动作），或者一些可以在输入完就做判断的输入内容，可以先在本地做一次校验 ，而不是一股脑的塞给服务器去判断，服务器和程序猿哥哥都不喜欢这样的孩子。

五曰“天”：本地校验成功之后服务端校验。

举例：多拉轰的第五要点！和地面部队交锋成功后，我们终于迎来的最后一步，向服务器提交，也就是和服务器端做交互，交互类型包括很多，如注册就属于表单的提交和校验，服务器一旦校验完成，就是反馈结果和允许跳转，同时提交的表单会被记录到相应的数据库中，整个交互的目的也就真正的完成了。

在这个终点到来之前，交互设计师们，千万谨记，这一步看似简单，其实凶险万分，要充分考虑各种情况下的校验反馈，如传递到一般断网了？注册成功返回时服务器崩溃了？注册时显示有问题？等等等，同时要考虑在各种情况下，是停留在本地， 还是跳转，或者增加一些引导提示帮助找回状态，所以和“天”沟通，实则不易，千万不要功败垂成！

最后，来个口诀串起来，别说观主土，观主酷爱武侠，和马云粑粑一样！

口诀：两点一连就是线，多线一合就是面，换面还须先入地，上天实则最凶险！（呦西，还押韵了。。。）

这个武侠BI装的不错，自我评价99分，多1分怕骄傲！不说了，马云粑粑要来幼儿园接藕了！

---

2.观主是如何学习产品和交互的？

多做，多想，多错，多改。

观主这7年多的职业生涯，只看了两本半的书，无数的产品经理问过这个问题，也追问了是哪两本书，在这里分享下书名《体验经济》、《星巴克体验》，还半本《一路向前》。

观主不是学院派出身，任何理论知识，你们听着新鲜的原因，是因为都是自己总结的，书上没出现过，顶多雷同，所以你们听着新鲜，哈哈哈。

观主这七年，刚毕业时是文案策划，一路做到现在，无非在重复一个流程：上去干，干不了想，干错了改，改完以后不犯，下次继续直接上去干！

如果非说有什么不同，观主可能更信奉两点：“一千次空想不如一次实干”，上面的流程就是最好佐证，另外一点就是“道法自然”，观主毕竟是道家的嘛，所以法天法地法万物。

观主的学习方法，是在日常生活中，任何场景下，观察身边的一切，去思考他们或者它们背后的逻辑和原因。

比如家附近新开了一家烧腊店，观主在出门第一次看到时，就思考了很多问题，比如它为什么是个烧腊店？它的客户是谁？真正的客户会是谁？它的客户复购率如何？它的产品应该如何定位和定价？如果我是老板如何增加销量？等等等，一大堆问题。

又比如，今晚在星巴克买咖啡时，看到乱哄哄的吧台，观主就思考了很多点，比如：咖啡师在做巧克力原浆时，是否可以拿到里面去做？避免制作过程的不拘小节被用户看到等等。

总结：很多人老爱问这个问题，今晚统一作答了，最后希望大家，多做生活的有心人，观主做产品经理第二年时，就爱和人说，多体会生活，懂生活就懂产品，那时，没人信！现在，你们还不信吗？骚年们！享受生活吧！毕竟你们的产品是为了生活和大众服务，有什么比生活更好的老师吗？

（且看下回分解）

2016.8.6

题外话：今天，是从pmcaff搬来的第一天，为什么搬？可能是觉得那里更多的，不是读者，而是商人。

我的文章，每天纯因兴趣而写着，也纯为个人喜好，平时工作里，很多体会感悟，希望找些人倾述罢了。

从今日起，如无意外，每日更新，这个连载，未必一直是专业的东西， 我喜欢说它的是半专业、半小说，偶尔会把以前工作里遇到的一些“办公室规则和经验”，用第三人称的方式，告诉大家，所以，这里的观主，有时，不仅仅代表的是作者本人，请勿对号入座！

1.办公室里的“圈地运动”：

记得观主年轻时，属于丢人堆里儿，没人能注意的那种产品经理，但人就是如此有趣，越平凡，往往越激进，那时观主满脑子是想做管理，去管着一摊子事儿，去试试“高高在上”的感觉。

记得当时，X星集团的电商事业部因为发展迅速，遇到了一个问题，就是整站的用户体验跟不上来，因为是与集团配套的电商平台，集团有着自己成熟的传统线下产业链，许多线下服务的理念，在互联网的大环境下，显得有些捉襟见肘，这里面除了专业和理念的不统一，更多的是弄潮儿和老古董之间的相互排斥。

于是，观主认为机会来了，和当时的直属总监提议我们产品部去接这个山芋，并和个愣头青似的，提了一大堆见解和想法，且不论对错，当时总监出于爱护和信任，也是基本认可的，就说让观主去牵头整改。

观主当时满口应着，但是回头儿，就没动静了，我相信，这理由一说，大多数小朋友都会认可，公司没给授权啊！也没给title！更没给资源啊！

当那个提议被认可的一个月后，总监有次开会问到观主，观主就是如此回答的，当时，满脸的委屈，感觉就是让马儿跑，又不给马儿吃草，总之丝毫不觉得理亏。

会后，总监私下找观主谈了，当时原话是什么，已经记不清了，大意就是：你那么年轻， 什么也没做出来，就希望公司给你各种匹配的资源和权力，这肯定是不现实的，公司无论大小，没必要在一个没看出符合能力和要求的新人身上，去试错，除非你已经证明了，所以，现在是你的机会，你应该先趁着大伙儿不注意，先把这事儿做成，到时大家都知道是你主动做成的，公司认可了结果， 必然会给予你想要的。

这番话，很透彻，但是当年的观主，还是看不透，就好比现在读着这些字的小朋友，你可能也不理解，不过那时的观主，没的选择，于是就大刀阔斧的一个人闷头干了起来，把这份儿没人认领的工作给接下来做了。

幸运的是，半年后的事实，证明了这样做是正确的，集团认可我在这件事上勇于主动请缨，并把事做的很好的基础上，给到了一个用户体验官的虚职，并成立了专项组，让我可以跨部门调动资源来继续推进整站体验的优化。

总结：观主从以上那件事儿开始，就深刻的理解了，当你职场上渴望得到一些荣誉、地位、权利时，请先证明你的能力，当你能cover一件事儿时，自然它对应的一切，都是属于你的，这不就和当年的“圈地运动”一样吗？在太阳落山，马儿跑完之前，不论归属，等真正的站在那片土地儿上（cover整件事）时，你就是那的“领主”！

所以，小朋友们，老生常谈，职场上，多做，少说，观主工作里一直秉承这点，也见过很多小朋友爱和我讨价还价或者谈条件，但是这样，其实不好！

---

2.为什么很多人付钱去参加各类线下行业交流？

看到最近各类行业交流活动颇多，身边很多朋友竟然付钱去参加，突然想到以前的一些随感：

曾经总结过哪三类人需要和喜欢参加各类外部行业社交活动：

1.本职工作其实不需要对外，但主客观原因导致郁郁不得志或在事业上后继乏力，亦或是工作时间短，渴望探知世界的，前者要注意近期是否想离职，后者多位一些工作不久的小朋友。

2.本职工作需要外部社交来维持和拓展，一般是市场啊、猎头啊、媒体啊这些，社交是他们的工作属性之一。

3.目前自己是合伙人或者有自己事业，需要发声让人知道的，需要吸引市场和投资人目光的。

其余的，说认识人，作为一名产品人，我反正觉得，自己能力够强，自然而然会有朋友在你身边聚集；想学东西，我宁愿自己多做多想，实战得来的才真正有价值。

况且，公司里你的项目，你真的做好了吗？你真的每天八小时100%投入了吗？你真的把你工作当你的梦想去做了吗？如果都是肯定的，你哪来时间参加活动？？？

说到底，真实世界是残酷的——你能接触到的人脉，其实都不是你真正需要的。

感叹现今所谓交流，社交已远大于学术，已无什么意义，往往可以看到一群毫无实践经验的吊书袋，到处“坑蒙拐骗”，看似理论满满，实则套路颇深，误人子弟啊！

（且看下回分解）

2016.8.5

1.回昨晚提问：某宝为何把失效物品也计算入购物车总数量限制？

1）首先，往前多思考一步，相信有些小朋友会奇怪为什么购物车依然保留失效物品？

原因有二：

a.任何设计，在现实中，是可以投射到具体事物上的，是可以相互对照的。

互联网的发达和演变，不是在创造，更多的在于改造，人们本质的需求和行为模式没发生变化，好比超市有购物车，用户把东西放进去，最后去收银台结账，于是电商平台也做了购物车，延续了线下购物车的价值和功用，而对这个购物车中物品的操作权限，线上线下是保持一致的，只有用户主动行为可以去改变，这是一种对用户行为的尊重。

b.从用户体验的角度，任何数据层导致的表现层变化，必须清晰的让用户认知理解，就好比购物车里的物品，在用户未知的情况下，哪怕失效了，也不应该被系统自动处理，这是一种对交互的思考。

2）那为什么购物车会设置商品上限？

这个问题记得之前有咖友提过，其实说白了，很多功能在设计出来后，大家会发现和去赋予它很多主观价值，但客观的说，在最初的设计阶段，有时可能只是开发和产品说，这里的数字，出于安全性，必须设个上限，产品想了下，那就设99吧，仅此而已。

观主喜欢叫这类设计为容器设计，很多场景和控件和功能都会遇到这个概念，说白了，输入框也是容器，容纳文字，只要是容器，就有大小，出去安全性和数据溢出的考虑，必须设定一个阀值。

有人会说，设定一个上限，会更好的去引导用户行为？并但是这个点，无非刺激用户去review之前的历史添加，去做更新，在这个过程中，可能产生关联性的兴趣延伸行为，不是不对，就是成本太高，条件较难触发，我们还是回归本质的好。

3）最后回答文首的问题，为什么失效的也算进总数？

结合上面的答案，显而易见为了三个原因：

a）如果失效的不算入总数，出于容器设计的考虑，依然要给失效物品设置上限，上限这个事，避免不了，设置两个意义不大。

b）根据上一点，如果仅仅设置有效上限，失效的单独计算（包含设置上限和不设置上限），某个商品如果，失效后，移出生效的容器中，再把生效容器灌满，即重新加满，失效的又生效，是加入生效还是不加入？加入是顶替某个还是溢出？

c）失效和有效的是两个需求对立面，而在产品设计层面，我们应该主动引导用户去管理失效商品，通过共享上限，去督促用户自发的维护，是十分有必要的。

（且看下回分解）

2016.8.4

1.如何对一个线上平台，做用户体验优化规划？

背景：一个类X宝的大型电商平台，线上产品的业务模式已经成熟，同时迭代不断，有拓展新的方向，也有深挖之前的功能，但是长期用户体验反馈不佳，公司高层开始下决心改，作为一条产品总监，该从哪几个方面规划这件事？

1）确认阶段：用户体验的阶段从无到有，到可用，到好用，到依赖，一般很多产品前期赶工，堆积了大量为了时间和业务妥协的不良体验，有些是未思考周全，也有些是降低了开发成本，基本阶段都处于有和可用的阶段。

2）收集问题：改善体验，要快准狠，不要去学理论派，把一个产品重新分析和思考，这样太慢，没等你做完，高层就急不可耐了，先速度让所有人看到变化！

动员不同渠道获取反馈，速度要快，充分利用高层对该事的重视，协调资源进行问题的收集，用户体验改进最怕的是问题来源不全，可用渠道一般有：

a）新员工（包括入职不久的）做体验反馈；

b）ued团队做可用性排查；

c）各种渠道的用户发聩；

d）内部同事的反馈；

e）高层的最不满之处（你会发现根据他们的背景、责任不同，大家care的点差别很大）；

f）产品经理自查。

当然可能会有其他渠道，尽可能多收集问题。

3）解构问题：问题不在多，但是如何快速推进改善？如何有效的真正改善？如何合理分配人力？取决于如何分解问题。

分解问题，有很多维度，在用户体验的问题上，要从多个维度结构问题，然后综合比较，才能更好的有效规划，一般维度有以下几个：

a）问题类型：

表现层：认知释义问题、信息结构问题、视觉表现问题；

逻辑层：页面承接问题、流程断点问题、功能缺失问题；

交互层：直接交互问题、间接交互问题、交互性能问题；

业务层：业务流程问题、商业逻辑问题、服务设计问题。

b）体验影响：

急需改进（急）：不改要死人，要亏损，要被骂。

必须改进（高）：暂时不死人，但是长期下去有问题。

值得改进（中）：不改问题不大，但是改了会有明显的收益和好处。

考虑改进（低）：锦上添花，可改可不改。

c）改进成本：

需要紧急插入（最高优先级，先改了，别等催）

可以顺便改进（可以顺带着放在当前需求内做）；

需要单独改进（按改进难易程度排序）；

需要专题研究。

*从产研测的成本和排期角度出发，预估改进成本，毕竟你不可能脱离现有业务需求来单独改进用户体验，BOSS们永远是，嘴里喊着要改进，甚至不惜放弃业务进度，但是真的等你放弃了，你就发现，你也被放弃了。

d）改进方式：

定规范修改；

一次性修改。

e）业务影响：根据所属模块，进行划分，对比产品排期的优先级（产品排期一般代表了业务层面的优先级），进行排序。

4）综合排期：根据解构完的问题，综合以上的维度，进行排期，推进修改。

这点，不想展开说，因为牵涉项目经验、团队能力、沟通协调和资源掌控问题，每个团队和具体问题，都会有自己的一套思路，但是相信各位童鞋根据上面的几个方法，已经可以很清楚的掌握问题，并让高层和所有同事都看到这些问题，并清楚知道这些问题的改进价值和成本，在这样的大前提下，又回到了取舍的问题上，相信本着一个目的，如何取舍，总会得到解决。

最后总结下：用户体验的优化，核心要点是『快』，快速的做出反应，并让所有人感受到你的快，不要等着BOSS再来催！

（且看下回分解）

2016.8.3

1.如何优雅的对10多条产品线的，近100个月度需求进行排期？

今天把所有需求方，拉一块儿，排排坐，近百个当月需求，列在一起，让他们自己按模块一个个排序，基本就是12345这么的排，这个阶段比较简单，因为一般同一模块都是一个需求方，自己定自己需求的优先级不难。

第二步，把所有排完的需求，做筛选，都是1的列出来，都是2的列出来，继续定1下面的优先级排序，以此类推，结果，就可以买包瓜子，看需求方排序了。

这个时候，就会发现同样是1的需求，各模块都有，大家就会开始排先后，这个时候产品该给予建议和参考，协助去排序。

总结：产品团队，手上的活，不停即可，核心是轻重缓急，管理者要学会把问题抛给外部，而不是自己闷头苦想去定优先级，对需求方来说，什么都是紧急重要，要学会分解对比出，相比某些需求，哪些更重要，没有这个条件的排优先级，是不可操作的，最终目的还是有效支撑业务发展，在有限时间里做最有意义的事。

进一步的就是，当发现有两个都是1号需求下的1号需求，即1.1时（最高的优先级），都需要同一名产品经理负责，管理者要妥善的做内部调拨。

---

2.面试一个小朋友的感受，请其余小朋友注意：

挑几句话，有扣分项，有加分项，请各位面试注意，其实回头想想，自己年轻时也是辣么自信！！！

1）“这里没人在乎公司产品，大家都偷懒，我觉得没挑战，我还年轻，不想养老”——加分，但是要婉转谦虚，多说自己，少论他人！

2）“高保证、产品思路、技术了解、审美定性、用户体验研究、运营等等，我都在做”——扣分，你工作多久你的面试官很清楚，除非你谎报，同时能面你的，基本也是你这个职业线上比你资深不少的，说的你啥都会，面试官心里其实只是笑笑而过。

另外如此之杂，代表的就是没有专长，有时时间不代表沉淀了多少，但是深厚的沉淀，背后必然有时间在起作用！

观主年轻时，也爱和人说自己做这做那，很多人劝我改简历，少说不相干的，多专注一个领域，我不信，结果走了很多弯路，但是幸运的是，坚持下来后，量变会产生质变，不过这个代价，很大很大，奉劝考虑清楚。

3）“作为XX岗位，没任何团队支撑，起不到作用”——扣分，起不到作用说明你没做好，你只能婉转的说，你想发挥更大的作用，正面一些吧！

总结：观主面试人和被人面试经验很丰富，观主觉得，面试官普遍喜欢爱夸人的孩子，学会感恩和善良，很重要，你可以因为年轻气盛而有些焦躁和过分自信，但是切莫自大，更多的体现你的主观意愿吧！

（且看下回分解）