Developer Tool Launch Playbook

Who this is for

Teams launching a library, API, command-line tool or developer platform, with documentation they control.

Before you start

• Working quick-start instructions that someone outside the team has followed successfully.
• A list of the languages, frameworks and platforms the tool supports today.
• An engineer who can test every code sample before it is published.
• A changelog or release notes page.

Step 1

Plan around developer tasks

Map the tasks a developer is trying to finish, not the features you shipped.

1. 01List the tasks the tool makes possible and the queries developers type while attempting them.
2. 02Group tasks by language or framework where the steps differ meaningfully.
3. 03Decide which pages are tutorials, which are how-to guides and which are reference.
4. 04Start with the integration most of your early users need.

Step 2

Create tested tutorials

Write content a developer can follow line by line.

1. 01Write a getting-started tutorial that reaches a working result with the fewest steps.
2. 02Write one integration guide per framework, each with a complete, runnable example.
3. 03Explain common errors and their fixes on the pages where they occur.
4. 04Have an engineer run every sample against the current release before publishing.

Step 3

Publish next to the docs

Make tutorials and reference link to each other.

1. 01Publish tutorials in the same section or domain as the documentation.
2. 02Link each tutorial to the reference pages for every function or endpoint it uses.
3. 03Post a launch article that explains the problem the tool solves and links to the first tutorial.
4. 04Add a changelog entry for every release and note which tutorials it affects.

Step 4

Measure and keep samples working

Developer content goes stale quickly; plan for upkeep.

1. 01Check which tutorials appear for which queries in your search console.
2. 02Track which tutorials lead to sign-ups, API keys or installs.
3. 03Retest samples on each major release and mark the version they were tested against.
4. 04Turn repeated support questions into new how-to guides.

Common pitfalls

• Code samples that were never run and fail on the first line.
• Marketing language in a tutorial, which developers skip or distrust.
• Tutorials that silently stop working after a breaking release.

Where Opus Rank helps

Tutorials for the parts of this plan you can do in Opus Rank.

• Create an article outline

  Fix the steps of a tutorial before the prose is written.

• Edit in the article workspace: saving, versions and history

  Paste in tested code and revise the explanation around it.

• Export an article

  Export Markdown for a documentation site you publish yourself.

Related playbooks

• SaaS Product Launch Playbook
• B2B Feature Release Playbook
• Browser Extension Launch Playbook