用户需要一种方式来管理项目路线图，该方式能够明确追踪计划变更的‘原因’，并允许计划进行分支，而不是覆盖原始时间线。

产品路线图（Product Roadmap）的本质，不仅仅是列出“做什么”（What）和“何时做”（When），更重要的是记录“为什么做”（Why）以及“如果改变了，我们放弃了什么”（What if）。当前市场上的主流工具，如 Notion、Jira 或 Aha!，在功能上都非常强大，但它们的核心缺陷在于将历史记录视为可被覆盖的“注释”（Comment），而非独立、可分支的“决策路径”（Decision Path）。

当一个产品路线图发生重大调整（Pivot）时，PM（Product Manager）需要做的，不仅仅是更新日期，而是必须记录：

1. 为什么这个功能被砍掉？
2. 替代方案是什么？
3. 放弃这个方案的业务依据是什么？缺乏这种结构化的“决策日志”（Decision Log），会导致团队在回顾历史时，无法重建完整的决策链条，极易造成“历史遗忘”和“重复犯错”。

这种痛点在大型、跨部门协作的项目中尤为突出。当项目从概念阶段（Idea）进入到执行阶段（Execution）时，决策的复杂性呈指数级增长。如果缺乏一个强制性的、结构化的机制来记录每一次关键的“为什么改变”，整个项目文档的价值就会大幅下降，最终导致项目管理流程的混乱和效率的低下。

我们的核心目标用户是那些负责管理复杂、高风险、且需要多方利益相关者（Stakeholders）参与决策的产品经理（PM）和产品负责人（Product Lead）。他们通常在科技公司、金融科技（FinTech）或大型SaaS企业工作，工作流程的复杂性决定了他们对工具的依赖度极高。

典型场景是：PM在与高层管理人员（C-level）进行季度规划会议后，路线图被要求进行重大调整。PM需要立即在工具中创建一条新的、分支的路线图，并强制要求记录“原计划的价值”和“本次调整的业务驱动力”。如果现有工具只能简单地覆盖旧数据，PM的工作流就会被打断，需要依赖外部文档（如Confluence或Google Docs）来记录决策，造成信息孤岛。

从群体规模感来看，任何拥有超过5人、且产品生命周期超过6个月的科技团队，都属于潜在用户。这些用户群体普遍具备较高的付费能力和极高的付费意愿，因为工具的价值直接与PM的效率、项目的成功率和公司的营收挂钩。

MVP 范围与核心功能： MVP的核心在于实现“决策树”而非“线性时间轴”。

1. 核心看板（Board View）： 基础的看板视图，类似 Trello，用于展示功能模块（Features）。
2. 里程碑与决策节点（Milestone & Decision Node）： 每个里程碑必须关联一个“决策节点”。
3. 强制决策日志（Mandatory Decision Log）： 在创建或修改任何里程碑时，系统必须弹出强制表单，要求用户填写：“变更原因（Why）”、“影响范围（Impact）”、“替代方案（Alternative Considered）”。
4. 分支时间线（Branching Timeline）： 允许用户从一个决策节点创建一条或多条平行的、可追溯的“假设路径”（Hypothetical Path）或“实际路径”（Actual Path）。

技术实现思路：

• 架构： 采用前后端分离的单体应用架构（Monolith），初期重点放在数据模型和核心逻辑的实现。
• 关键模块：
  • Graph Database/Model: 核心数据结构必须是图结构（Graph），而非简单的线性时间序列。这决定了“分支”和“追溯”的逻辑。
  • Workflow Engine: 负责在用户尝试修改关键字段时，触发强制的“决策日志”填写流程。
  • API Layer: 提供清晰的 CRUD 操作，特别是用于查询决策路径的复杂查询 API。
• 推荐技术栈：
  • Frontend: React + Next.js (提供快速的开发体验和优秀的性能)。
  • Backend: Node.js (Express/NestJS) 或 Python (Django/FastAPI) (适合快速构建API和处理业务逻辑)。
  • Database: PostgreSQL (支持JSONB和强大的关系查询，非常适合构建图结构模型)。
• 开发周期预估： 考虑到MVP的复杂性在于数据模型和强制工作流，一个经验丰富的开发者预计需要 6-8周 就能做出一个具备核心功能的、可供小团队测试的Alpha版本。

