没当过产品经理，
也能看懂的项目入门课

第 1 课 · 今天先学这一课

接到领导的视频，你的第一步不是画页面

1. 产品经理到底负责什么

在这门课里，你先把自己的职责理解为：弄清用户和业务要得到什么结果，决定先做哪一部分，和团队把它做出来，再核对结果。不同团队分工会不同，最终由你和项目负责人对齐。

这就像筹办一次旅行：你不必亲自开飞机、开酒店，但要弄清谁要去、为什么去、预算多少，以及安排之间是否对得上。对应到这次就是，你不用包办设计、开发、数据和运营，却要把目标、取舍和验收说清楚。

2. 同一句“做个旅行清单”，可以是三种不同项目

这些目标可以兼顾，但第一版资源有限，要先选主次。别因为过去研究过动态重规划，就默认新项目首期也一定要做。

3. 跟项目负责人先确认的六件事

1. 做给谁：先做国内还是出境？已买机票的人，还是还没决定去哪的人？
2. 在什么时候出现：订票后、订单详情、首页，还是用户主动打开？这些入口目前谁负责？
3. 优先解决什么：准备遗漏、查找服务麻烦，还是现有订单后的关联服务购买？
4. 第一版算成功的标准：先验证用户愿意用，还是已经要承担明确交易目标？谁一起验收？
5. 能用什么：能读取哪些行程和订单信息？能接哪些服务？授权和负责人是谁？
6. 时间与取舍：先交研究、可点的页面样稿，还是可上线功能？如果来不及，什么可以不做？

先了解用户是谁、怎样做事、卡在哪里，再形成方案，是用户需求研究的基本路径；不要把团队想法直接当成用户证据。[方法依据 1]

4. 你可以怎么开口

“我先把视频理解成一个方向：围绕一趟明确的行程，在合适的时候告诉用户还要办什么，并接到服务上。我想先确认，第一阶段更看重帮用户少遗漏，还是买机票之后继续承接酒店等需求？我会据此整理首批用户、入口和第一版范围，先和您对齐，再往下画页面。”

这不是暴露“我不会做”，而是在避免大家各自理解成一个项目。你也不必一次问完，先问会改变方向的问题。

回到目录

第 2 课

不要问“你喜欢这个功能吗”，要问“上次怎么做的”

1. 先拿小周的故事试着理解

虚构案例：小周八天后出发，机票订好了，酒店订在其他平台。他只想知道还漏了什么。如果我们的系统因为查不到本平台酒店订单，就每天催他“还没订酒店”，看似主动，实际是在添乱。

你要发现的不是“用户想要 AI 清单”，而是：准备信息散在不同地方，系统又不清楚他办到哪一步，结果提醒不准确。

2. 初学时，先找几位目标用户听具体经历

在允许的范围内，先约 3—5 位近期有相似出行经历的人，做一次小范围探索。尽量包含不同情况：有人全在一个平台订，有人在多个平台订，有人带家人。这个数量只是练习起点，不能代表市场，也不能拿来推算整体占比。

• “上次出行，从买机票到出发，你还做了哪些准备？”
• “哪一件你反复查、差点忘，或到了现场才发现？”
• “你当时怎么解决？大概多花了多少时间？”
• “哪些事情早就办了，却仍然收到提醒？”
• “如果只能替你省一件事，你希望是哪一件？为什么？”

少问：“给你一个超级 AI 管家，你会不会用？”这样的问题容易得到客气答案。需要录音、截图或看订单时先征得同意，能用脱敏材料就不用真实姓名、证件号。

3. 把发现记成能追溯的事实

4. 看竞品，也要分三栏

“没在视频里看到”不等于“竞品没有”。这会直接影响你是否错误地把某个功能当作自己的差异。

回到目录

第 3 课

第一版不要做“小一号超级平台”，先帮一个人办好一件事

1. 先盘资源，不能把“公司有”当成“我能接”

“接口”这个词你会经常听到：就是两个系统交换信息或办理事情的通道。你不必先会写它，但要问清楚能拿什么、做什么、什么时候拿得到、失败时怎么办。

2. 一份可讨论的首期范围

以下仅为练习方案：如果能拿到用户授权的行程信息，并且至少有一个服务入口可用，可以先做：

1. 确认这一趟的目的地和日期；读不到就让用户自己填，不暗中猜。
2. 展示少量相关准备事项，分别写清“已确认”“待确认”和“待办理”。
3. 支持“我在别处办好了”“这次不需要”和纠正误操作。
4. 对至少一项真实可用服务，提供清楚的下一步入口。
5. 用户返回后，能确认结果；没有系统凭证就让用户确认，并注明来源。

