今晚想给实习生整理点资料，好让他对产品经理有更全面的理解，更快上手，因为这样我就可以少干活，多摸鱼hhh~找着找着，找到了一份1年半前老板让我写得《我在群接龙做产品的十条原则》。
当时的背景是新人大量入职，公司从30人一下子窜到了100人，需要沉淀下一些共识，也就是产品原则，让彼此协作效率更高。憋了一星期后，我终于写完了，但也就仅限内部分享过，今晚我再看的时候，发现有一些点还是可以的，代表了我一年半前的思考，不过我也在成长，也在不断刷新自己的认知，这就避免不了局限性，姑且看之吧：
自2018年10月21日加入群接龙，已有1年半，期间我们经历了近百次迭代，踩了很多坑，也做对了一些事情，从中沉淀下许多有用的经验，我总结为10条原则，供大家参考，也方便新同学快速了解群接龙。
下面的原则未必是对的，也会更新迭代，也不是为了炫耀因为我们有这些原则，所以群接龙现在做得很好。恰恰相反，正是因为我们缺少共同遵循的原则，导致现在群接龙的体验还磕磕绊绊，离用户对我们的预期还有很大距离。
下图是我在群接龙开展工作过程中的业务流，以下原则根据该图展开：
[图片]
1.产品经理应该把一半时间花在“需求定义”上
下图是产品经理的常规工作流，输入的是需求，输出的是产品方案。“需求定义”、“产品设计”、“产品运营”、“沟通协调”是产品经理的四大主要工作，但下图有一些小缺陷，没有表达出各工作的权重。
[图片]
当我们反思踩过的坑，就会发现无论是产品设计时的混乱、产品运营过程中的扯皮或沟通协调过程中的共识不一，都是因为需求定义不清造成的。我们需要不断思考“你究竟要解决哪部分用户在哪些场景下的哪些问题”、“这些问题本质上是什么问题”、“这些问题是否值得被解决、是否值得现在就解决、要解决到什么程度”。所以，下面的产品经理工作流是更贴切的（仅针对非管理岗的产品经理，管理岗可能会花在沟通协调上）：
[图片]
2.确保你的需求来源是充分的、信息是一手的
[图片]
需求从性质上分两种：用户需求与商业需求。发现商业需求是比较简单的，你多了解公司的战略、公司近期的目标、用户会为了哪些痛点而付费，愿意付多少即可。
[图片]
而发现用户需求需要确保你的需求来源是充分的、信息是一手，当你保持敏感地浏览这些信息时，就容易发现有价值的需求，推动立项并上线。
就我而言，目前的信息渠道包括：
（1）微信群。
我在50个团长群里面（我有多个微信，还不至于干扰~~），每天我会浏览一下她们在聊什么、关注什么、想得到什么。
（2）微信好友。
我被1000个团长/品牌商添加了微信好友，她们遇到问题或者有需求未被满足时，会向我反馈。
（3）微信公众号留言。
我们的群接龙公众号已经200万粉丝，每天的留言会有几百条，都是用户火急火燎、救助无门留下的，定期浏览一遍就会知道常见问题。
（4）浏览团长的朋友圈。
在浏览团长朋友圈的过程中，你就会发现她们愿意炫耀什么。
（5）群接龙学堂的互动反馈。
我们有时候会发布接龙与团长们互动，她们的留言也是她们的心声，值得关注。
（6）客服系统的问答对话。
我们需要定期与客服同学沟通，了解一下目前哪些客服问题比较频繁，是否能够通过产品的手段解决。
至于如何处理用户的反馈，俞军说的一句话很有意思，供你思考：用户的反馈我一条不漏，用户的建议我一概不听。意思是要听问题，不要听解决方案，这里面需要你的归纳与抽象。
3.动手前确保你经过充分的调研
[图片]
产品经理是需要不断做出正确决策，让事情美好发生的人。人的决策跟计算机差不多，都是“数据*算法”，我们的数据是信息量，算法是认知能力。
[图片]
为了让信息尽可能地对称，你可以选择亲自下场成为目标用户，比如成为团长；可以到现场实地调研，比如到团长的店里或者仓库里，观察他们真实的业务是如何展开的；也可以做用户调研、做竞品（行业）分析、做数据分析。
需要注意的是，用户调研不是有了某个需求才展开的（时间上你会来不及），而是在日常工作中就可以随时开展，最好的用户调研是随时随地调研。其次是要带着问题去调研，而不是漫无目的地漫谈，你要反复提醒自己“我要通过这次调研了解清楚哪几个问题”。
关于用户调研还有一个故事，我印象很深刻，某互联网公司老板问新来的产品怎么开展工作，然后他回了一句：在没有针对100个目标用户充分调研前，我不会去开展任何的工作。
4.评估优先级的4种常规方法与5种思考框架
[图片]
评估优先级是一门“技术活”，最能体现你对业务整体性的理解，我常用的有以下4种方法：
（1）需求价值公式：用户价值 = 需求的刚性 * 需求的频次 * 需求的广度 * 竞争对手有没有替代方案。
（2）KANO模型：需求分为基本型需求，期望型需求和兴奋型需求，满足用户基础必备需求用户并不会满意，且满意度效益递减；满足用户的期望型需求用户会逐步满足，且满意度线性增长；满足用户的兴奋型需求用户会非常满意，且满意度递增。
（3）CFS评分：C：Commonality普适性：在我们的用户画像中，有哪些类型的用户会使用该功能？预估用户数大概有多少？F：Frequency频繁性：这个功能可能被使用的频次，是天天都会用到，还是偶尔一次？S：Severity严重不可替代性：这个功能有没有可替代的方案，用户没有这个功能就无法正常工作了？还是无关紧要，锦上添花的功能？CFS评分与需求价值公式是类似的。
（4）重要紧急矩阵：重要紧急的马上做，重要不紧急的按规划来，不重要紧急的优先做，不重要不紧急的可以删掉。
以上4种常规方法都会在潜移默化中使用，当一个新需求“飘”过的时候，会被迅速对号入座，确定一个大概的优先级，这足以应付常规性需求。而当我们面对一些复杂性需求时，就需要比较深度的思考，这里面也有5种思考框架供你参考：
（1）多想想团长的本质需求什么？开发资源紧缺的时候应该抛弃非本质需求，因为团长永远关心的是：
<1>能不能帮助我更好地运营社群？给我带来更多的成员，留住现有成员。
<2>能不能帮助我多赚钱？以前我赚1万，用了你们群接龙，我能赚10万。
<3>能不能帮助我提高效率？以前我处理这事要1个小时，现在用了群接龙，1分钟就搞定了。
<4>能不能帮助我学习成长？以前我不会运营社群，现在有了群接龙，成了社群老炮儿。
（2）多想想我们群接龙的初心--让消费回归简单、回归社区。我们做这个需求是会让消费变得简单，还是变得复杂？
（3）多想想我们的独特价值是什么？用户之前是因为什么而选择了我们（简单、高效、群体氛围、真实），我们现在如果做了这个需求，是会让他们更愿意使用，还是选择抛弃。
（4）多想想这需求属于竞争的哪个维度。都说最好的竞争是降维攻击，那低维竞争就是做功能，很多竞品功能比我们多、设计比我们炫酷、主页不用付费、服务费可以减免（甚至补贴），这都是低纬竞争，如接龙圈、接龙管家、接力Go、快团团等（有时候功能越做越多，越做越复杂，反而会给后来者颠覆式创新的机会，有赞可能没有意识到这个问题）；中维竞争是做数据。让数据产生价值，包括顾客的交易数据、商家的经营数据等等，沉淀的数据越大，迁移的成本就越高，用户就越难离开我们；高维竞争是做关系。”缺好货“是一个大痛点，谁能更早地让团长搭建稳固可靠的关系、链接到源源不断的好货，谁就能脱颖而出。
[图片]
（5）最后可以想一下接龙是什么？接龙有什么特点？你做的这个需求是在放大接龙的特性，还是在模糊它的边界？
<1>简单。接龙是简单的，这需求是否会损害到群接龙的简单性，让其越来越复杂？比如为了页面的好看，强迫用户创建商品时一定要像淘宝有赞那样上传图片。
<2>群体氛围。接龙的群体参与感是很强的，这也是我们比起很多商城转化率更高的原因，你的新需求是在增强还是削弱群体氛围？
<3>真实。接龙是真实的，每一个参与的人在什么时候参与了什么项目都展示得清清楚楚，如果有商家为了虚荣的数字，让你弄点假数据，而这种假数据确实在短期内有收益，你会不会动摇？
<4>裂变性。接龙自带裂变性，这也是为什么我们一分钱没花，每天新增几十万新用户的原因，要多想想如何放大裂变性,而不是把这点丢弃了。
5.明确设计目标与实现路径
[图片]
当我们完成需求定义以后，进入到产品设计，首先要做的就是明确设计目标与实现路径，设计目标往往跟需求背景对应的，用户存在哪些问题，我们这个方案要解决到什么程度？
其次是实现路径，当我们有了设计目标以后，很可能不是一步实现的，而是分步实施，但我们需要在一开始就有整体的规划，要有设计蓝图、架构图、以终为始，上线以后观察数据，让结果逐步向我们预设的目标靠近。
6.与开发共同梳理用例与业务流程
[图片]
具体设计是从用例开始的，用例指的是“谁可以用系统做什么，从而获得一个明确的业务目标”，在需求分析阶段用例有很重要的作用（能够确定系统的范围），整个开发过程都是围绕需求分析阶段的用例进行的。可见，与开发同学在用例上达成共识就非常必要，可以避免开发过程中各种业务纠缠、欠缺考虑或者过度考虑的情况。
而业务流程描述的是“系统内各角色、各模块以怎样的顺序进行交互，从而完成各自业务目标，实现总目标的”。你需要对整个业务进行分析，并考虑3个问题（1）业务涉及到哪些角色？（2）每个角色都有哪些任务？（3）各个角色之间是如何交互的？
开发也需要参与到业务流程的梳理中，原因在于能从业务流程梳理的过程中就想清楚时序图、状态图等软件设计图，而不用自己揣摩想象，导致开发时间延长或者偏离业务。
7.原型/UE/UI需“符合认知、目标明确、重点突出、层次分明、体验连贯、一致性、情感积极...”
[图片]
交互设计是“定义系统如何响应用户请求的”，属于“战略层、范围层、结构层、框架层、表现层”中“结构层”的范畴。战略层要解决的是“用户的需求是什么，我们能得到什么”，范围层告诉我们“什么样的功能将满足用户需求”，而在结构层我们要面对的问题是：“具体识别出用户心目中至关重要的信息 ”。
交互设计中最关键的是符合认知，即追求产品概念模型与用户心智模型的匹配，让理解成本降到最低，一切都是用户脑海里熟悉的元素，用户希望看到的是“1+1=2”，而不是“&#@%￥”。
案例：填表接龙 VS 互动接龙
UI设计属于“框架层、表现层”的内容，讲究“形、色、字、构、质”，这里面的学问很多，如“目标明确”、“重点突出”、“层次分明”、“体验连贯”、“一致性”、“情感积极”、“场景式触发”.....我们产品经理没有UI同学专业，但也要懂基本的概念。
案例：新的接龙活动选择页 VS 旧的接龙活动选择页
8.项目上线前需确定成功标准，并用数据去验证或者驱动迭代
[图片]
所谓的成功标准是从未来看现在，思考到底达到怎样的程度，我们这个功能就成功了，并用数据去量化这个程度，只有确立了成功的标准，才便于我们用数据去驱动迭代，一步步靠近“成功”。
案例1：物流模块的成功标准。
C端用户消费时永远关心的是“多、快、好、省”，社区团购SKU比不过淘宝、物流速度比不过京东，便宜比不过拼多多，而用户还是选择通过团长这个渠道购买，其实满足的是“好”、与“省”，从这里买的产品更好，因为有团长精挑细选；其次是更“省”，但不是更省钱，而是更省心。我们有优势，但也要确保在物流这种基础体验里不要落后太多。
所以，我们要方便商家们导入单号、甚至直接打印快递面单，让C端用户能够实时查询物流。当有一天，80%快递发货订单都能实时查询物流的时候，我们物流模块就算“成功”了。
案例2：团长帮/品牌帮的成功标准
我们每天都能看到很多团长的询问：“这里有没有帮卖春笋的？”、“这里有没有武汉猪肉供应商？”、“这里有没有儿童绘本供应商？”，我们可以想象有一天，当没有团长这样询问的时候，我们团长帮/品牌帮就算“成功”了。
如果我们要量化这种“成功”，根据云集的标准，中国中产家庭至少需要3000款精品商品才能覆盖基本生活，我们的场景要更广泛，可能要有上万拥有精品商品的大团长/供应商入驻才算基本成功，那时候，团长们都能匹配到拥有好货的大团长/供应商，并建立关系。
9.项目上线前需要内部宣讲，上线后需要外部推广
[图片]
在项目上线前，需要与运营、市场、客服等兄弟部门进行宣讲与演示，让他们做好上线准备，因为他们是在第一线面对用户的，不能突然上了一个新功能，而他们完全不知道。
项目上线后需要进行外部推广，最极致的效果是“让这个功能的所有目标用户都知道，并且了解怎么用”。
[图片]
失败案例1：活动页多商品展示
该功能在设计过程中就缺少与运营等部门的沟通，上线后运营同学也不知情，导致一部分用户不满，需要浪费开发资源进行二次优化。
失败案例2：一品多规
该功能甚至没有经过严格验收，运营同学也没有准备好推广内容，导致上线后各种Bug与交互体验问题、客服咨询问题等等。
10.从互动中收集反馈，从数据中发现问题
[图片]
新功能上线后，应该第一时间与目标用户取得联系，让他们去体验，听取他们的感受，是否和咱们设计过程中沟通的一样，是否彻底解决了问题，是否还有需要优化的地方。
新功能光听用户反馈是不够的，那未必就反应现实，我们还需要看数据，从数据中发现问题。互联网圈子流传着一句话：“平庸的产品经理看数据只是为了证明自己对与错，优秀的产品经理善于发现数据与数据间的关系，推导出反应现实的因果关系，洞察问题的根源，从根源上解决问题”，其实这才是看数据的价值。
关于如何看数据，还有一些诀窍，比如“定位不出问题，往往是因为你用户分群分层不够细（分群分层分析是数据分析的第一步）”、“没有经过交叉对比的数据，往往会失真（真实性是数据最基本的要求）”、“不要怪数据驱动不行，那是你作为驱动的数据指标选得不行”、“如果设计目标本来就不可量化，比如做认知，那其实是无法通过数据验证的”......
以上就是我在群接龙一年半积累的10条原则，希望对你有用哈。
对互联网、创业、产品经理感兴趣的同学，还可以到我的星球玩哈：
[图片]