上篇写“产品经理自学基础”的时候我还在讲岗位认知、工作流程、工具清单这些入门货。结果评论区被一群自学党追问“讲完这些之后呢下一步该学什么怎么从‘知道’变成‘会做’”这篇“产品经理自学基础2”就是来填这个坑的。这篇内容的核心就一件事把一个模糊的想法变成一份能拿去评审、能指导开发的需求文档。我会把这条链路拆成需求调研、竞品分析、优先级排序、原型与PRD四个环节按顺序串起来讲并且用“团队周报助手”这个具体项目从头到尾走一遍。整个过程没有晦涩的理论全是能拿来直接用的方法、模板和踩坑记录。适合正在自学转型产品岗的新人也适合已经入行但觉得“需求总是被挑战”的初级产品助理。先说好这篇不是教你怎么把Axure用得花里胡哨也不讲怎么写出一百页的宏大PRD。自学产品经理的人最缺的不是工具技巧而是“一套想事情的顺序和判断标准”。这部分练扎实了后面学什么都快。1. “产品经理自学基础2”到底该补什么课1.1 自学产品经理的人最容易倒在哪个环节先说个现象。我接触过不少自学产品经理的朋友大家的学习路径惊人的一致先看几本经典书然后装个Axure或者即时设计照着网上的案例画高保真原型画完觉得自己已经会做产品了。等真正接到一个任务发现自己连“要从哪里开始想”都不知道。问题出在哪出在把“输出物”当成了“能力本身”。原型、PRD、流程图这些都是输出物它们只是你把思考结果表达出来的方式。真正值钱的思考过程是你怎么判断“做这个功能”是合理的怎么取舍“这个需求”要不要做怎么做才能让开发拿到文档不骂人。这就是“产品经理自学基础2”要补的核心内容从“想法”到“方案”的中间链路。这条链路其实就是你在一个真实项目里从第一天到第一周会经历的过程。能独立走通它才算真正摸到了产品工作的门槛。1.2 为什么选这四个模块而不是别的这次内容选了四个模块需求调研、竞品分析、优先级排序、原型与PRD。你可能想问为什么不是数据分析不是项目管理不是增长方法论因为自学阶段最要紧的是先建立起“从模糊到清晰”的处理能力。需求调研解决的是“到底为谁解决什么问题”竞品分析解决的是“别人怎么做的、我们怎么做才能更好”优先级排序解决的是“资源有限先做什么”原型和PRD解决的是“怎么把自己的想法准确传达给别人”。这四个模块串起来正好是产品工作最日常的闭环。换个生活化的类比你要装修一套毛坯房。需求调研等于先问清楚家里几口人、生活习惯是什么竞品分析等于去邻居家和样板间看看别人怎么布局的优先级排序等于想清楚先改水电还是先买软装原型图是装修效果图PRD是施工图。没有前面这些步骤直接画施工图大概率装出来没法住。1.3 这一阶段的学习目标请你对号入座这篇结束后你可以照着下面的清单检验自己是否达成了目标能制定一份不带引导性问题的访谈提纲并完成至少3场真实访谈。能从功能层、体验层、商业逻辑层三个维度拆解一个竞品。能用一个可量化的模型给需求打分排序而不是凭感觉说“这个很急”。能画出一份结构完整、逻辑通顺的低保真原型。能写出一份开发拿着不用追问就能开工的PRD。如果你现在一项都做不到没关系这篇文章就是给你准备的。跟着第三章的案例完整走一遍你会发现自己对“产品经理平时都在干什么”这件事的理解会立刻变得具体。2. 关键能力拆解需求和方案之间的四个动作2.1 需求调研最有价值的一步也最容易被跳过很多自学的人会犯一个共同的毛病有了一个想法之后特别着急画原型。理由是“我得先做出来一个东西看看”。但产品经理不是艺术家不能自己闷头创作完再让大家欣赏。产品经理的工作方式更像是“先想清楚再画出来”而想清楚的唯一途径就是去接触真实的需求来源。需求调研最基础也最常用的方法是用户访谈。访谈这东西听起来简单不就是找人聊聊天嘛实际上里面全是坑。我见过新手列的问题清一色是“你觉得这个功能好不好”“如果有了这个功能你会不会用”这种问法得到的答案几乎没有参考价值因为用户在回答的时候通常会给你留面子嘴上说“很好很有用”实际上转身就走。访谈的正确打开方式是让你自己闭嘴让用户讲场景和事实。不要问“你想要什么”而要问“你上次遇到这个情况是什么时候当时你做了什么”。举个例子你想做会议纪要工具不要问“你觉得自动生成纪要这个功能有用吗”而是问“过去一个月里你印象最深的一次开完会没人整理纪要是什么情况后来你怎么办了”这样问出来的才是真实的场景、真实的痛点、真实的现有解决方案。访谈结束之后整理纪要也有讲究。我建议用三栏记录表第一栏写用户的原始话术原封不动地记最好记那些带情绪的话第二栏写你推测的真实需求第三栏写证据等级分“亲口说的”“亲眼看到的”“只凭猜测的”。为什么分等级因为在评审需求的时候开发只要问一句“这个需求哪来的”你就能立刻拿出“某用户原话是XXX在什么场景下说的”这样的硬证据而不是说“我觉得大家都需要”。这种细节会让你在团队里的可信度高一个档次。2.2 竞品分析不是抄功能清单而是拆对方的决策逻辑竞品分析可能是被误解最深的一个词。很多自学者理解的竞品分析就是“把别人的功能列表抄下来然后加一行字说我们有”。这种分析报告交上去不客气地说就是废纸。我自己的习惯是把竞品分析拆成三层。第一层是功能层看对方做了哪些功能这层最直观但信息价值也是最低的。第二层是体验层看他在核心路径上是怎么设计的哪些地方让你觉得顺手哪些地方让你觉得别扭关键不是评价好坏而是理解“他为什么这么设计”。第三层是商业逻辑层看他的钱从哪里来核心用户是谁靠什么留住用户这层才是理解一个产品灵魂的地方。举一个我自己做过的例子。如果我要做团队周报助手我的直接竞品可能包括各种项目管理工具里的周报模块。功能层上对比的是“谁能自动汇总成员周报”“谁能同步项目进度”体验层上要对比的是“成员填写周报需要花几分钟”“管理者查看时能不能快速定位风险”商业逻辑层上要想的是“周报模块对这个产品来说是拉新功能、留存功能还是商业化功能”。这三层分析完之后你才真正知道别人的产品为什么长这样而不是急着复制。做竞品分析还有一个容易被忽略的点不要只看同赛道。做效率工具的人可以去看看外卖点餐是怎么做引导的做教育产品的人可以去看看记账软件是怎么做打卡激励的。跨行业看到的东西往往更新鲜也更可能成为你产品的差异化亮点。2.3 优先级排序手里只有三个馒头别想着摆满汉全席需求调研和竞品分析做完你手上会积累一大把“听起来都该做”的需求。这时候就要做一个残酷的动作排序。资源永远是有限的开发团队一个月只能做两三件事产品经理的核心价值之一就是决定“这个月不做什么”。市面上的排序方法很多我给自学的新人推荐三个按使用场景排列。第一个是KANO模型它把需求分成三类基础型需求做了没人夸不做会被骂、期望型需求做得越好满意度越高、兴奋型需求不做没人觉得缺做了大家会很惊喜。它的价值在于帮你识别“底线”和“亮点”。一个连登录都不稳定的小程序做再多花哨的动画也没用。第二个是RICE评分法用四个因素给需求打分触达人数Reach、影响力Impact、信心指数Confidence、成本Effort分数等于触达乘以影响力乘以信心除以成本。这个模型的好处是强迫你量化每一项当你无法量化的时候你就必须去收集数据而不是拍脑袋。第三个是莫斯科法则把需求分成Must必须有、Should应该有、Could可以有、Wont这期不做。这个适合快速和团队对齐谁都能看懂不会产生歧义。我还想强调一个“一刀切”的判断标准也许多次在项目里帮了我大忙如果砍掉这个需求用户的真实使用链路仍然完整那它就值得被延后。反过来如果你发现某个需求不做的代价是用户卡在关键步骤上无法继续那无论有多复杂它也该是这一期优先级的最高位置。3. 完整实操一周走通“从想法到PRD”的流程3.1 项目背景我们假定要做“团队周报助手”光讲方法论太干我们来点真的。我拿“团队周报助手”这个项目作为贯穿全文的案例。背景假设是这样的一个三十人左右的研发团队每周五都要写周报给部门负责人看现在的流程是每个人在文档里写一段然后负责人手动收集、汇总、提炼每次要花一下午的时间。目标是在两周内完成产品方案评审。这个项目从零开始我会带着你走完整条链路需求调研、竞品分析、优先级排序、原型设计、PRD撰写。每一步给出具体的输出物模板你以后做别的事可以直接套用。先说好这个两周的时间是给产品方案评审用的不是给开发上线用的。产品经理在这个阶段要交付的是一沓有依据的方案而不是一堆代码。3.2 需求调研与竞品分析的实操记录第一天到第三天我集中做访谈。访谈对象锁定三类人写周报的成员、汇总周报的负责人、看周报的部门负责人。三类人的诉求完全不一样成员嫌麻烦负责人嫌信息不整齐老板嫌内容看不到重点。访谈提纲只列了六个开放问题。第一你最近一次写周报是什么时候当时是怎么写的第二写一份周报大概花多少时间卡在哪里第三你收到大家的周报之后整理的时候都做了什么操作第四你看周报的时候最想从中获取什么信息第五现在这个流程里哪个环节最让你烦第六如果有一个工具能帮你改掉这个流程你最希望它解决哪一件事。这个提纲的目的很明确不问“你要什么功能”只问“你现在的行为是什么样的”因为功能需求可以由行为推导出来而直接问“你要什么”往往得到的是空话。三天时间约了六个受访者每人聊了大概四十分钟。访谈下来才发现团队真正痛的不是“写周报”本身而是“不知道这周工作重心的变化”。负责人汇总周报的时候不只是在贴文字他其实在做信息判断谁这周没进展、谁遇到阻碍、谁的优先级变了。这个发现直接影响了后续产品形态的走向。同步进行的竞品分析我用了一天时间。重点看了四类产品飞书的周报模块、企业微信的汇报功能、TAPD的项目周报、以及Notion上的周报模板。功能层对比的是“自动汇总能力”“提醒能力”“数据统计能力”体验层对比的是“填写成本”“查看效率”商业逻辑层分析发现周报模块对这些B端产品来说更多是制造粘性的功能而不是独立的价值点。让我用一个表格展示当时整理的功能层对比你可以感受一下这个表格的颗粒度竞品自动汇总模板配置进度对接数据统计提醒机制飞书周报模块支持支持多种模板支持关联任务较弱有企业微信汇报支持支持不支持较弱有TAPD项目周报支持支持支持关联迭代中等有Notion模板无灵活但需自建可手动关联无无到了第四天调研材料已经足够丰富了。我的书桌上摊着六份访谈纪要、四份竞品分析表这时候才开始动笔整理需求清单我觉得这才是正确的顺序。很多人把这个顺序搞反了先画原型再去补调研最后原型被推翻白白浪费时间。3.3 整理需求清单用RICE评分模型排出优先级第四天下午我开始把访谈和竞品分析的结果转成需求清单。这一步的核心是“需求追溯”每一条需求都要能追溯到某位受访者的原话或者某个竞品验证的依据拒绝一切凭空冒出来的“我觉得”。最终整理出八条需求。第一条成员填写周报时自动带出本周已完成任务和下周计划第二条负责人可以自定义周报模板字段第三条成员周报中标注阻塞项负责人查看时高亮展示第四条系统每周五下午自动提醒未提交成员第五条自动汇总所有成员周报生成整体团队周报摘要第六条支持与已有IM工具比如飞书或企微免登录跳转第七条支持手机端快捷填写第八条周报历史自动归档并支持按月份搜索。接下来就是排序环节。我用RICE模型给每条需求打分你还记得公式吗分数等于触达人数乘以影响力乘以信心除以成本。触达人数用的是团队规模30人做基准“对所有人有影响”算30“只对负责人生效”可能算3。影响力打分在0.5到3之间重大影响给3一般给1微弱给0.5。信心指数在50%到100%之间有直接用户原话支撑的给高信心只是竞品验证的适当打折。成本则是估算人天数字大反而会降低排序。来看看第一条“自动带出已完成任务”的打分它可以追溯到访谈中成员“我每周都要把任务列表重新抄一遍”的原话触达人数是30人因为每个成员都受益影响力给3信心指数90%成本估计3人天计算结果是30乘以3乘以0.9除以3等于27。再看第五条“自动汇总周报摘要”它主要受益者是汇总的负责人触达人数是3影响力给2信心指数75%成本却要10人天计算结果只有0.45分。这一比差别就出来了。所以这一期拍板做第一条、第三条、第四条、第五条里的轻量版第七条和第八条顺延到下期第六条因为要对接外部系统、成本太高但收益有限直接砍掉。你看有了量化过程砍需求的时候就不再是吵架而是拿计算过程说话。3.4 画低保真原型别在颜色和细节上纠结第五天开始画原型。自学者最大的误区是喜欢一上来就画高保真花两小时调按钮阴影。原型在这个阶段的作用是沟通不是美观所以低保真线框图就够了。我用的是即时设计你也可以用Axure、Figma或者甚至纸和笔。关键是画出信息结构和操作路径不需要在意配色。核心页面就三个成员填写页、负责人汇总页、历史归档页。成员填写页的结构是这样的顶部是周次选择器下面分成三个区块“本周完成”列表、自动带出的未完成任务供勾选、“阻塞项”特殊输入框。负责人汇总页分成左侧成员列表和右侧详情区有高危标记的成员在列表里标红右侧顶部提供“生成团队摘要”按钮。历史归档页就是一张按周排列的表格点某周能展开当时每个成员的周报。画原型的时候我会顺手标注每个页面的交互规则。什么叫交互规则举个例子页面上的数据从哪来、为空时显示什么、操作后如何反馈。这些细节才是开发真正关心的东西颜色反而是最不重要的。3.5 写一份“开发不追问”的PRD结构、边界、验收标准第六天写PRD。这是整个自学基础里最硬核的输出物也是最多人写不好的东西。我给新人推荐一个“一页纸PRD”结构核心字段包括项目背景、目标用户、核心痛点、本期目标、名词解释、功能范围、非目标、用户流程图、每个功能的详细规则、数据埋点、异常边界。其中“非目标”这块最容易忽略我建议每个PRD都写清楚“本期明确不做的东西”它能省掉大量评审会上无休止的争论。用功能规则来举例还是说“自动带出已完成任务”这条。我的PRD里写的规则是这样的“进入周报页面时系统自动拉取用户当前迭代中状态为已完成的任务列表。列表按任务创建时间倒序排列用户可勾选是否展示在周报中。勾选状态默认全选。如果当前迭代没有已完成任务则展示空状态的引导文案‘本周还没有已完成任务去任务列表看看吧’。”“阻塞项”功能的规则是“阻塞项输入框最多填写三条每条不少于十个字。提交后阻塞项在负责人汇总页中显示为红色标签优先级高于普通内容展示。”你看这种写法才叫需求描述它包含了触发条件、数据来源、默认值、空状态、边界限制。开发拿到这种PRD不用再来回追问“这里为空怎么办”“最多能填几条”评审会上自然没人喷你。PRD写完一定要自己通读一遍把自己当成什么都不懂的开发挑出任何一个“这里没说明白”的地方。很多新手PRD被退回都是因为“想当然地把上下文默认了”而开发眼里没有理所当然这件事。这里我当年吃过不小的亏后面问题清单里再细说。4. 自学路上最常踩的坑以及应对速查4.1 需求评审会上被挑战通常不是临场发挥的问题很多自学者好不容易写出一份PRD结果评审会被开发问得哑口无言于是怀疑自己沟通能力不行。其实绝大多数被挑战的场景是你前期思考不到位。开发问“用户为什么不直接用表格”“这个自动汇总的准确率怎么保证”这些问题都应该在你动笔写PRD之前就想清楚。我整理了一个高频问题速查表里面记录了真实工作里反复被问到的场景高频质疑问题本质应对方法这个需求有数据支撑吗需求缺少来源证据整理调研记录引用用户原话这里出现异常情况怎么处理PRD没写边界条件补充空状态、超限、重复提交等场景为什么要做这个功能看不出需求与目标的关联在PRD第一段写清楚背景与预期收益这个方案的实现成本太高了没考虑投入产出比给出打折方案拆成MVP先验证竞品有你就一定要有吗照抄需求无思考用竞品分析说明“必须做”的理由或差异化策略4.2 访谈时用户说的和做的不一样怎么办这又是一个自学过程中必然会碰到的问题。口口声声说“我每周写周报很痛苦”的人你观察他实际操作发现他十分钟就写完了痛苦感远没有他描述的那么强。遇到这种情况我的处理原则是“行为优先于语言”。用户嘴里的需求要被行为验证才算数。访谈中观察到的行为细节反馈往往更真实。如果他说痛苦但行为上不痛苦那说明“自动带出任务”这条需求的优先级应该下调或者它根本不是一个值得单独产品化的需求。你可以换个方向细化这类用户嘴上说痛苦行为却很快那他真正缺的可能是“让老板看到自己工作成果”痛点藏在表达层不是效率层。4.3 没有数据基础怎么说服别人排序自学者做项目最头疼的就是没有真实数据做支撑。用户量没有、转化率没有、留存率也没有RICE模型里的触达人数和影响力全靠估算总觉得心里没底。我的做法很实在没有存量数据就去创造最小样本数据。找五个目标用户跑一次小范围测试统计他们的行为数据哪怕样本很少也比纯估算强。比如“自动带出任务”到底能节省多少时间访谈时让受访者当场填一遍周报掐表计时拿到的就是一手数据佐证“填写周报时间可以从15分钟降到5分钟”这个数据在评审会上是可以立住的。4.4 画出的原型总被说“丑”是审美问题还是方法问题新手被说原型丑很常见但你仔细复盘会发现大多数时候被说“丑”并不是配色问题而是布局让人看不懂信息层级。解决方法很简单别自己发明组件去抄成熟设计系统的组件规则。即时设计、Figma都有丰富的设计系统资源库直接使用规范化的组件哪怕全是默认样式信息层级也是清晰的。原型里最容易出丑的环节是“信息过载”一屏内容塞得太满评审会全程都在讨论样式而非逻辑。记得抓主要流程周边内容用“待定”占位即可。4.5 自学者如何给自己制造反馈循环最后说一个自学专属的问题工作中有人带的人做错了立刻会被提醒而自学者没有反馈链容易在一个错误的方向上越走越远。我的办法是给自己制造“外部反馈”。把写好的PRD、画好的原型发到产品经理社区或找一个同为自学的朋友互相评审方案。关键是评审时提出这三个问题“这个方案要解决什么问题”“解决方案真的能解决吗”“有没有成本更低的替代方案”。只要有人对你这三个问题提出具体质疑你的思考就能快速迭代。5. 学习节奏安排与后续扩展建议5.1 用一个月时间把基础2的内容练成肌肉记忆如果你希望彻底消化这次的内容我建议你按照四周的节奏来练习。前两周专门找身边一个熟悉的场景做访谈和竞品分析小到“家里点外卖的选择流程”都可以重点是把提问方式和信息整理方法练熟。后两周找一个真实的软件需求从调研到产出PRD完整走一遍这次说的流程哪怕产品是你虚构的也要把每个环节的输出物做得像模像样。我之前反复跟自学的人强调一个观点输出物是唯一的检验标准。你觉得自己会了没用把访谈纪要、竞品分析表、优先级评分表、原型图、PRD这几个东西摆出来你自己就能看出哪一步还虚。哪一步虚就回头重新学哪一步。5.2 基础2之后你可以继续深挖这些方向这条链路走通后你已经具备了初级产品经理的基本功。接下来再往深走会有几个自然的方向。比如数据分析学会给每个需求设定指标验证上线后是否达到了预期又比如说项目管理学会如何把一个方案拆成迭代计划跟踪进度处理风险还可以学一些细分领域的方法论例如B端产品的复杂业务抽象能力或者C端产品的用户增长思路。我的建议是不要急着每一个方向都去学先挑一个和你目标岗位最匹配的方向深挖下去。做B端产品就死磕业务理解和流程抽象做C端产品就研究用户心理和数据验证。有了基础2打底你学这些新东西的速度会快很多因为你已经知道所有方法论最终都是为了让“模糊的想法”变成“扎实的方案”。我个人在带过几个新人之后最深的体会是产品经理这个岗位的门槛不在工具不在画图而在一种“对模糊信息不恐惧且有能力逐步把它变清晰”的思维方式。基础2讲的就是培养这种思维方式的具体路径。如果你能把访谈、分析、排序、表达这一套链条走顺后面遇到再复杂的项目你都不会慌。最后分享一个小习惯也许能帮到你从下一个练习项目开始动笔之前先写一句“一句话需求陈述”格式是“为谁解决什么问题以达到什么效果”。这句话写不通顺坚决不动笔。试过你就知道它能帮你规避掉一半以上的无效工作。