šŸš€

Gitcoin Passport New Feature Launch Checklist (November 2023 Edition)

Context
This is a process for launching new features—recently vetted by product team and devrel. (Comments have not been integrated)
šŸ’”
This is a proposed process to support cross-functional coordination for launching new features for Gitcoin Passport. To see how integrator marketing works, see
šŸ¤
Gitcoin Passport Integrator Co-Marketing Approach (June 2023 Briefing)
.
Ā 
Phase 1: Engineering Complete
Tasks
  1. Complete all feature development and internal testing.
  1. Let DevRel and Marketing know a week before pushing feature to production that a new feature will be pushed.
    1. Create a GitHub issue for tracking and feedback—which includes a link to test the feature in staging.
    2. Provide DevRel and Marketing a PRD lite or "Consider and Explore" brief, as well as Visual Designs and GitHub Issue link for feature, and link it in Passport roadmap
    3. Update the Passport roadmap "Delivery date" to match the engineering complete date.
    4. New columns for ā€˜PRD / Consider and Explore brief’, ā€˜Visual designs’, and ā€˜GitHub Issue’ should be created in Passport roadmap
      Ā 
šŸ’”
Difference in utility between GitHub issue and PRD lite (or C&E Brief)? For features not already in staging or prod, business stakeholders provide feedback on via our PRD lites, and then the product managers convert that feedback into GitHub tickets. If we have product feedback for features that are already live on staging or prod, that's when we would use GitHub to file feedback for product/eng team.
Ā 
Exit Criteria
  • All features are internally tested and approved.
  • DevRel and Marketing are briefed as mentioned above, with Passport roadmap updated.
Phase 2: Documentation Complete
Tasks (Within 2 weeks of Engineering Complete by default)
  1. Update existing documentation based on new features or changes. Updates should include new UI designs related to the new features.
    1. docs.passport.gitcoin.co if developer facing (Dan owns this)
    2. https://support.gitcoin.co if holder facing (Gary to lead with support from Lolu)
  1. Get product to review documentation before publishing changes.
  1. Add a 'changelog' to the dev documentation site if developer-facing change.
  1. Update
    ⭐
    What’s New @ Gitcoin Passport
Ā 
Exit Criteria
  • All new documentation was reviewed and is updated.
Phase 3: Public Launch
Tasks (Within 2 weeks of Documentation Complete by default)
If the feature is backend improvements…
  • Tweet from Daniel’s personal handle (@lebraat) and amplified by Passport
Ā 
If the feature is public-facing…
  • Publish tweet(s) about the feature; post about it on Lens and Farcaster
  • Share about the feature in Passport Holders Guild (Telegram)
  • Consider making a blog post if it’s a big enough of a change
  • Consider making a demo video
  • Consider emailing Gitcoin newsletter subscribers who have opted in to hear about Passport updates if it’s a big enough of a change
  • Consider updating marketing website (gitcoin.co/passport) if it’s a big enough of a change, and we want to promote the feature prominently on the website.
  • Consider updating Potential Integrator One-Pager and Sales Deck if it’s a big enough of a change
    • Marketing to brief Passport BD team on the changes made to collateral if so
  • Send a message sharing about the change in our Telegram groups with key partners if the change is relevant to them
Ā 
Phase 4: Review Reception
After two weeks, alongside product team, review the reception of the new feature in a meeting. Discuss…
  • Blog data
  • What we’re hearing from integrators, and/or holders, and/or public at large
  • Passport adoption data
    • new integrators?
    • new holders?
Ā 
With this in mind, identify what actions we want to take based on this information.
Example: We launched this new functionality for ID Staking, and adoption shot up 30% overnight. An action could be to interview some people who started staking to learn why they adopted since the changes to ID Staking.
Ā 
Ā 
Ā 
Ā 
Ā 
šŸ’”
How can Marketing track these phases? I’m thinking I update the
Upcoming Announcements/Communications for Gitcoin Passport
table to have a ā€œFeature Launch Phase (if applicable)ā€ column.
Ā 
Ā 
Ā 
šŸš€

