在产品经理自学基础1那篇里我把入行前半年该补的知识框架整体过了一遍岗位分工、需求池、用户画像、MVP、PRD长什么样。当时有不少朋友留言说这些名词我都记住了可真到了要判断这个需求做不做、那个功能砍不砍的时候还是不知道怎么下手。这其实就是从基础1跨向基础2最需要解决的问题——概念继续堆砌已经没有增量真正要练的是决策能力。所以这篇产品经理自学基础2我不会再给你罗列新名词而是把产品经理日常工作中真正要反复使用的那套思考方式拆开讲需求怎么分析才不靠拍脑袋、竞品怎么拆才能拆出决策依据、数据怎么读才能发现问题、PRD和评审怎么做才不会被开发怼。适合已经看过基础概念、准备用真实场景练手的自学者也适合刚入职不久、发现学校教的用不上的初级产品经理。这一篇的东西每一节都能直接拿去用在你的实际项目上。1. 自学产品经理的第二个坡从会背概念到会做决策1.1 为什么大部分自学者会卡在第二个阶段基础1阶段学的东西本质上都是名词DAU、留存、转化漏斗、用户画像、MVP。这些概念背下来不难网上随便搜一篇入门文章就能看个大概。但工作里的产品经理面对的从来不是名词而是一道道没有标准答案的选择题。举个例子。老板跑过来说竞品上了个打卡签到功能我们是不是也得做一个你说做还是不做如果只背过概念你会想起用户激励体系留存工具这些词然后准备照着抄一个。但真正的产品经理要考虑的是我们的核心用户是谁、打卡能解决他们的什么问题、团队有没有精力做完并运营起来、这个功能会不会只是自嗨。这就是基础2和基础1的本质差别基础1教你知道有什么基础2逼你在信息不完整的情况下做出怎么办的判断。自学的人往往在第二个坡上卡住不是因为不够努力是因为学校里和教程里都没有人逼你做决策练习。1.2 做决策需要哪三种输入我做了这些年产品回头看每一个最终被验证正确或错误的产品决策底层输入其实就三类事实和数据这个问题的规模有多大用户在哪一步流失了类似功能的历史数据表现如何用户理解目标用户到底是谁他们打开产品的场景是什么他们说的是不是他们真正想要的业务约束现在有多少开发资源排期多久技术债重不重老板给的KPI是什么大多数自学者的问题在于只练了中间那部分——用户理解全靠猜数据不去查业务约束完全没概念。于是做出来的方案看起来逻辑通顺但一放到真实环境里就被各种现实因素击穿。我特别想强调一点自学产品经理最缺的不是知识是反馈。在公司里你的需求要过评审会开发会问你边界怎么处理运营会质疑你的判断数据同事会指出你口径不对。这些对抗虽然当时很难受但恰恰是让你进步最快的东西。自学者没人挑战你你就很容易在以为自己会了的状态里停留很久。所以这篇文章后面每一节我都会尽量把别人会怎么挑战你这个问题一并写出来。2. 需求分析进阶把我觉得变成有依据的判断2.1 一个典型需求是怎么从口头描述走完流程的先看一个最日常的场景。运营跑过来跟你说我们的下载转化率太低了做个签到领奖吧肯定能拉起来。如果你是刚入门的产品经理这时候容易直接进入画原型的阶段。但老手听到这句话脑子里会先弹出几个问题。下载转化率低是多少是1%还是5%行业里这类产品的中位数大概是多少用户到底是在哪一步流失的是渠道导流问题、落地页问题、还是注册流程本身太重签到领奖解决的是用户来了之后不活跃的问题而你没有证据证明用户不来的原因是不想活跃。这个例子说明一个非常核心的道理**运营和技术给你的往往不是需求是方案。**你能不能满足他取决于你有没有能力从他的方案里挖出真正的诉求再判断这个诉求是不是值得解决。所以我在处理这类需求时给自己定了一个流程先记录原话再写他真正想解决的是什么最后写我判断该不该做、为什么。就这三栏能挡掉大部分拍脑袋的需求。如果你现在正在自学我建议你拿手机里任何一个产品把最近一个月它做的更新都按这三栏拆一遍比看十篇需求分析怎么做的文章都有用。2.2 需求优先级排序RICE评分和KANO模型的组合用法需求池里躺着几十条需求怎么排先后初级产品经理喜欢用感觉这个重要高级产品经理会给一个可讨论的评分体系。我最常用的组合是KANO模型加RICE评分。KANO模型帮你做定性判断它把需求分成三类基本型、期望型、兴奋型。基本型没有的话用户会非常不满比如聊天软件的发送消息、登录功能。这类需求不做产品无法成立。期望型有的话用户会满意没有会不满意线性相关。比如深色模式、搜索排序优化。兴奋型没有用户也不觉得缺有了会眼前一亮。比如表情包推荐、拍照直接识别商品。但这东西有个麻烦它不能量化值不值得现在做。所以我一般再用RICE评分来帮忙拍板。RICE是四个单词的缩写Reach触达人数、Impact影响力、Confidence信心指数、Effort工作量。维度含义评分方式Reach3个月内能影响多少用户按具体人数估算Impact对目标指标的影响程度0.25微小、0.5低、1高、2极高等Confidence你对自己估算的信心100%高、80%中、50%低Effort需要的团队工作量按人周计算要问开发然后按公式算RICE分 (Reach × Impact × Confidence) / Effort。举个例子。需求A在账单列表增加搜索功能。估算月覆盖2000人Impact给0.5Confidence 80%需要2人周。分数 (2000 × 0.5 × 0.8) / 2 400。需求B重做新手引导月覆盖5000人Impact给0.75Confidence只有50%需要6人周。分数 (5000 × 0.75 × 0.5) / 6 312.5。这样一比从投入产出看A更优先但考虑到B信心指数低你可能应该先做个一周的小调研把B验证清楚而不是直接砍掉或者直接开工。用RICE时要记住几个坑Impact的评分标准要和团队提前对齐否则每个人给的数没法比Effort一定要问开发不要自己拍Confidence低的需求不要直接上或直接砍应该进入验证环节。2.3 学会场景推演把需求演一遍再决定写不写前面说的都是排序和过滤现在说一个我在实际工作中觉得最提效的动作——场景推演。拿到一个看起来没什么问题的需求时先别急着画原型闭上眼睛把用户使用它的完整过程演一遍从什么入口进来、当时是什么状态、操作完会发生什么、如果中途出错了怎么办。举个例子。有个需求是账单支持导出Excel。听起来很简单不就是拉个列表加个导出按钮吗。但你推演一下就会发现问题用户导出的场景是什么如果是拿去给财务报销他需要的是某个月份的消费明细带时间、商户、金额如果是自己记账分析他可能需要的是全量流水甚至要按类别汇总。导出的Excel用手机打开乱码怎么办导出的数据量超过十万行怎么办权限上子账户能不能导我当时练这个推演是在一个记账App的需求里发现用户真正不满的不是没有导出功能而是总金额对不上账单里的数。导出只是他用来对账的手段。如果只做导出等于帮用户把一个错误数据加工成一份更正式的表格。真正该做的是先把金额计算口径问题解决掉。所以我给自己定了个习惯任何一个需求在进入PRD之前先写一份一页纸的场景推演。不用写得很正式就是用户在什么情况下、带着什么目的、如何一步步完成这件事以及每一步可能的阻碍。这个习惯养成之后你会发现需求池里至少三分之一的需求在推演阶段就被推倒了——这不是浪费这是省钱。3. 竞品分析实战不是抄功能是拆对方的决策逻辑3.1 为什么你做的竞品分析没有用很多自学者写的竞品分析打开是这种结构竞品A的首页截图、竞品A的消息页截图、竞品A的个人页截图……每个截图下面配两行字该功能支持XX体验比较流畅。写三十页发给谁都没人看。问题出在哪你把竞品分析做成了功能清单。功能清单当然也有价值但价值是给研发参考的不是给产品做决策用的。产品经理做竞品分析唯一的目的是回答自己正在纠结的问题。比如你在纠结我们应不应该在首页加一个关注Tab这时候你去拆竞品的信息流结构才有意义。你要看的不是它有没有关注Tab而是它为什么有、在什么阶段加的、加了之后解决了什么、牺牲了什么。做竞品分析的时候记住这句话你是去读对方的决策逻辑不是去抄对方的功能样式。3.2 一套能落地的竞品拆解框架我给自己总结了一个四步框架每次做竞品分析就按这个走基本不会跑偏。第一步明确分析目的。你是为了验证商业模式、为了抄一个具体功能还是为了给自己的产品找定位目的不同你拆的颗粒度完全不同。第二步选竞品。这里很多人只会选直接竞争对手也就是产品形态和目标用户都差不多的那个。但真正有用的竞品分析还要包括间接竞品和替代品。类型定义示例假如你在做一款健身记录App直接竞品形态相似、用户相同Keep、Fitbod间接竞品方案不同、解决类似问题线下私教工作室、抖音健身博主替代品用户用别的方式满足同一需求小红书食谱、共勉打卡群第三步拆解维度不要贪多。每次只挑三到五个维度深挖比如定位、目标人群、核心链路、商业化设计、留存机制。问自己三个问题对方最核心的一个循环是什么这个循环里哪个点最强哪个点明显是妥协的结果第四步输出决策。不要用对方做了XX功能这种陈述句用对方用XX解决了XX问题对我们的启示是XX我们决定做/不做XX这种句式。我拿一个真实案例来演示。之前我拆过一个内容社区的信息流发现它采用关注流推荐流双Tab结构。很多人觉得这是标配但往深了想这个结构背后是两个决策关注流服务于老用户的关系链推荐流服务于新用户的内容冷启动。如果只做推荐流新用户能快速看到内容但老用户会觉得我的关注有什么用如果只做关注流新用户进来扑面而来全是陌生人动态根本留不住。拆到这一步你就能回来思考自己的产品了如果我们也遇到新用户留存低的问题是不是该优先建推荐流而不是先加关注Tab这就是竞品分析的真正用处。3.3 竞品资料的获取渠道和一些注意事项拆竞品最怕没素材。我常用的渠道大概这么几类产品本身的注册体验和全流程使用记录公开的官方公众号、创始人访谈、产品更新日志财报和发布会上提到的用户数据和战略方向行业媒体和分析报告的交叉验证。没进那家公司你永远拿不到它的内部数据所以要学会从公开信息里做合理推算。比如一个社区产品的财报里公布了MAU和单用户日均使用时长你就可以推算它的总使用时长规模再结合公开的创作者分成数据大致反推它的供需匹配效率。还有一条必须提醒不要试图通过任何不合规的渠道去获取竞品的内部数据或后台截图这既是职业操守问题也是法律风险问题。产品经理应该有竞品意识但更应该有边界感。用公开可查的信息做分析完全够用。4. 数据指标不是报表是产品经理的决策语言4.1 从北极星指标开始反推指标体系很多自学者学数据分析一上来就学SQL、学Python方向错了。产品经理的数据能力首先不是写代码而是知道该看哪个数、这个数为什么变、变了之后怎么办。一个产品最重要的数据指标叫北极星指标它要能代表产品给用户创造的核心价值。拿内容社区举例注册量不是北极星因为注册了不用等于零DAU也不是最好的北极星因为它可以被签到和推送硬拉起来。对这类产品我更倾向于用周活跃阅读用户数它意味着用户真的在持续获取内容价值。从北极星指标往下拆就是一套指标体系。核心逻辑是用户从接触产品到成为忠实用户会经历一条链路每个环节都要有人负责、有数可看。环节核心指标这环节要回答的问题激活注册转化率、首次关键行为完成率新用户进来能不能在5分钟内体验到产品核心价值活跃DAU/MAU、人均使用时长用户是否在养成使用习惯留存次日留存、7日留存、30日留存用户第二天还来不来一周后还来不来变现ARPU、付费转化率产品靠什么赚钱、付费点是否自然推荐NPS、邀请率、K因子用户愿不愿意把产品推荐给别人这里面要特别注意指标口径的统一。拿DAU来说去重口径是按设备算还是按账号算跨天时区怎么算不同团队要是不对齐后面分析数据一定打架。我在写PRD的时候就会规定好这个页面事件叫什么名、参数带什么、统计口径是什么。等到功能上线数据自动按约定的口径进入看板省掉后面大量扯皮。4.2 没有真实数据自学者怎么练手这是个老问题。很多自学的人说我知道指标重要但我手上没有产品、没有数据怎么练不是完全没有办法我用过几条比较有效的路子。第一拿上市公司的财报练手。很多互联网产品在财报里会公布MAU、ARPU、营收结构。你可以拿着三个季度的数据自己试着找规律用户涨了但收入没涨说明什么收入涨了但用户没涨又说明什么把推论写下来然后去官网动态和行业分析里验证。第二给一个自己天天用的产品造指标体系。比如你天天用某记账App你觉得它现在的留存做得不好那你怎么定义它的北极星指标往下一级拆关键的激活行为是什么从哪里能找到留存断裂的证据这是纯思考题但特别练数据思维。第三用Excel做模拟数据。假设自己是一个电商小产品设定1000个用户样本给每个用户编上来源渠道、注册日期、购买次数、退款记录。然后自己算一遍哪个渠道的次留最高、哪个渠道的30日留存衰减最厉害、退款率最高的商品有什么共同点。数据是假的没关系练的是从数据到假设的思考链路。我始终觉得产品经理和数据分析师的分工区别在于分析师帮你确认是什么产品经理要回答为什么、怎么办。所以练手的时候重点不是把指标算得多准而是看到一组数字之后你能提出多少条有价值的假设。4.3 数据异常时产品经理怎么排查很多人一看到数据跌了就慌直接给研发发消息你是不是改坏什么了这样既不专业也解决不了问题。我自己的排查顺序是固定的三步。第一步判断波动是不是真的异常。看趋势线不能拿今天的数字和昨天的比要拿它跟过去30天同一维度的数据比。还要看波动是否落在正常的假期效应、周期效应范围内。第二步拆维度定位。如果次日留存率从40%掉到了35%不要停留在总体层面。按版本拆是不是只有新版用户掉按渠道拆是不是某个买量渠道带来的用户质量下降了按人群拆是不是新用户掉而老用户没掉每拆一个维度范围就缩小一圈。第三步提假设、排优先级。结合最近一周上线的功能、渠道投放变化、运营活动来分析。先验证可能性最高的那个假设。比如你发现只有新版用户留存掉了而且新版正好改了注册引导流程那第一个该查的就是引导流程是不是让用户卡在某个环节了。这背后有个很重要的习惯从写PRD的时候就要想好埋点方案。别等功能上线了才研究为什么数据不对那时候你已经没有过程数据可以看了。所以我在第五部分会专门讲一份合格的PRD里埋点方案是必写项不是可选项。5. 中期工作流的真实面貌PRD、流程图与评审会5.1 PRD是思考容器不是免责声明有些新人把PRD写成了免责声明事无巨细写一堆等于什么都没想。真正好的PRD核心作用是逼你自己把逻辑走通顺便让开发、测试、设计能高效地理解你的思路。我写PRD用的骨架是固定的分享给你。第一块是背景和目标目标必须量化。不要写提升用户体验要写新版注册流程将注册转化率从35%提升到45%。第二块是范围明确做和本期不做。本期不做这一栏特别重要能省掉评审会上大量那这个呢的问题。第三块是功能详述包括用户故事、交互流程、异常场景和边界情况。第四块是埋点需求。第五块是上线方案和回滚方案。这里我要格外强调异常场景和边界情况。开发最怕的不是你功能讲不清楚而是主流程讲完了一问边界全没想过。没登录怎么办网络断了怎么办数据为空怎么展示用户重复提交怎么处理权限不足怎么拦截这些写清楚开发对你的好感会直线上升。5.2 流程图与状态图的正确用法画流程图前面要搞明白一个问题你画这张图是为了表达什么方向不同用的图完全不同。展示一个跨角色、跨系统的操作流程用泳道图。泳道图按角色或者系统分横向泳道每个角色在自己的泳道里做动作箭头表示流转关系。好处是一眼能看出来谁在什么环节卡住了、交接是不是清晰、有没有哪个角色被分配了过多职责。展示一个实体对象的状态流转用状态图。比如订单它可能有待支付、已支付、已发货、已完成、已退款、已关闭这些状态。状态图重点画状态之间有哪些合法转移以及触发转移的动作是什么。凡是后台管理、订单系统、任务系统这类需求状态图比流程图更合适。我每次画完图都会做一个自检是否每个分支都走到了终点、每个判断节点有没有兜底处理、泳道之间的交接有没有明确的信息载体比如提交表单这件事产出什么、传给谁。如果你画完发现一张图里有超过七八个判断节点那不是你画得不好而是这个功能本身就该拆分成好几个。工具方面draw.io免费、ProcessOn在线方便、Figma也能画。不要纠结工具能把想法画明白就行。5.3 评审会上最容易被挑战的问题清单评审会是很多自学者的心理阴影但其实被挑战是好事说明别人在帮你找漏洞。我整理了常见的几类问题你自己写PRD的时候可以逐条先问自己一遍。问题类型评审会上最常见的问法你提前该做的准备需求价值你怎么证明用户需要这个功能拿出用户反馈、数据证据哪怕是小范围调研结果边界情况用户没登录怎么办断网呢PRD里列出异常场景清单不遗漏、不侥幸优先级为什么这个现在做不做行不行用RICE这类评分逻辑说明排序依据技术约束开发说了这个做不了/要三个月提前和开发对齐技术方案备选方案至少要一个成功标准上线之后你怎么知道它成了写清验收指标和埋点方案没有指标的需求不要提还有一个经验评审之前提前把文档发给测试和开发里技术能力比较强的人看一遍请他们先提一轮意见。这不会显得你能力弱反而说明你靠谱。评审会是为了确认方案不是为了检测能力你要尽量让所有分歧在会前就解决掉会上只讨论真正需要拍板的事。6. 自学者最容易卡住的三道坎以及我的破局方法6.1 坎一只学不练一直在收藏方法论我见过太多自学者收藏夹里存了几十个产品经理必看干货合集真正动手做一个完整方案的几乎没有。为什么因为练习意味着要动脑、要被否定、要输出可能很烂的东西比收藏累多了。破局方法很简单粗暴给自己布置一个限定时间的端到端任务。比如假设你是某记账App的产品经理目标是把月活跃用户提升10%时间三个月。请你在两周内输出一份可以拿出去评审的方案内容包括目标拆解、用户场景分析、功能设计、核心埋点、评审备问、上线后的验证计划。这个任务不需要真实数据支撑你模拟就行。关键是整个过程必须走完不能只写一个功能要想清楚它怎么影响北极星指标、开发成本大概多少、有什么风险。做完之后找任何一个懂产品的朋友或网友来挑战你认真听批评。6.2 坎二工具学太多反而没时间思考产品经理的工具列表越来越长Axure、Figma、Sketch、ProcessOn、Notion、Teambition、Mixpanel……很多自学者把大量时间耗在学会每一个工具上误以为工具熟练就等于产品能力强。实际上在一家公司里产品经理常用的核心工具就那几类画原型的Figma或即时设计这类二选一就够、画流程图的draw.io或ProcessOn、写文档的Notion或语雀、做表格的Excel或在线表格。每一类用一个顺手的学到能把想法表达出来的程度就可以了。判断标准很简单**工具是服务表达不是表演技能。**如果你为了画一个好看的高保真原型要花一周那就是你工具使用方法错了。产品经理交互细节可以做得粗糙但业务逻辑必须讲清楚。把省下来的时间用来做场景推演、做数据分析、打磨PRD比啥都强。6.3 坎三没有反馈回路不知道自己几斤几两在公司里产品经理的需求会被设计挑战、被开发挑战、被测试挑战、被运营挑战。你说我觉得这个用户可能需要立刻会有人问你有数据吗。这种对抗环境虽然难受但能逼着你不断完善想法。自学的人最缺的就是这个。没人怼你你就不知道方案的漏洞在哪会长期停留在自我感觉良好的状态。我试过几个办法来解决。一是把你的方案和决策记录发到产品社区或者行业群里征求不同意见。发布前记得做好业务脱敏别把公司内部数据放进去。二是找一位产品经验比你丰富的人做模拟评审付费请教也可以一次两个小时让他专门挑你方案里的毛病这个钱花得比买课值。三是养成写复盘的习惯每个练习项目结束之后写三栏当时是怎么想的、结果如何、如果重来会在哪里改变。自我复盘虽然比不上外人批评但它能帮你建立起回看自己决策的惯性。6.4 基础2阶段的自学路线建议如果你已经看完这篇文章想把这套东西真正内化我建议你给自己排一个8周的学习计划。周期学习内容输出物达成标准第1-2周需求分析与优先级判断一份需求池清单两个RICE评分案例能对任何需求说清楚做/不做、为什么第3-4周竞品分析拆解3个产品每个输出一页决策页能说出竞品每个核心功能背后的取舍第5-6周数据指标体系选一个真实产品写出它的北极星指标和完整漏斗拆解能给指标定义统计口径并规划埋点方案第7-8周端到端练手项目完整方案评审备问数据验证计划找至少一位同行完成模拟评审每两周一个交付物时间一到必须拿出东西来拿不出就降级需求范围但不能跳步。这种以输出倒逼输入的方式比无限期看书看课靠谱得多。有人问我从零开始自学产品经理最难的是不是学画原型、学写文档我的真实感受是这些东西都有标准答案照着练总会。真正难的是自己一个人面对一堆含糊不清的信息时敢不敢拍板、能不能为自己的拍板负责。基础2的训练本质上就是在练这件事。等你把上面这六个模块完整走完一遍再回头看基础1里那些名词你会明显感觉到它们不再是纸面上的定义而是你每天做判断时随手就能调用的工具。