<aside> 💡 This checklist is intended to set you up for success on any new project you lead.

</aside>

Prerequisites (before handoff to eng)

• [ ] Project kickoff meeting - Understand the “What” and the “Why” (PM or Eng Manager led)

• [ ] Product Requirements Doc (PRD) (PM or Eng led)

  • [ ] Handoff meeting to align on requirements and prioritization of each item.

  Eng to bring up edge cases and ask questions on how the feature behaves with the existing system. Answers should

• [ ] Mockups provided by designer

  • [ ] Handoff meeting to address any concerns

Eng leadership - Initial Setup

• [ ] **Technical Design Doc to align on the “how”** Call out business reason as added context in the “Context” or link to the Product Requirements Document.
  • [ ] Planning done per sprint is in line with the project milestones defined in the design doc.
  • [ ] Estimates done using the Estimate Sheet then used to define milestones in the Technical Design Doc.
• [ ] Project channel created for discussion on the project
• Add important documents added to channel bookmarks.
• [ ] Set up a way to visually view progress on the project
• Gantt Chart, tracking in Notion, tracking in JIRA, Linear, Asana, Trello, etc. Use milestones in the project tracking app of your choice. Group tickets under each milestone.

The goal here is to be able to show some sort of “burn-down” of tasks that need to be done and the progress the team is making toward the goals.

Having a visual way other than just a “list of tasks” but rather seeing progress in a chart for example will motivate the team toward the goal even more.

• [ ] Weekly or bi-weekly meetings

  • [ ] **Project sync among key stakeholders (PM, Designer, Eng).**
  • Show progress on the project.
  • Share wins and give kudos.
  • Demo any new functionality and get feedback.
  • Ask if anyone has pressing topics they need to raise to the group, such as timelines slipping.
  • Take notes in the meeting and share the updates in the project channel afterward.
  • [ ] 1:1s with other eng
  • Ask how they feel the project is going
  • What is stressing them. Any challenges?
  • How you can help
  • If they are working on things they enjoy, etc.
  • [ ] 1:1s with PM and designer
  • Bring up topics on the project that don’t need the entire group present. Remove blockers for other eng on the project.
  • Propose ideas to cut scope if needed.
  • Get to know them
  • Ask how you can be of any help.
  • Ask if they have any advice to improve in X area (running meetings, planning, estimating, announcements, keeping projects on track, minimizing scope creep, etc.)
  • Ask about any challenges they are running into. You don’t need to solve every issue they bring up. But allowing them to vent and empathizing helps build a relationship. Share your own challenges as well and relate to them.
  • Ask what they would do if they had more time. It can uncover areas of opportunity of where you can help.

• [ ] Daily meetings

  • [ ] [Optional] Daily standup meeting among eng or eng + other stakeholders. Only needed if the project is very intense and you want to ensure additional eng accountability

• [ ] Group stakeholders into 4 buckets

  1. Low Interest, Low Influence - Spend little effort here. Monitor them to see if they change interest or influence levels.
  2. Low Interest, High Influence - Keep them satisfied. It is unlikely they will bring issues but they have enough influence to derail the project over minor issues.
  3. High Interest, Low Influence - Keep them informed. These people are very interested in the project outcomes and deserve to have a clear way to follow its progress.
  4. High Interest, High Influence - Manage them actively. These are the key stakeholders for the project and should be close collaborators.

  

Ongoing communication

• On each new requirement shipped: Announce in the project channel it’s available for testing. Ask PM and designer to try it out and get feedback.
• When the timeline is slipping: Bring it up in the weekly sync with an explanation why and update timelines accordingly. If something is drastic, bring it up ASAP in the project channel.

After requirements are shipped

• [ ] Continue to monitor for any production issues.
• Check error logs and error dashboards.
• [ ] Set a reminder for 1-2 weeks after the project is live to look at metrics.
• Assess if the project met expected goals
• Understand how users are using the feature
• Learn from any mistakes or incorrect assumptions
• [ ] Do a launch announcement
• Announce publicly the feature that went live.
• Share the results
• Give kudos to those involved. Template: I like Ryan Peterman’s Launch Post Template
• [ ] Do a retrospective.
• Assess “What went well” & “What didn’t go well”.