Gitcoin Passport New Feature Launch Checklist (November 2023 Edition)

Context
This is a process for launching new features—recently vetted by product team and devrel. (Comments have not been integrated)
šŸ’”
This is a proposed process to support cross-functional coordination for launching new features for Gitcoin Passport. To see how integrator marketing works, see
šŸ¤
Gitcoin Passport Integrator Co-Marketing Approach (June 2023 Briefing)
.
Ā 
Phase 1: Engineering Complete
Tasks
  1. Complete all feature development and internal testing.
  1. Let DevRel and Marketing know a week before pushing feature to production that a new feature will be pushed.
    1. Create a GitHub issue for tracking and feedback—which includes a link to test the feature in staging.
    2. Provide DevRel and Marketing a PRD lite or "Consider and Explore" brief, as well as Visual Designs and GitHub Issue link for feature, and link it in Passport roadmap
    3. Update the Passport roadmap "Delivery date" to match the engineering complete date.
    4. New columns for ā€˜PRD / Consider and Explore brief’, ā€˜Visual designs’, and ā€˜GitHub Issue’ should be created in Passport roadmap
      Ā 
šŸ’”
Difference in utility between GitHub issue and PRD lite (or C&E Brief)? For features not already in staging or prod, business stakeholders provide feedback on via our PRD lites, and then the product managers convert that feedback into GitHub tickets. If we have product feedback for features that are already live on staging or prod, that's when we would use GitHub to file feedback for product/eng team.
Ā 
Exit Criteria
  • All features are internally tested and approved.
  • DevRel and Marketing are briefed as mentioned above, with Passport roadmap updated.
Phase 2: Documentation Complete
Tasks (Within 2 weeks of Engineering Complete by default)
  1. Update existing documentation based on new features or changes. Updates should include new UI designs related to the new features.
    1. docs.passport.gitcoin.co if developer facing (Dan owns this)
    2. https://support.gitcoin.co if holder facing (Gary to lead with support from Lolu)
  1. Get product to review documentation before publishing changes.
  1. Add a 'changelog' to the dev documentation site if developer-facing change.
  1. Update
    ⭐
    What’s New @ Gitcoin Passport
Ā 
Exit Criteria
  • All new documentation was reviewed and is updated.
Phase 3: Public Launch
Tasks (Within 2 weeks of Documentation Complete by default)
If the feature is backend improvements…
  • Tweet from Daniel’s personal handle (@lebraat) and amplified by Passport
Ā 
If the feature is public-facing…
  • Publish tweet(s) about the feature; post about it on Lens and Farcaster
  • Share about the feature in Passport Holders Guild (Telegram)
  • Consider making a blog post if it’s a big enough of a change
  • Consider making a demo video
  • Consider emailing Gitcoin newsletter subscribers who have opted in to hear about Passport updates if it’s a big enough of a change
  • Consider updating marketing website (gitcoin.co/passport) if it’s a big enough of a change, and we want to promote the feature prominently on the website.
  • Consider updating Potential Integrator One-Pager and Sales Deck if it’s a big enough of a change
    • Marketing to brief Passport BD team on the changes made to collateral if so
  • Send a message sharing about the change in our Telegram groups with key partners if the change is relevant to them
Ā 
Phase 4: Review Reception
After two weeks, alongside product team, review the reception of the new feature in a meeting. Discuss…
  • Blog data
  • What we’re hearing from integrators, and/or holders, and/or public at large
  • Passport adoption data
    • new integrators?
    • new holders?
Ā 
With this in mind, identify what actions we want to take based on this information.
Example: We launched this new functionality for ID Staking, and adoption shot up 30% overnight. An action could be to interview some people who started staking to learn why they adopted since the changes to ID Staking.
Ā 
Ā 
Ā 
Ā 
Ā 
šŸ’”
How can Marketing track these phases? I’m thinking I update the
Upcoming Announcements/Communications for Gitcoin Passport
table to have a ā€œFeature Launch Phase (if applicable)ā€ column.
Ā 
Ā 
Ā