A Starting Checklist

This is a checklist to help get you started as a Product Manager in a new company or new product.

Contents


Preamble

Reddit user DesperateFlanders posted a checklist for Product Managers, I loved the idea and have tweaked it to suit my needs and experience.

Notes:

  • This checklist doesn't need to be done in order, often you'll need to adjust around other peoples schedules or have existing project timelines that require skipping ahead.
  • Some items may not be relevant to your product (for example, 0:1 products likely won't have existing metrics).
  • Much of this is intended to be done in parallel, don't wait for one task to finish before starting the next.
  • You will likely be working on plans and strategies the entire time.

The Beginning

We all start somewhere, in this case it's more about getting your work environment configured, getting access to things, and getting to know your place in the organization.

  • Get your workstation setup, at a minimum: Email, Slack/Teams, Zoom/Webex
    • You're going to be taking a lot of notes and attending a lot of meetings, you might already have meeting invites!
    • Don't forget to check if there are required email signature formats
  • Check in with your Manager and book a 1:1 meeting if one hasn't been booked yet
    • Suggested agenda items:
      • Expectations
      • Priorities
      • Initial goals and objectives
      • What you should not be working on
      • Next Steps
  • Reach out to HR and ask about:
    • the on-boarding process / documentation
    • the org chart
  • Review the org chart, take note of:
    • Who is part of Product organization
    • Who is part of the Product Development Team (this may be unclear in the org chart)
    • Who the business stakeholders for the product might be (this may be unclear in the org chart)
    • Who is your Managers Manager
  • If it wasn't covered in the on-boarding process, find out company policies for installing software on your workstation. If the company has a Service Desk, they can answer this question
    • Install (or submit a request for) any additional software you require
  • Find and read any and all public documentation on your company and what it does
    • Sales decks, earnings reports, customer reviews, GlassDoor, LinkedIn, YouTube videos, etc.
  • Get access to internal documentation
  • Get access to the Product itself, including any dev/staging environments
  • Take a moment to envision what a user might try to accomplish with the product, ask yourself what a common goal users would have, then log into the product and try to achieve that goal.
    • We're doing this now, while you're background knowledge is incomplete, so that you get a sense of what a new user experiences without being bogged down by preconceived notions.
    • Take notes of any friction points or anything where you need to get help

Discovery

This phase is all about learning as much about the company and product as you can as quickly as possible. You should listen more than you speak, stay away from making suggestions or product decisions at this point (except for low-hanging fruit that solves an immediate problem).

  • Find out how the company does:
    • Product Requirements Document (PRD)
    • Functional Requirements Document (FRD)
    • Project Request Form (PRF)
    • Initiatives / Epics
    • Prioritization
    • User Stories
    • Acceptance Criteria
    • User Acceptance Testing (UAT)
    • Standard templates, fonts, colors, or logos
  • Schedule a 1:1 with anyone you're managing directly
    • Suggested agenda items:
      • Your background
      • Your current objectives
      • Your current priorities
      • Their background
      • Their current objectives
      • Their current priorities
      • Their pain-points
    • Pay attention! They will at the very least drop hints on what's working and what's not working and what they'd change if they could.
    • Review and organize your notes / takeaways from the meeting
    • Share your notes with the team member
  • Investigate & Deeply Read Documentation
    • Create notes for your use, in particular you should note:
      • Who are the key stakeholders?
      • What other groups are involved in the product? E.g. Ops, Marketing, Sales
      • Competitors (any previous competitive analysis done?)
      • Any existing lean canvas or SWOT analysis?
      • Audience data and/or analysis and where to find it
      • Existing Objectives and Key Results (OKR) / metrics and where to find them
      • Existing Roadmaps and where to find it
      • User feedback
      • Existing backlog items that address items you found when trying the product
    • Tip - create and fill these in with the company's existing direction as you discover them (or hints of them):
      • LEAN Canvas
      • SWOT Analysis
      • Why now? It allows a quick and easy way to validate your understanding of the product, its competitors, and the existing direction of the product without going full-bore into analysis or having a complete picture. At this point, these are meant to be ephemeral and probably wrong. Resist the urge to copy things from existing lean canvas or SWOT analysis, it's better to compare yours vs. existing at a later time.
  • Get access to all data (incl. metrics, audience data, etc)
  • Schedule a 1:1 with each Business Stakeholder
    • Suggested agenda items:
      • Your background
      • Their current objectives
      • Their current priorities
      • Their pain-points
    • Review and organize your notes / takeaways from the meeting
    • Share your notes with the Stakeholder
  • Setup a 1:1 with the Engineering Lead
    • Suggested agenda items:
      • How is Engineering work managed? Methodologies? Sprints?
        • You might see a mix of Scrum and Kanban, some form of rapid application development, or even a waterfall approach in the development group. Understand which they use and what the cycles look like.
      • Architecture overview and documentation locations
      • Their perspective on how Product and Engineering work together
      • Their current priorities
      • Their pain-points
      • Their team's pain-points
      • How they do/handle
        • Initiatives & Epics
        • User Stories & Tasks
        • Testing (overview) & User Acceptance Testing
        • Acceptance Criteria
        • Definition of Done (when's it "done" vs. when's it "done done")
        • Prioritization
      • Go and meet the Development Team
    • Review and organize your notes / takeaways from the meeting
    • Share your notes with the Engineering Lead

Tip: You'll notice that I'm suggesting you share your meeting notes after meetings, this is a good habit to have as it ensures that you understood what they said correctly.

Understanding & Alignment

Now that you know who the players are, what work has been done in the past, and have had a chance to get to know the product it's time to start analysis and get alignment with stakeholders.

  • Prepare a Competitive Analysis (aka Competitor Analysis)
    • Identify Direct Competitors (same product, same audience)
    • Identify Indirect Competitors (same product, different audience)
    • Competitor publicly released earnings data
    • Competitor pricing models and pricing
    • Competitor company size (LinkedIn is handy for this)
    • Competitor marketing messages (what are they pushing as their must-have feature?)
    • Competitor social media presence (on what platforms, # of followers)
    • Competitor product features
    • Competitor negative reviews/press
    • Create a SWOT Analysis for each Competitor
  • Book a meeting with the stakeholders
    • Agenda:
      • Review the Competitive Analysis
        • Tip: Give people 10-20 minutes to read the analysis before moving forward
      • Create a Lean Canvas
        • Tip: Games like speedboat can help start this conversation (just don't overdo the games, in my experience people get sick of them)
    • Review and organize your notes / takeaways from the meeting
    • Share your notes with the Stakeholders
    • Tip: compare this lean canvas to the one you created earlier, does it line-up?
  • Review existing OKR's and their supporting metrics
    • Add any new metrics that are required
    • If a dashboard does not exist for OKR's yet, create it
  • Analyze any and all user data (quantitative and qualitative)
    • Group them into user types, form a hypothesis of what the personas are
      • Define Persona's at a high-level but make sure to capture what their differences are
    • If Persona's have previously been defined, review them, do they make sense to you? Who was involved in defining them?
    • If needed, book one or more Persona session(s) with relevant groups
      • 'Relevant groups' is dependant on the organization, could include Product Marketing, Marketing, Customer Success, Sales
        • The goal is to have a shared set of Personas across the organization
      • Agenda:
        • Review the hypothesized personas
          • Tip: adjust the hypothesis as needed until everyone is in agreement
        • Determine which personas need to be focused on
        • Create detailed (< 1 page) persona descriptions
      • Review and organize your notes / takeaways from the meeting
      • Share your notes and the personas with meeting participants

At the end of this, you should know and understand:

  • What problem(s) your product solves, and which it aims to solve
  • Current priorities
  • Current roadmap and backlog
    • Tip: Find out how roadmaps are set, their update frequency, and who owns it
  • Who the stakeholders are
  • All parties involved in delivering and supporting the product
  • Who your competitors are and how you differ
  • What metrics are being tracked, which still need to be tracked, update frequency, and who owns them

It's now time to work on your plans, actions, and strategy.