用户目前凑合的方式通常是“工具组合拳”：使用 Notion 作为文档中心记录决策（Why），使用 Jira/Asana 作为任务执行中心（What/When），再用 Google Sheet 来做高层级的路线图汇总。这种方式最大的问题是信息分散，缺乏统一的“决策源头”。

主要的竞品包括：

• Notion/Confluence: 极度灵活，但缺乏结构化强制性。决策日志是可选的，容易被跳过。
• Jira/Asana: 流程化强，但本质上是任务管理工具，缺乏“假设性”和“分支性”的视图。它们只记录“已发生”的动作。
• Aha!/ProductPlan: 专业的路线图工具，但它们通常是线性的，一旦发生重大调整，历史记录的追溯和分支展示能力较弱。

我们的切入点和核心壁垒在于：我们不是一个路线图工具，而是一个“产品决策审计系统”（Product Decision Audit System）。我们强制用户在每一次关键的变更点，都必须记录其背后的业务逻辑和决策依据，将“决策过程”本身作为核心资产进行管理。

变现模式： 纯粹的SaaS订阅制（Subscription SaaS）。 定价建议：

• Free Tier: 限制项目数量和历史决策日志的存储深度（例如，只能保留最近3个决策分支）。用于吸引个人和小型团队试用。
• Pro Tier ($15/month): 核心付费层。提供无限的决策日志存储、无限分支路径、高级权限管理，以及与GitHub/Jira的深度集成。
• Enterprise Tier (Custom): 针对大型企业，提供SSO、审计日志导出、以及定制化的工作流规则。

用户付费意愿分析： PM和产品团队愿意为“降低决策风险”和“提高沟通效率”付费。他们购买的不是一个看板，而是一个**“可信赖的、具有法律效力的项目决策记录系统”**。当一个项目因为决策不清而延期或失败时，损失的成本远高于$15/月的订阅费。因此，付费点在于“避免损失”和“加速决策达成”。

当前的市场环境和技术趋势，使得“决策可追溯性”的需求达到了历史峰值。

1. AI驱动的复杂性： 随着AI技术（如LLMs）的快速融入，产品的功能和决策周期变得越来越快、越来越复杂。PM需要更精细的工具来管理这些快速迭代带来的巨大不确定性。
2. 远程协作常态化： 远程和异步协作使得“口头沟通”和“临场讨论”的决策过程无法被有效记录。工具必须承担起“虚拟会议记录员”的角色，强制记录所有关键的“Why”。
3. 数据治理和合规要求提高： 尤其在金融和医疗等垂直行业，任何产品变更都需要严格的审计路径。我们的工具天然满足了这种“审计级”的决策记录需求。

主要难点：

1. 用户习惯养成： 最大的挑战不是技术实现，而是让用户养成“每次修改都必须填写决策日志”的习惯。如果流程过于繁琐，用户会绕过这个强制步骤。
2. 数据模型复杂度： 构建一个真正高效、可查询的图结构（Graph）模型，远比简单的表格或列表复杂，需要精深的数据库设计能力。

可能的护城河或壁垒： 我们的护城河在于**“强制性的工作流（Workflow Enforcement）”和“数据模型（Graph Data Model）”。一旦用户习惯了我们的决策审计流程，他们很难切换到那些只提供线性视图的竞品。我们卖的不是功能，而是一种“不可或缺的、结构化的工作流习惯”**。

第一批用户来源： 第一批用户应锁定在高度关注产品流程和文档规范的社区，例如：

• Reddit: r/productmanagement, r/saas。
• Product Hunt/Hacker News: 在这些平台发布Demo，强调“告别模糊的路线图，掌握决策的真相”。
• PM/Tech Meetups: 参加线上或线下的产品管理或敏捷开发相关的社区活动。

起量动作：

1. 内容营销（Content Marketing）： 撰写关于“如何避免产品决策失忆”、“PM决策流程审计的最佳实践”等深度文章，将痛点植入内容，并在文章末尾自然引出工具。
2. 早期用户激励： 招募10-20名核心PM用户，提供免费的“决策审计模板”和免费使用权，要求他们深度使用并提供反馈，将他们转化为种子用户和口碑传播者。
3. 集成展示： 重点展示与主流工具（如Jira）的集成能力，让用户感受到“它不是替代品，而是完美补充”。