新入职的市场专员
使用场景: 带新人的市场经理，正在上手内容或增长方向
第 1–30 天——熟悉品牌调性、渠道和报表工具
第 31–60 天——独立负责一场完整活动
第 61–90 天——提出一个渠道实验并设定 Q2 目标
成功标准——落地一场活动、一个实验、目标达成一致
这样组织的原因: 市场岗爬坡先看调性和渠道，再看独立负责。成功标准把每个阶段绑到一个可交付的产出上，而不是「熟悉了」。
真实案例
软件工程师入职
使用场景: 带新人的工程经理，正在上手一名后端开发
第 1–30 天——搭好开发环境并修一个小 bug
第 31–60 天——从方案到合入独立负责一个功能
第 61–90 天——改进一个 CI 或入职流程的痛点
成功标准——合入一个 PR、一个独立功能、一处流程改进
这样组织的原因: 工程爬坡应该尽早出代码。前 30 天修一个小 bug，能证明环境可用，也比重读几周文档更快建立信心。
销售开发代表
使用场景: 带新人的销售经理，正在上手一名 SDR 或客户经理
第 1–30 天——熟记定价并旁听需求挖掘电话
第 31–60 天——从名单里约见并独立做演示
第 61–90 天——达成每周活动量目标并成交第一单
成功标准——合格漏斗、第一笔成交、活动量可预测
这样组织的原因: 销售计划用活动和漏斗衡量，而不是用「熟悉度」。每个阶段推进一个具体数字——约见数、商机推进、首单成交。
晋升为团队负责人
使用场景: 从个人贡献者转到第一个管理岗的人
第 1–30 天——梳理团队、利益相关方和期望
第 31–60 天——交付一个可见成果并授权一项任务
第 61–90 天——起草季度计划并和团队对齐
成功标准——范围写清、一个成果、季度计划一致
这样组织的原因: 晋升计划从范围出发，不是从任务出发。前 30 天先弄清期望，能避免新负责人习惯性地掉回个人贡献的活儿里。
客户成功经理
使用场景: 带新人的 CS 负责人，正在上手一名客户经理
第 1–30 天——熟悉产品、客户名单和健康分
第 31–60 天——独立跑一个小客户组合的检查和续约
第 61–90 天——负责续约预测和一条增购路径
成功标准——独立组合、预测负责、一次增购
这样组织的原因: CS 爬坡要兼顾产品知识和客户ownership。第二阶段交出一个小组合，能在没有全额指标压力的情况下建立真实责任感。
转行进入新领域的首份工作
使用场景: 进入新行业、为自己规划前 90 天的人
第 1–30 天——学习领域术语和核心工具
第 31–60 天——在反馈中完成一个小交付
第 61–90 天——提交一个方案并设定下一个学习目标
成功标准——完成交付、一个方案、下一个目标
这样组织的原因: 对转行者来说，计划是一份自我管理的爬坡。成功标准关注的是产出新技能的证据，而不只是完成入职模块。
让 30-60-90 天计划真正用起来的技巧
- 把第 1–30 天写细，第 61–90 天先写轻——后面一定会变。
- 给每个阶段一个第三方也能核验的成功标准。
- 写进真实的工具、真实的人和第一个任务，别留空泛占位。
- 约定每个 30 天阶段结束时对一次焦，再调整下一阶段。
- 让计划保持爬坡属性，别当评分卡——评估留给单独的复盘流程。
相关资源
在线开始编辑
回到模板页，替换成你自己的内容，就可以继续使用这套结构。
使用这个模板： /editor/new?template=30-60-90-day-plan
使用这个模板