企业官网建设流程全解析

在产品经理自学基础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（工作量）。

然后按公式算：RICE分 = (Reach × Impact × Confidence) / Effort。

举个例子。需求A：在账单列表增加搜索功能。估算月覆盖2000人，Impact给0.5，Confidence 80%，需要2人周。分数 = (2000 × 0.5 × 0.8) / 2 = 400。需求B：重做新手引导，月覆盖5000人，Impact给0.75，Confidence只有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 一套能落地的竞品拆解框架

我给自己总结了一个四步框架，每次做竞品分析就按这个走，基本不会跑偏。

第一步，明确分析目的。你是为了验证商业模式、为了抄一个具体功能，还是为了给自己的产品找定位？目的不同，你拆的颗粒度完全不同。

第二步，选竞品。这里很多人只会选"直接竞争对手"，也就是产品形态和目标用户都差不多的那个。但真正有用的竞品分析还要包括间接竞品和替代品。

第三步，拆解维度不要贪多。每次只挑三到五个维度深挖，比如定位、目标人群、核心链路、商业化设计、留存机制。问自己三个问题：对方最核心的一个循环是什么？这个循环里哪个点最强？哪个点明显是妥协的结果？

第四步，输出决策。不要用"对方做了XX功能"这种陈述句，用"对方用XX解决了XX问题，对我们的启示是XX，我们决定做/不做XX"这种句式。

我拿一个真实案例来演示。之前我拆过一个内容社区的信息流，发现它采用"关注流+推荐流"双Tab结构。很多人觉得这是标配，但往深了想，这个结构背后是两个决策：关注流服务于老用户的关系链，推荐流服务于新用户的内容冷启动。如果只做推荐流，新用户能快速看到内容，但老用户会觉得"我的关注有什么用"；如果只做关注流，新用户进来扑面而来全是陌生人动态，根本留不住。拆到这一步，你就能回来思考自己的产品了：如果我们也遇到新用户留存低的问题，是不是该优先建推荐流而不是先加关注Tab？这就是竞品分析的真正用处。

3.3 竞品资料的获取渠道和一些注意事项

拆竞品最怕没素材。我常用的渠道大概这么几类：产品本身的注册体验和全流程使用记录；公开的官方公众号、创始人访谈、产品更新日志；财报和发布会上提到的用户数据和战略方向；行业媒体和分析报告的交叉验证。

没进那家公司，你永远拿不到它的内部数据，所以要学会从公开信息里做合理推算。比如一个社区产品的财报里公布了MAU和单用户日均使用时长，你就可以推算它的总使用时长规模，再结合公开的创作者分成数据，大致反推它的供需匹配效率。

还有一条必须提醒：不要试图通过任何不合规的渠道去获取竞品的内部数据或后台截图，这既是职业操守问题，也是法律风险问题。产品经理应该有竞品意识，但更应该有边界感。用公开可查的信息做分析，完全够用。

4. 数据指标不是报表，是产品经理的决策语言

4.1 从北极星指标开始反推指标体系

很多自学者学数据分析，一上来就学SQL、学Python，方向错了。产品经理的数据能力首先不是写代码，而是知道该看哪个数、这个数为什么变、变了之后怎么办。

一个产品最重要的数据指标叫北极星指标，它要能代表产品给用户创造的核心价值。拿内容社区举例，注册量不是北极星，因为注册了不用等于零；DAU也不是最好的北极星，因为它可以被签到和推送硬拉起来。对这类产品，我更倾向于用"周活跃阅读用户数"，它意味着用户真的在持续获取内容价值。

从北极星指标往下拆，就是一套指标体系。核心逻辑是：用户从接触产品到成为忠实用户，会经历一条链路，每个环节都要有人负责、有数可看。

这里面要特别注意指标口径的统一。拿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的时候，可以逐条先问自己一遍。

还有一个经验：评审之前，提前把文档发给测试和开发里技术能力比较强的人看一遍，请他们先提一轮意见。这不会显得你能力弱，反而说明你靠谱。评审会是为了确认方案，不是为了检测能力，你要尽量让所有分歧在会前就解决掉，会上只讨论真正需要拍板的事。

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周的学习计划。

每两周一个交付物，时间一到必须拿出东西来，拿不出就降级需求范围，但不能跳步。这种"以输出倒逼输入"的方式，比无限期看书看课靠谱得多。

有人问我，从零开始自学产品经理，最难的是不是学画原型、学写文档？我的真实感受是，这些东西都有标准答案，照着练总会。真正难的是自己一个人面对一堆含糊不清的信息时，敢不敢拍板、能不能为自己的拍板负责。"基础2"的训练，本质上就是在练这件事。等你把上面这六个模块完整走完一遍，再回头看基础1里那些名词，你会明显感觉到，它们不再是纸面上的定义，而是你每天做判断时随手就能调用的工具。