B端产品方法论「b端最火的产品」
今天给大家普及一下B端产品方法论「b端最火的产品」相关知识，最近很多在问B端产品方法论「b端最火的产品」，希望能帮助到您。
编辑导读：产品经理是一个快速成长的岗位，接触的工作越多，总结的经验越多。本文作者从一位小白成长为B端产品经理，根据自己的工作经历，总结了一套产品经验，希望对你有帮助。
一、首语假设一名产品经理需要在一小时内完成一个任务，那么前五十分钟应该花在需求的分析上，而方案输出应该只需要最后的十分钟。
距离上次发文已经有一年多时间，在此期间经历了暑期实习、秋招、毕业典礼等多个节点，在疫情的影响下仿佛一切都打上了独特的烙印，既感慨自己终于成为一名产品人，也感慨时间飞逝。
目前我在一家B端saas企业做产品，至今大大小小产出并上线了上百个需求，出于个人习惯，想总结一套方法论方便后续需求设计，减少重复工作量的同时也能让自己有所沉淀，夯实基础能力。
引用的这句话是我最近在《缔造企鹅》中读到，结合自身的工作内容深有感触所以分享给大家，也作为本篇文章的主题。基于自身处理需求的全流程，我将其拆分为如下节点，本文内容主要为需求前期方法论。
前期——发现需求、提炼需求、辨别需求、管理需求中期——设计需求、把控进度后期——上线后跟进二、发现需求发现需求这个命题比较主观，我在工作的过程中就碰到了包括用户调研、用户反馈、PM自身思考、竞品分析、体验产品等多种渠道。个人觉得不需要纠结，每种渠道都有自己的优劣，或许“发现需求”可以理解为各种渠道相辅相成，例如PM进行思考后通过调研等方式验证想法是否可行；也可能是通过调研等方式发现问题，转而经过自己的思考去验证问题是否存在。
“不管黑猫白猫，能抓到老鼠就是好猫”。可以先从定期收集更新记录、与用户简单交流开始。重要是培养自己对于用户、竟品、行业的敏锐度。
三、提炼需求用户A：我想要实现xxx功能
PM：噢，懂了，我觉得应该是这个意思，马上出需求
——上线后——
数据极差，当时反馈的用户也不买账，不禁开始怀疑人生，为啥我做的功能没人用？？
在PM日常工作中，我们会收到很多来自四面八方的需求信息，切记带着有色眼镜去处理信息，避免成为“自嗨型”产品经理。
了解清楚问题背景以及诉求，如果有必要可以多次求证（也需要一丢丢的换位思考能力，不要过于打扰别人hh），务必做到客观、真实、清晰。例如用户A跟你说希望在开车的时候也能用手机打电话：
场景：一个人在开车过程中，需要进行通信用户行为：一只手开车，另一只手操作手机目标：快速且便捷的操作手机，最好是不需要分散太多注意力效果：用户打开应用之后，直接长按就可以实现语音操作将繁杂的信息提炼为：用户A在xx场景下，想通过xxx实现xxx诉求，以达到xxx的目的。
四、用户需求≠产品需求用户需求并不等于产品需求，这是很多同学存在的误区，想要将用户需求上升为需求文档级别，还需要经过市场与商业的考虑。
例如提炼出的某个用户需求是“我想上传的学习视频能够设置付费才能播放”，那么我们首先要问自己两个关于市场的问题：
a.相同的诉求有多少量？（市场容量）
特定条件下，相同的用户需求集合已达到一定量级，例如例子中的知识付费需求，我们跑数据看到产品内教育行业用户占比巨大，且有30%的用户希望视频付费，那就意味着市场容量较大，可以继续了解。
b.是否已有解决方案？（市场环境）
这个步骤主要是要了解两个点，直接or间接竞品有没有实现知识付费功能、实现的方案是不是成熟？
那么怎么样的需求能被称为商业需求呢，商业需求是为实现商业目的，围绕产品产生的运营或业务性需求，例如知识付费功能可以帮助商家打通线上获客—转化路径，增加了产品售卖方式，满足业务经营。又或者是帮助商家节省了人力成本跟时间成本，也属于变相实现商业目的。
一个好的产品需求应该满足用户、市场，同时兼顾商业。
五、需求归类&管理过滤到这一步大概率是真需求，能够将其放进个人需求池中，作用有两个
随着整理次数以及数量的增多，渐渐会在脑海中形成一张地图，上面记录着哪个部分比较多什么类型的问题，用户关注什么？增加对产品的熟悉度好记性不如烂笔头，你甚至没有办法记起上周用户调研时提到的问题，更不用说好几个星期乃至一个月前了，养成记录的习惯，对自己负责更是对产品负责需求前期调研可以到池子中试着搜索下，能帮你补全场景或者发现该需求上游环节、下游环节存在的问题，提高需求产出质量由于笔者是做b端saas产品，从一个垂类场景切入结合上企业业务需求，产品涉及的功能模块较多，再加上踩过好几次坑。目前采用如下图所示字段对收集回来的需求进行整理归类
类型：分为功能、样式、运营、数量、体验、tips六个属性，该字段的目的是对需求进行粗分类，即需要新功能来满足还是小需求fix掉，结合记录时间甚至可以评估某个时间段内什么类型需求较多所属模块：指的是产品哪部分的需求，最小粒度到具体功能模块，该字段的目的是方便筛选哪个模块需求出现频次最高，集合“类型”字段甚至可以优化整个用户路径不局限在小功能点上反馈场景：言简意赅说明需求背后的场景，方便溯源时定位问题所在优先级：目前这个字段我仅会在紧急需求例如风控、跨部门协作时备注，平时不做填写。因为一开始在这个字段踩坑，会在记录需求的当下进行主观判断高、中、低，但需求管理是一个长时间的过程，反而会疑惑当时定优先级的初衷，很少东西是一成不变的，导致没有达到“管理需求”目的记录时间：何时记录该需求，方便结合“类型”、“所属模块”做周期性的复盘以及整个用户路径的优化上线时间：需求上线时间，由于需求进入规划状态会纳入另一个表格管理，所以没什么填写的必要，后续考虑去掉该列降低干扰备注：随机应变，懂得都懂任务进度：同“上线时间”。考虑废弃降低干扰至于需求管理我是有两份表格，上文提到的“个人需求池”以及“项目管理表”，前者记录未规划的需求，后者按不同的项目分sheet记录已经在工作流程中的需求。两份表格会在每周周一早上、周五下班前更新。
甚至我会在“项目管理表”中单独开一个sheet记录当前版本上线的需求，目的也是为了监控进度，保证需求按质按量上线。（遇到推不动的情况，也能提前向上反馈，避免撕逼）
六、需求如何策划目前我接手过的需求分为三大类
功能类：实现xx功能，相对来说需求调研、逻辑能力要求较高；样式类：通过xx功能去还原xx样式，相对来说逻辑没那么重，抽象归纳以及需求细节能力要求较高；运营类：通过xx手段去达到xx目的，相对来说全局意识、数据思维、脑洞要求较高；本篇文章会着重讲功能类的需求如何策划，样式与运营类的会单独开一篇文章说明
七、旧功能梳理我负责的产品至今已有十一年，期间经过n个pm的手，记录工作也做的比较差，经常会出现“货不对版”或是“一句话需求”的情况。所以我在策划每个需求的时候，都会主动花时间梳理旧逻辑。
无论是什么类型的功能需求，即使是全新的功能，我也非常建议大家去输出对应功能模块的两种脑图。“信息结构图”和“功能结构图”。
这两种类型的脑图在搜索引擎中已经有无数篇学习文章，还记得一开始学习产品知识，经常会弄混这两种类型的图，后续基于琢磨与实践，也有了自己的理解，下面会简单说说两者的意义与区别。
1. 信息结构图信息结构图指的是穷举页面/功能中每一个元素，最小粒度我一般用设置项。要做到事无巨细，防止遗漏。为了便于大家理解，我举了个微信的例子，微信中「设置」-「我的」tag信息结构图如下图所示，大家可以对照着产品琢磨琢磨。
信息结构图可以帮助我们了解旧模块的“构造”，特定的选项下是否有个性化的设置，能够高效的了解旧模块/功能全貌。
2. 功能结构图百度百科：按照功能的从属关系画成的图标，在该图标中的每一个分支都被称为一个功能模块。功能模块可以根据具体情况分得大一点或者小一点，分解最小功能模块可以是一个程序中的每个处理过程，而较大的功能模块则可能是完成某一个任务的一组程序
上面百度百科的定义有些绕，我自己理解功能结构图指的是页面中所有的功能，最小粒度是用户可使用的功能。类似鸟瞰的视角。同理在微信中「设置」-「我的」功能结构图如下图所示，大家可以对照下，相比信息结构图，两者之间的区别是什么。
揭晓答案：功能结构图与信息结构图的区别是前者注重抽象信息，后者注重罗列信息。
通过信息结构图与功能结构图的梳理，可以帮助我们从纵向、横向两个维度了解当前功能模块的“前世今生”，避免在策划阶段走弯路，提高工作效率。
当然，如果是一些逻辑非常复杂的功能模块，也可以去公司研发管理平台（我司是tapd）以功能模块为关键词去搜索下历史需求，看看是否有AB测试或特殊的兼容逻辑。
产品经理梳理完成后，如果有条件可以让有经验的测试、开发同学帮你稍微看一眼，防止遗漏（开发过程中才发现的特殊兼容逻辑，导致方案部分推倒重来的经历，真的太痛了）。
八、新功能拆解8.1 需求调研想要理解需求，永远离不开用户、场景、诉求。我会将这部分分为内、外两个维度去介绍日常工作中如何进行需求调研工作。
8.1.1 内部
搜索工单&用户反馈&建议：
工单常见于平台型产品中，用户可针对使用过程中的问题、未满足的功能，通过文本、图片、参考链接等元素直接与PM沟通，PM阅读后会做出对应的回复，可以发起二次沟通，或者打上标签完结本次沟通。一次沟通等于一条工单。
现阶段我获取需求最直接最有效的渠道就是工单反馈。用户可以畅所欲言，甚至见过附上axure原型图的，对于PM也更利于管理，你可以在固定时间如刚到公司的半小时、临近下班的半小时集中精力处理。
在处理工单的过程中，大家可以猜一猜我回复频次最高的一句话是什么
「已经收到您的反馈，想了解下您是在什么场景下需要xx功能/有xx诉求呢，可以详细说说，若条件允许也可以附上对应的截图或链接，方便我们了解问题所在」
是的，在需求调研过程中，最忌讳PM想当然，“噢用户说的应该是这个问题，马上需求排期跟进”的思维不可取，虽然这样处理效率很高，但最后有很大可能你根本没有解决用户遇到的问题。
那要怎么做才能真正解决问题呢？
首先是了解用户；
我从处理第一份工单至今一直保留着一个习惯，就是会抽样去看工单归属用户的实际使用情况，尤其是考虑排期的工单需求，通过抽样我可以知道用户所在的行业、使用产品的目的以及使用的情况。例如用户提出了一个“非常紧急”的表单模块诉求，实际抽样中发现用户已付费，且使用产品的主场景并不是获客留客，也没有使用表单模块。那你就要留点心，这意味着这个诉求要么是必须型需求，已经影响到主流程无法使用，要么只是用户心血来潮，你可以带着疑问发起二次沟通。是不是了解用户后，看问题的角度不同了呢。
其次是明确场景；场景是时间与空间的结合，代表某个人，在某个时间点某个地点，做了什么事（起因、经过、结果）。
什么模块？哪个页面？如果是优化类的工单要以能否复现作为标准，如果是新功能要以能否理解作为标准。其实产品经理的工作内容，就是去创造新的目标场景，或是优化已有场景，并在这些场景下满足用户的需求
最后是挖掘诉求：
人永远是情感世界的产物，想要永远客观公正的做出判断是不可能的。就好像上文提到的工单例子，如果用户真的是心血来潮提出的诉求，我们花了很大成本去实现，那最后肯定是投入产出比较低的。
由于成本的限制，产品经理不可能无时无刻坐在用户旁边观察他的行为。所以我们要用各种方法去挖掘用户真实的诉求，在这里分享我经常用的「需求拆分法」给大家，例如：
“用户/我想吃麦当劳
PM/为什么？
用户/跑完步，有点饿（知道了场景和冬季）
PM/肠粉行不行（换了一个替代方案，看下能否满足）
用户/想吃麦辣鸡翅（发现了更深一层的需求，麦辣鸡翅是麦当劳的子集）
PM/麦辣鸡腿行不行？（替换掉解决方案中的一个元素，看下能否满足）
用户/想吃鸡翅（得到了更细节的需求）
PM/烧鸡翅呢？（假设麦当劳并不售卖烧鸡翅，所以找到了用户的替换需求）
用户/也可以”
….
ps：这个思路是之前在一篇关于需求调研的文章看到，觉得非常有意思便记录下来，一直沿用至今
这种类似打破砂锅问到底的方法，通过对用户回答的层层拆解，最后找到用户真实的需求，是比较有意思的。当然，上述内容只是方便大家理解挖掘的思路。在现实工作中几乎不可能会遇到如此温文尔雅的用户会耐心回答你的每个问题（要是真的遇到了，可以好好跟他培养下感情哈哈哈），所以我们得从其他渠道，例如抽样、浏览该用户每条客服会话内容去补充细节。那么在产品设计阶段，我们只需要去思考拆解到最后的问题即可。
总之在需求挖掘的过程中尽量做到”无我”，清空自己的主观判断，倾听用户的声音，不要掺杂太多主观意见、不要离开用户群尤其是核心用户群去判断需求，不要脱离场景去想需求，从用户提出的需求出发，去伪存真挖掘用户内心真正的目标。
搜索客服会话：
如果说工单是问题抽象化的表现，那么客服会话就是问题具像化的表现
客服会话指的是用户在使用产品时，通过不同的页面入口发起跟我司客服同学的聊天窗口，用户可以通过文字、图片等元素去发起在线沟通。
因为客服会话工具的时效性，所以相对于工单会有更详细的场景与诉求描述，方便PM获取有用的信息。
也可以通过搜索关键字的方式，抽样去看这个周期内有多少条会话与搜索关键词相关，从而了解用户与场景的共性，为挖掘真实需求提供燃料。
其他部门同事：
若需求内容与其他部门相关，或是其他部门同学提出，则需要主动发起询问，了解清楚事情的背景和目的，这里更多涉及沟通技巧方面的知识，仅举例接触过的坑，不做展开
ownship意识，即使发起方不是自己的业务，也要像自己产出的需求一样对待它；遇到问题，及时同步。（再小的问题也会造成连锁反应，降低效率）；不能随便给同事承诺，尤其是销售、客服等对外的角色，要学会让他们做阅读理解以及留多些空间给自己；8.2.2 外部
竞品调研：
可以毫不夸张的说，目前我们想实现的新功能，几乎99%都能在市面上的产品中找到类似的影子，所以竞品分析相对需求调研乃至整个产品工作流中都非常重要。
在我刚毕业的那段时间，还没有浏览竞品的意识，在做需求的时候偶尔看一看，直到有一次leader问我“xxx、xxx竞品最近的动作是什么？”我哑口无言。这样闭关锁国的行为不可取，不仅会让一个PM丧失对所在行业的敏感度，还容易陷入自我满足的怪圈。
所以我之后做的第一件事，就是把几个直接竞品的功能更新渠道找出来，按横轴-产品名称、竖轴-时间轴的形式，如下图所示。每周一早上抽十来分钟填一填更新内容。随着文档的一次次被编辑，我对竞品也越来越了解，知道它们这段时间都在拓哪个方面的需求，结合产品定位有更深入的思考；在做需求的时候也可以反应过来“噢，我记得xx上几周貌似做了个类似的功能，去看看先”，提高竞品调研的效率。
回到需求调研场景，如何通过竞品进行需求调研环节？可以用一句话总结：同样的需求或场景，别人的解决方案是什么，然后我们可以….
下面我会分成两个步骤聊聊具体做法：
第一：你调研的目的是什么/想通过调研获得哪方面的结论？
在这里先引用一个思维模型-黄金圈法则
黄金圈法则，又叫做why-how-what法则
外圈层：what圈层，是什么和做什么。指的是事情的表象；中圈层：how圈层，怎么做，是实现目标的途径和方法论；内圈层：why圈层，是为什么做一件事，是做事的初衷和核心理念；大部分人思考、行动和交流，都只是用到了最外层的what层，但是黄金圈法则的思考方式是从内向外，也就是why-how-what的方式进行思考。
在我们通过竞品进行需求调研前，首先要花时间想清楚调研的目的是什么，我们希望通过竞品获得哪些维度的参考？是场景、用户路径还是交互以及文案。
举一个真实的例子，我曾经想实现一个新样式，于是去遍历竞品所有的功能更新文档，去找对应的样式预设效果有哪些，整理好后在策划功能时又因为部分信息项不清晰，又回去找了一遍。效率很低不说，也有可能因为忽略了某方面的信息导致需求设计变形。
为什么会出现这样的问题，根本原因在于我没有弄清楚此次调研的目的是什么？也可以说对于目的的理解不够深入
实现一个新样式，表现层、框架层、结构层、范围层的内容都是需要关注的。所以大家在执行竞品调研工作时，不妨先花点时间想想自己要达到什么目的，需要关注哪方面的信息去达到这个目的，梳理出大致的框架，调研过程中也只是往框架中填充内容。
第二：找什么竞品？
对于互联网产品来说，基本所有的功能都能在市面上找到参考。但茫茫多的产品，我们如何有的放矢，增加调研的效率呢。在这里引入直接竟品、间接竞品的概念：
直接竞品：产品定位、用户群、价格等元素差别不大的产品，例如可口可乐和百事可乐间接竞品：间接竟品是指产品形式不同，目标用户群类似的产品，例如可口可乐和脉动参照品：两个产品不存在竞争关系，但是值得部分学习借鉴的产品，例如微博和推特我一般关注直接竟品和参照品，因为直接竟品的用户群与场景与自身高度重合，对方推出并迭代的产品肯定满足了部分用户的需求，所以参考意义较大。
相比与C端产品，B端体验成本较高，尤其是付费使用模式的产品，想要完成的体验用户使用流程是非常困难的，这时候我会把目光放到专注于某个功能的垂直产品中，也就是提到的「参照品」
例如tapd（组内的敏捷协作平台）需要优化编辑器模块，那么对标其他组内敏捷协作平台固然是个好方法，同时我们也要把格局打开，如果只聚焦编辑器（编辑）场景，那么垂类工具例如腾讯文档、飞书甚至wps、office有没有参考价值呢，肯定是有的，在某些场景可能它们更加聚焦，同时体验成本也较低，那么这个时候「参照品」也可以作为竟品维度之一去选择。
在对比「参照品」的时候，要牢记自己的调研目的，切勿照搬照抄。因为两个产品不存在竞争关系，所以解决的并不是同一类问题，我们不能全盘吸收，而是要回到自身产品中取舍。
客群调研：
目前我触达客群的方式有以下几种：QQ（群聊为主）、微信（群聊为主）、企微（私聊为主）
对于B端产品来说，用户沟通成本较高，原因是实际使用者跟管理者大概率不是一个人，且用户对产品的情感价值不高，更多认为是一笔买卖，所以会导致沟通变形。
每次我通过工单、社群帮助用户解决问题后，都会尝试附上我的企微二维码，引导用户添加好友，成功率70-80%吧，在“成功解决问题后，尝试转化”这个场景引流过来的用户质量还是蛮高的。添加为好友后，可以随时发起沟通。目前我的企微已经有几十号用户了，再给上对应的备注，例如“xx版本-id-反馈的功能模块”更方便我们后续识别。
出于个人隐私的考虑，我不建议大家在个人聊天软件上添加过多的用户，工作相关的还是尽量引流到工作软件中去。
产出功能清单：
功能清单是调研结束后的重要产出之一，按照用户主流程/分支流程，将功能结构图中的每个点拆解出来作为维度，进行备注，同时基于已有的信息赋予所有功能点优先级。
对于PM来说，提供了一个类似全局的视角去“鸟瞰”整个功能，涉及什么功能点，哪些比较重要需要一期完成，哪些相对没那么重要可以拆分到二期或数据驱动的。
对于开发等角色来说，帮助其了解需求内容的同时，也提供了兜底作用，增加需求的可拓展性。
拿我最近做的一个需求-功能清单举例，我常用的分类维度以及评估标准有：
工单&客服反馈数量：指的是[2.1 对内]中提到的工单、客服会话渠道反馈内容，这里转化成具体的数量，指的是反馈中直接match到功能点的数量。这里有个坑是产品经理一定要去看反馈内容并理解背后的诉求，不能想当然的只看标题或某几个关键字就关联上；x竞品支持：有多少个直接竞品支持该功能，数量越多越能说明这是一个通用类的功能，但也要注意结合自身产品定位和差异化打法思考；是否必须：该功能点是否在用户使用主路径上，若不支持断路的影响有多大；开发成本：该功能点的开发成本如何，是否有组件支持、是否已实现类似功能，不确定的话可以问问关系较好的开发同学；优先级：以需求目的、产品定位、差异化能力为主要思考方向，上述维度为辅助思考方向，对每个功能点标记优先级，并根据优先级对应后续处理方式；九、交互设计用户需要通过这个功能达到什么样的目的？我们如何帮助用户更快更愉悦的达到这个目的？
至今仍记得年初职级晋升答辩，评委问过我的一个问题和答案“你觉得怎么去评判一个交互设计的好坏？”“搞明白这个交互想让用户达成的目的是什么，再去看它有没有基于场景、用户特点去做对应的适配”。交互设计是PM日常工作中比较基础的环节，而两者又与用户体验息息相关，适当的交互与页面设计可以降低决策成本，从而更容易被转化。
我觉得交互这块要做好有以下几个点：
了解清楚用户发生行为的场景和我们预设的目的；脑子里有足够多的交互储备（用哪种类型的输入框？要不要收起、要不要给提示）；换位思考能力；分享一下我平时学习交互知识的秘诀：有效输入 归类整理 定时复盘，这里用到了与语雀-知识花园概念类似的个人体系学习方法，感兴趣的小伙伴可以在评论区留言，这里不多赘述了。
十、检查1.首先根据用户使用路径，检查是否有地方逻辑中断，分支流程是否有考虑到；
2.按照「2.2」中的功能清单，核实边界逻辑、兼容逻辑是否正常；
3.最后也是最重要的一点，找回需求调研的案例，代入进用户角色与场景看能否满足诉求，使用体验能否再优化；
十一、评审我理解的需求评审目的主要是大伙一起帮你找需求方案中是否还有遗漏的场景，那么在需求评审前，一定要做好准备。包括检查原型能否正常预览，一些文档的跳转是否正常。由于与会都是组长级别的同事，所以要注意认知差异，模拟对方是小白的情况下来组织话术，能够准确描述场景与希望解决的问题，
需求评审中要学会抓大放小，感觉有坑的点要提前确认好，会议上直接抛结论与论据，小点可以一句话带过，提高评审的效率；
需求评审后要做好会议纪要，评审中大家挑战的点有哪些，怎么解决，ddl是多少，做好后续行动的同步；
十二、需求如何落地千言万语汇聚成十个字，事事有回应、事事有记录
事事有回应指的是在需求流转过程中，会遇到各种形形色色的问题，在做好时间管理的情况下，要认真思考并给出结论（下一步的行动）；
事事有记录指的是，如果需求发生变更，要抽时间做纸质或口头的记录，建议大家在每个需求前面放一个变更记录表，总结变更点后记录下来，非常好用；
十三、需求如何推出去需求跟进：
我的需求跟进手段有两种，用户反馈、功能埋点，后者也是非常重要的一个部分，想单拆一篇文章来说明。
用户反馈是一个定性的跟进方式，上线前用户的反馈在上线后能close多少、上线后跟这些用户沟通的效果怎么样，它能直接反应我们是否解决了问题
功能埋点是一个定量的跟进方式，上线后使用情况如何、是否符合设计预期，它能反应用户的实际使用情况，目前我会以上线后一周/上线后一月/上线后三月的频次来产出对应的数据分析文档，数据驱动迭代是一件非常美妙的事情
功能包装：
俞军老师在《产品方法论》中有一个相关的名词叫「扩大效用」，指的是产品是企业和用户进行价值交换的媒介，用户愿意进行交易是因为在用户的预期中该产品的效用大于用户的成本且大于其他产品的效用。
如果想提高用户进行交易的几率，我们可以通过扩大产品效用的方式，而功能包装则是其中较常见的一种手段：选择某个用户群，利用banner、专题页等方式，直截了当的告知用户该功能的价值。
因为大部分用户是不想去思考的，例如微信有一个功能叫图片大爆炸，我在更新中看到这个名词，没看懂也不感兴趣就直接划走了，但实际它能帮助我们提取图片中的信息，如果是个付费功能，在这个场景下我是需要的，但我流失了。功能包装这个行为本质上就是告诉用户“我能帮你做什么”，是站在用户视角而不是产品视角。
1.在进行功能包装时，要强调价值而不是手段，提供一个快速跳转的功能入口并通过数据监测用户行为，驱动优化。
2.在进行功能包装时，不要局限在单点上，要去寻找点依附的那条线、线依附的那个面
十四、总结时光飞逝，这份方法论文档完稿于做产品的第一年，在这一年里我由懵懂的实习生成为越来越得心应手的“老油条”，离不开日常复盘、总结、思考的过程。毕业时自己定下的一年职业规划目标是「建立个人B端产品方法论，持续打磨基础能力」，现在看来虽然大体完成，但自身的学习效率与执行力还是要多加提升。
前几天跟朋友聊天，他问我为什么要花时间去输出这种方法论，当时我完全是从利他的角度出发，希望输出方法论后能让大家有复盘的意识，能少踩一些坑，能让工作再高效一些，从而帮用户解决更多的问题。
现在我要补充上利己的角度，因为输出方法论真的是一件非常有意思的事情，它就像一条线，将过往的每个知识点串联起来，让我有一种温故而知新的感觉。随着工作年限的增长，有可能现在的框架会进行修改、有可能现在的想法会被推翻，但从大盘来看是正向的进化过程，缓慢而踏实的成长。
anyway，希望自己能永远保持这份初心，也希望大家能踊跃地分享自己的意见和看法，不积跬步，无以至千里。
本文由 @sky0247 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
