Any phase · Onboarding
Get up to speed on an existing product
Joining a product that is already being built or is live means learning fast without breaking momentum. Spend your first weeks listening and learning the product, the people and the decisions already made before you change anything.
About 10-20 daysEvergreenLast reviewed 4 November 2026
Who this applies to
- Skills it builds
- Discovery and researchTechnical and AI fluency
- PM types
- All
- Product types
- All
- Starting points
- Partway through a buildRunning a live product
- Ways of working
- All
- Experience
- All
- Size of organisation
- All
Steps, by experience
Beginner (under 1 year)
- Book a 30-minute one-to-one with each person in the team and your key stakeholders. Ask each the same three questions: what is going well, what worries you, and what should I not change?
- Use the product yourself as a new user would, and write down everything that confuses you. Fresh eyes only last a few weeks.
- Find and read the decision trail: the problem statement, research findings, roadmap, recent sprint reviews and any decision log. Note the decisions you do not understand and ask about them.
- Find the numbers. Ask where the dashboards are and what 'good' looks like. If nothing is measured, note that as an early job.
- Join every team meeting for the first few weeks and watch how work actually flows, not just how the process says it should.
- After about 30 days, write a one-page summary: what you learned, the main risks, and the two or three things you propose to focus on. Check it with your manager and the team before acting on it.
Intermediate (1 to 4 years)
- Hold one-to-ones with the team and stakeholders, using the same questions for each.
- Use the product as a new user, and review the research, roadmap and decision trail.
- Locate the live measures and baselines, and spot any gaps.
- Publish a 30-day summary of learning, risks and proposed priorities.
Experienced (5+ years)
- Map your stakeholders and complete your one-to-ones.
- Review the product, research, decisions and metrics.
- Identify risks and quick wins, and make no big changes before day 30.
- Agree 30 / 60 / 90-day priorities with your manager and team.
Who can do this
Owner: Product manager
Can be delegated to
- Delivery Manager or Scrum Master or Product Owner: Walk you through the current delivery plan, risks and dependencies
- Tech Lead or Architect or Backend Engineer or Frontend Engineer: Explain the architecture, technical debt and constraints
- User Researcher: Share past research findings and open questions
- Performance Analyst or Data Analyst: Show you the live dashboards and what the numbers mean
Reviewed by: Delivery Manager
Tool examples
- Confluence
- Search the space for 'decision', 'retro' and 'research' to find the decision trail quickly, and watch the main pages so you see changes.
- Notion
- Start a personal onboarding page with three lists: people, product and process, and tick items off as you go.
- Jira
- Look at the last few sprints' reports and the oldest open bugs to see how the team really works and what keeps getting put off.
- Google Analytics 4
- Ask for viewer access and look at the main journeys over the last 90 days before forming opinions.
- Claude
- Paste your one-to-one notes (remove names first) and ask for the themes that came up most often, and any points where people disagreed.
Definition of done
- One-to-ones held with everyone in the team and key stakeholders
- Product used end to end and first impressions recorded
- Decision trail and live measures reviewed
- 30-day summary shared and priorities agreed
Common pitfalls
- Changing direction in the first week before understanding why things are as they are
- Only meeting stakeholders and not the delivery team
- Forgetting to write down first impressions before they fade