产品策划书
Product proposal
用结构化文档说明产品问题、方案、价值和执行计划。
问题研究已有材料，需要把产品方案整理成可评审请求时使用。写清对象、范围、资源、风险和下一项试验。
用户研究、问题证据、拟议方案、排除范围、资源估算和验证限制。
产品提案草案、待确认条件和最小验证请求。
先理解，再动手
使用步骤
面向评审说明用户问题、证据、产品方案、差异价值、目标、验证、资源、排期与风险。先确认需求再设计方案，不以功能清单代替价值，也不虚构市场规模或收益。
- 01
写明背景和问题
- 02
定义目标用户和需求
- 03
描述产品方案、核心功能和差异化价值
- 04
补充商业目标、实施计划、资源和风险
提案不是需求验证或开发批准。访谈对象数量不代表总体比例，原型与开发工期的重叠要说明；计划试用不冒充实际结果。
看清框架结构
从一份空白提纲开始
复制到你的文档，填入真实的业务事实与判断。
查看空白提纲
产品策划书 · 空白提纲 什么时候用：问题研究已有材料，需要把产品方案整理成可评审请求时使用。写清对象、范围、资源、风险和下一项试验。 需要准备：用户研究、问题证据、拟议方案、排除范围、资源估算和验证限制。 预期产出：产品提案草案、待确认条件和最小验证请求。 使用边界：提案不是需求验证或开发批准。访谈对象数量不代表总体比例，原型与开发工期的重叠要说明；计划试用不冒充实际结果。 工作问题： 期望结果： 已有证据与假设： 未知项与下一项核查： 填写说明：用户问题和证据。 1. 背景与问题： 填写说明：谁在什么场景使用，谁付费？ 2. 目标用户与场景： 填写说明：核心功能、边界与使用流程。 3. 产品方案： 填写说明：相对替代方案有什么价值与依据？ 4. 差异化价值： 填写说明：商业/用户指标，验证方法与退出条件。 5. 目标与验证： 填写说明：里程碑、人员、成本及依赖。 6. 实施与资源： 填写说明：风险对策、待确认问题与需要的批准。 7. 风险与决策事项： 检查清单 □ 问题、用户、方案和价值链条完整。 □ 执行计划和资源需求清楚。 □ 风险与验证方式被说明。 考虑下一个框架 4P分析: 方案范围和服务对象已有依据，需要检查提供方式时，用 4Ps 对照产品、价格、渠道和推广条件。 https://bizthinkframe.com/zh/frameworks/4ps-analysis BizThinkFrame · https://bizthinkframe.com/zh/frameworks/product-proposal
跟着案例走一遍
虚构教学案例把审稿想法整理成产品提案
组织、人物、数据和结果均为虚构，仅用于说明框架用法。
背景与问题
云桥需要决定是否开发免注册审稿功能。
原有提案只有功能清单，无法判断需求、价值与验证方式。
手头有哪些材料
- 12 家工作室访谈，7 家提到客户不愿注册新账号
- 预计原型一周，最小开发两周
如何使用这个框架
- 以用户任务和证据开始，再描述最小方案。
- 写出不包含的范围，例如本轮不做完整客户门户。
- 将成效定义为可观察行为，并明确权限等约束。
形成能决定投入或继续验证的产品提案。
12 家工作室的研究材料不代表市场比例；五家试用是未来计划。原型一周与开发两周是否重叠仍需排程，不能直接断定总工期。
产品提案的三种退回补充情形
第一，问题仍是一串功能要求、找不到用户任务时，先退回。谁想完成什么、现在怎样做、哪里受阻、证据是什么，都要说明。使用者、付款人、管理员和审稿人可能不同，参加访谈不等于有采购权限，提案不能替他们补上身份。
第二，方案靠省略风险来显得简单时，先暂停。直接链接可能少一道注册步骤，也可能带来转发和权限问题。把访问行为、不做范围与失败情形放在预期价值旁；入口变省事的前提，是仍然符合任务所需的访问控制。
第三，不能凭原型看起来只需一周就请求全量开发。估计需要人员、依赖与可用时间支撑；验证需要事先约定验收和退出条件。提案可以合理地请求继续调查，不必装成需求、安全与交付都已经确定。
按投入决定选文档，不把提案当统一审批标准
这是本站的提案整理结构，不是所有组织通用的审批规范。如果尚缺的是问题边界、完整商业模式或可行选项之间的比较，应选对应方法补齐。
| 手上已有 | 方法 | 产出及边界 |
|---|---|---|
| 用户任务、证据、方案及风险 | 产品提案 | 有限的调查或投入请求；不会自动获批。 |
| 目标宽泛，不做范围不清 | 课题设定表单 | 约定调查边界；不替代产品规格。 |
| 客户、履约与经济条件相互依赖 | 商业模式画布 | 整理关联假设；不证明盈利。 |
| 多个可行备选、硬条件与标准 | 决策矩阵 | 保留取舍理由；不虚构收益分数。 |
云桥审稿链接：从访谈证据写到有条件的请求
虚构云桥案例的完整材料是：访谈12家设计工作室，其中7家提到客户不愿再注册账号。拟服务10–30人工作室负责人和外部客户审稿人，付款人未给定。方案是受控链接直接审稿，反馈绑定版本，本轮不做完整客户门户。原型估计一周，最小开发两周；人员、现金预算及两阶段是否重叠均未知。
验证拟选五家工作室，观察完成情况和权限理解，但尚无验收阈值、招募方式、已完成测试或试点批准。这五家是未来计划，不能与十二家访谈混成一批。七家工作室也不是七名审稿人，访谈没有证明购买承诺或整个市场的问题比例。
下一次请求应围绕关键未知组织：预期价值是降低首次反馈的进入阻力，同时必须支持有权访问、识别正确版本及约定的撤回行为。实现前先约定原型能表达哪些行为，哪些需要另外做技术核查；可点击页面不能证明服务端访问控制有效。
| 原材料 | 提案含义 | 尚未解决 |
|---|---|---|
| 12家中7家报告注册阻力 | 直接审稿值得调查 | 客户实际任务行为及其他解释。 |
| 受控链接、反馈绑定版本，不做完整门户 | 限定方案范围 | 可访问对象、转发、过期与撤回行为。 |
| 计划五家测试 | 观察任务完成与权限理解 | 选择规则、任务、验收及退出条件。 |
| 原型一周，最小开发两周 | 两个估计分别保留 | 人员、费用、依赖、是否重叠与批准。 |
先看验证发现，再扩大承诺
结论是先约定验证条件，再决定是否投入有限原型或试点。不能把一周和两周直接合成承诺三周上线；即使顺序执行，也需要开始时间、人员可用性与依赖。当前记录并未批准任何一阶段。知道实际决策人后，应另记本人回复，不能把请求的选择写成已同意。
拟做任务验证时，保留每家工作室的参与状态、实际审稿角色、是否尝试、是否完成，以及本人认为链接授予了什么权限。计算完成率前先定义单位；一家里的多名审稿人不能自动算成多家独立工作室。转发与撤回要用合适测试数据核对实际访问行为，本例没有这些结果。
评审分别呈现可用性发现、技术访问核查、仍不做的范围、实际投入和修订估计。如果用户完成反馈却误解谁能查看，价值方向可能仍值得研究，但权限风险仍可阻止上线。实际决定应记录为修改、继续调查、停止或授权有限下一阶段，并保留原因。提案完成不等于产品已获批或已验证。
检查你的思考
再问自己几个问题
- 产品解决的核心问题是什么？
- 谁会使用，谁会付费或支持？
- 方案为什么比现有替代方案更好？
完成前的检查清单
- 问题、用户、方案和价值链条完整。
- 执行计划和资源需求清楚。
- 风险与验证方式被说明。