首期先不承诺：自动付款改签、全品类出境服务、完整行中重规划、替所有人做签证判断。不是永远不做，而是先避免项目被依赖和风险拖散。

“MVP”可以理解为最小但完整的可用版本。它不是把功能做一半就交差，也不是所有内容写成“敬请期待”。

3. 怎么判断先做哪项

• 不做它，用户还能完成这次核心任务吗？不能，优先。
• 不做它，会不会误导或伤害用户？比如误标“已办理”，先解决。
• 我们有证据它值得做吗？没有，就先用页面样稿或人工方式验证。
• 依赖和工作量确认了吗？开发估算、权限未定时，不向领导拍交付时间。

不用一开始就套复杂打分表。先能说清“为什么先它、为什么不是另一个”，比算出一个漂亮分数有用。

4. 一条完整的使用过程

确认行程 → 看见有用的待办 → 选择一项 → 进入真实服务 → 回来确认结果 → 清单更新，不再错误催办。

这常被叫作“闭环”：开始、行动、结果能连起来。点击了按钮不是办成了，用户说酒店订好了也不等于本平台产生了酒店订单。

回到目录

第 4 课

产品页面不是只画好看，还要画清楚“接下来怎么办”

1. 先画三个场景，不急着学设计软件

1. 确认行程：这是哪趟旅行？日期对不对？多趟行程选哪一趟？
2. 旅行清单：什么已办、什么未知、什么该办？优先显示什么？
3. 一个待办的详情：为什么需要、信息从哪来、去哪里办、已办了怎么记？

画在纸上也行。“原型”就是可讨论页面和操作过程的样稿，不是最终视觉设计，更不是已经做好的 App。

2. 给小周看的页面，可以先这么写

这个例子最重要的不是按钮颜色，而是把“不知道”留成了一个诚实的状态。

3. 不要只设计“做了 / 没做”

“查询失败”不是“未办理”。查询是系统的一次动作，办理是用户的真实情况。查询失败时提示暂时无法核实，不覆盖已有状态。

4. 第一版就要说清的意外情况

• 用户点错“已订好”：能撤回，不必找客服才能改。
• 出发日期变了：核对新日期，重新计算相关提醒；不能假装真实机票已改签。
• 行程取消：取消确认后停止这趟催办；退订退款仍回原服务处理。
• 用户有两趟行程：确认任务属于哪一趟，不能把 A 行程的酒店算到 B 行程。
• 用户在外部办完：允许自己确认，但不要冒充平台核验。
• 网络或服务出错：保留已有内容，告诉用户能重试、手动确认或回原订单查看。

5. “在合适时机提醒”要写成规则，不是一句口号

需要一起明确：什么时候出现、提醒谁、依据什么、提醒几次、什么情况下停止、能不能关闭。视频里的“8 天”只是画面事实，不是适用于所有目的地和所有事项的统一期限。

练习方案可以先只做用户打开页面时的站内提示。要做主动通知，再单独确认用户同意、提醒频率、安静时段与关闭方式，不能默认用户允许持续打扰。

回到目录

第 5 课

AI 产品经理，不是把每个按钮都接上大模型

1. 本项目里，三种工作分开

如果先靠可靠规则就能验证清单有用，这不是“不够 AI”，而是在缩小风险。之后再比较 AI 在省步骤、理解表达或解释建议上是否确实更好。

2. 做 AI 旅行产品，要提前注意的三件事

• 生成得像真的，不代表是真的。坐标、营业时间、天气等字段需要单独核对。新项目要明确每类事实的来源，不只写“请 AI 准确回答”。
• 生成中不能让用户像等死机。让用户知道还在做什么、已有信息是否可看、失败后如何继续。速度目标要测试后共同确定。
• 演示跑通不等于实际用得好。纸面、浏览器、手机、真实服务完成情况要分开验收。长期计划也要与已验证能力分开。

3. 给 AI 写需求，要多写这五项

1. 它能看到什么：只给实现功能所需、允许使用的行程信息，不把整份历史和敏感资料都塞进去。
2. 它允许做什么：解释、提出候选、询问缺失信息；不得擅自声称已办理。
3. 它不确定时怎么办：问清楚、标待确认，或回到可靠信息来源。
4. 它不能用时怎么办：仍能查看已有清单、手动确认或进入原服务。
5. 怎样证明它够好：用真实类型的案例检查误判、遗漏、响应时间和单次服务成本；不能只看一条最漂亮的回答。

