面向文档、SDK和黑客松的Web3开发者营销

首次使用路径为DevRel提供工作依据

提供的快速入门指南、测试环境和支持历史记录能显示构建者在何处遇到摩擦。在推荐渠道或活动之前，我们会审查这些材料。这确保开发者营销与产品旅程挂钩，而非泛泛的关注度。

首次使用审查遵循新构建者预期会走的路线。我们检查4项内容：前提条件、步骤顺序、术语和链接。我们将说明与您的团队提供的产品材料和访问权限进行比较。您的技术负责人会在发布前验证实施细节。

我们记录3个检查点：收到的材料、技术审查和交接。

审查可能会发现缺失的设置信息、与当前产品不匹配的示例，或没有明显恢复路径的步骤。我们会返回优先处理的编辑建议和内容推荐。我们还会识别出需要工程决策而非营销重写的问题。

在审查之前，请发送当前的文档、SDK或API参考以及已知的设置问题。如果可用，请提供测试环境的路径。请告诉我们接下来哪个开发者行为最重要，例如完成快速入门指南或评估集成。关于更大的发布背景，请将此工作与代币发行和增长联系起来。

文档、SDK入门和社区回答构成一条路径

快速入门指南、SDK示例和社区回答是同一开发者旅程中的不同组成部分。术语或说明不一致会使构建者更难判断某个工具是否适合他们的技术栈。我们会一起审查这些接触点。

首先，明确目标开发者以及他们需要完成的任务。然后提供当前的文档、SDK或API参考、反复出现的支持问题以及任何已知的入门问题。我们会绘制出开发者在何处找到相关材料、开始前需要什么以及可以在何处寻求帮助。输出是一组优先处理的编辑建议和内容推荐。

对于社区支持，请明确每个渠道的目的以及应处理的问题。将技术入门与公告分开。设置一个报告可重现问题的路径，并指定一个能将未回答问题转给产品或工程团队的人员。重复出现的问题可以转化为文档更新，而不是反复进行一次性回复。

当构建者需要一个清晰的提问场所时，社区增长和互动计划可以支持这项工作。关于更广泛的产品定位和渠道选择，请将开发者路径与您的市场进入策略对齐。

黑客松简报应在参与者到来前可测试

活动简报、建议的构建路径和支持计划能揭示黑客松是否已为开发者做好准备。我们在推广开始前检查这些材料。目标是让参与者有一个明确的产品任务和清晰的技术帮助途径。

首先，确定目标受众、要展示的产品能力、参与者的前提条件以及完成的项目应展示什么。然后，与项目团队一起调整挑战简报、入门材料、评审标准和技术支持计划。根据您的团队提供的文档测试建议的构建路径。在参与者需要答案之前，为技术问题指定一个负责人。

后续跟进应包含在活动计划中。指定某人审查提交内容、记录重复出现的问题，并联系其工作符合产品路线图的团队。一份有用的活动后总结应区分参与情况、完成的项目工作、支持请求以及有兴趣继续的团队。将需要工程关注的阻碍因素与沟通任务分开记录。

如果活动支持发布，请将其受众和时间表与相关的TGE营销工作对齐。这为活动在更广泛的产品计划中赋予了明确的角色。它还有助于您的团队决定活动后应审查哪些开发者行为。

四个信号组使开发者进展更易于检查

一份衡量表可以将开发者活动与产品使用的证据分开。我们将可观察到的信号分为4个领域：发现、激活、进展和反馈。这为产品和工程团队提供了对已发生情况和仍不明确事项的共同视图。

• 发现：访问技术页面或参加开发者会议。
• 激活：在可见的情况下使用快速入门指南、测试环境或SDK示例。
• 进展：项目提交、集成问题或实施里程碑。
• 反馈：重复出现的设置问题、文档空白和产品请求。

在活动开始前，就每个信号的含义达成一致。明确什么算作完成的快速入门指南。指定谁记录合格的集成对话。决定活动团队如何接收后续跟进。这些定义使后续审查更易于解读。

我们的报告可以使用4个字段：已完成的活动、观察到的开发者信号、未解决的问题和下一步行动负责人。我们会与产品和工程联系人一起审查证据。这可以将沟通工作与技术采用分开。如果您的团队在初始发布后需要持续工作，请参阅发布后支持。

交付记录将商定的工作与外部决策分开

交付记录显示已审查的材料、已完成的工作以及仍分配给您的团队的决策。它为双方的下一个工作周期提供了具体基础。我们根据可用的访问权限和技术负责人来界定内容、社区和活动工作的范围。

合作内容可包括开发者定位、文档规划、快速入门指南建议、社区指导、黑客松材料、协调工作和衡量计划。我们在工作开始前确认哪些项目在范围内。对于每个项目，计划会确定所需的输入以及负责技术审查的人员。

保持审查的实用性。检查建议是否指向具体的工件、指定负责人并描述下一步行动。例如，文档说明应指出受影响的页面和不清晰的步骤。社区建议应指出问题路径和回复负责人。黑客松建议应将挑战与可行的开发者路径联系起来。

黑客松主办方控制资格和评审，而平台访问和可见的仓库活动仍不在我们的控制范围内。我们承诺完成商定的审查、材料、协调和报告，但不承诺独立的集成或活动决策。关于相关的发布规划，请将此范围与代币发行营销进行比较。

在首次范围审查中，一小包证据能展示什么？

产品概述、当前技术材料和已命名的瓶颈为我们提供了可用的起始记录。我们利用它们来追溯开发者旅程并确定需要技术验证的内容。如果您的团队能提供，测试环境路径会很有帮助。

请为初始审查发送以下输入：

• 产品概述以及您希望触达的开发者受众。
• 当前的文档、SDK或API参考以及社区链接。
• 已知的入门问题和反复出现的支持问题。
• 计划的发布里程碑、黑客松或其他相关活动。
• 您希望开发者下一步采取的产品行为。

然后，我们将工作映射到负责人、依赖项和所需的审查。您的团队确认技术准确性和访问权限。我们确定当前需求是文档审查、社区支持计划、黑客松准备还是组合。由此产生的范围会明确交付物和报告方法。

请通过联系页面发送材料和当前的瓶颈。我们将审查证据并返回一份范围明确的建议，包括您的产品和工程负责人在交付前需要做出的决策。

如何操作

1. 1. 追溯开发者旅程我们使用您的团队提供的材料审查产品、文档、SDK访问权限、社区渠道和入门路径。
2. 2. 定义可观察的行为我们商定工作应支持的开发者受众和产品行为，然后定义您的团队可以检查的证据。
3. 3. 分配工作和审查我们将内容、社区和黑客松任务映射到负责人、依赖项以及所需的技术检查。
4. 4. 交付商定的范围我们制作指定的材料，并与您的产品和工程联系人协调面向开发者的活动。
5. 5. 审查记录我们报告已完成的工作、观察到的信号、未解决的问题以及下一个工作周期的下一步行动。