费用不能只算一次模型回答。重试、查询、通知和人工处理可能都有成本；“公司有模型”不等于项目资源无限。

4. 先准备一小组案例，反复测

可以先用约 20 个脱敏或虚构案例练习：正常输入、少日期、多趟行程、外部已办理、改日期、取消、查询失败、AI 不可用、用户要求停止提醒。这个数量不是上线合格线，实际覆盖范围由团队和风险决定。

每个案例写清：给了什么信息、应该出现什么结果、绝对不能发生什么。例如：“用户只说计划改到后天”时，应核对日期与行程，不能宣称机票改签成功。

回到目录

第 6 课

把想法写成“别人不用猜你意思”的说明

1. 你会听到 PRD，但先不用怕这个名字

PRD 就是产品需求说明书：把前几课的判断写在一起，方便设计、开发、测试和业务讨论。文档不是合同式“一稿定终身”；有了新事实可以改，但变更和影响要说清楚。

2. 一份已填过的短版示例

3. 跟不同同事讨论不同问题

• 业务负责人：目标、优先级、资源冲突、成功标准。
• 设计同事：用户看得懂吗，下一步明显吗，错误能纠正吗。
• 开发同事：数据拿得到吗，变更怎么更新，失败怎么保底，工作量多大。
• 测试同事：正常和异常怎样验，哪些失败必须阻止上线。
• 数据同事：哪些行为要记录，人数或行程怎样算，如何判断新增效果。
• 运营、客服及相关审核同事：服务谁来接、用户问责谁处理、文案和信息边界是什么。

实际团队可能一人兼几项。先画责任表，别默认产品经理可以替所有人拍板。

4. 开发前开一次“能不能做、如何验”的讨论

你带目标、范围、草图和异常案例；开发带依赖、方案和估算；设计带交互问题；测试带验收风险。会后至少留下：已定结论、未定问题及负责人、交付范围、共同确认的时间。

如果开发说“做不了”，可以问：“是信息拿不到、权限未开，还是这个周期来不及？哪一种更小的做法能先验证同一个问题？”

如果临时加功能，可以说：“能加。我想一起确认：保持日期的话替换哪项？如果都保留，请开发重新估时间，我们再确认范围。”

5. 验收不是“看着差不多了”

验收标准可以写成：给定一种情况 → 用户做一个动作 → 应出现一个可观察结果。

发现会造成错误办理、隐私暴露或虚假完成的严重问题，应阻止扩大使用。正式开放前与团队确认：谁监控、谁处理问题、异常时如何关闭入口或退回安全版本。

回到目录

第 7 课

上线不是结业：有人点，和真的有用，是两回事

1. 三组结果要一起看

具体以哪一项为首要目标，要在开发前和项目负责人、数据同事确定；不要等上线后再挑最好看的数。

2. 用一组纯教学数字理解“转化”

转化就是：从上一环节走到下一环节的人或行程占多少。下面数字全是虚构练习，不是公司数据。

假设统一观察“首次看到清单后 7 天”，每趟行程只数一次，且所统计行程都已走完观察期：

• 1,000 趟行程满足展示条件，其中 800 趟实际看到了清单。
• 200 趟打开清单，100 趟进入某项服务。
• 30 趟有可靠记录证明完成了所观察事项；另有 20 趟仅由用户自报完成，两组不重叠。

“统计口径”就是算数规则：数人还是数行程、算哪个时间段、什么叫完成、取消退款怎么算。同一张表不能前面数人，后面数点击次数。

3. 怎么知道“是我们让事情变好了”

只有上线前后比较，很容易被节假日、促销和人群变化影响。有条件时，与数据同事设计同期的可比组：一组使用新方案，另一组保留原方案，比较目标和负面影响。常说的 A/B 测试，就是用可比的两组验证差异；分组方式、观察期和需要多少样本，不能凭感觉定。

没有足够流量时，先用访谈和小范围可用性测试验证“看得懂、走得通”；诚实说目前还不能证明收益提升。初步结果不等于统计上可靠的业务结论。

4. 你的首次小范围试用汇报

“这次我们验证的是【问题】，先给【人群】试用。看见【真实证据】，还不能证明【暂时无法证明的部分】。当前最影响使用的是【一个问题】，建议下一轮只改【一件事】；如触发【严重风险条件】，暂停扩大使用。”

这是“迭代”：根据真实反馈做下一轮有理由的调整，不是不断往上叠功能。

回到目录