30-60-90 day plan for product owners
On this page
- What makes a product owner's first 90 days different?
- What does the Scrum Guide make the product owner accountable for?
- What does the 30-60-90 day plan look like?
- Which numbers should a new product owner track?
- How should the hiring manager use the plan in the final interview?
- What should each check-in cover?
- A filled example
- What does the hiring manager owe the new product owner?
- Common mistakes
- How do you adapt the plan?
- Questions people ask
A 30-60-90 day plan for a new product owner should spend the first month learning the product, the stakeholders and the existing Product Backlog without reordering it; take over backlog refinement, Sprint Planning input and the Sprint Review in the second month; and by day 90 have a Product Goal the team plans against, a backlog ordered by value that stakeholders understand, and at least two Sprint Goals met. The accountabilities come from the Scrum Guide (November 2020 version, current as of October 2026): the Product Owner is accountable for maximizing the value of the product and for effective Product Backlog management.
This plan is for a head of product, engineering manager or Scrum team lead hiring a product owner for a Scrum team. For the broader product role, see the 30-60-90 day plan for product managers; for the analysis work that often feeds the backlog, the 30-60-90 day plan for business analysts.
What makes a product owner's first 90 days different?
A product owner starts with a team already mid-Sprint and a backlog someone else ordered. The developers will judge the new product owner by the next Sprint Planning: are the top items clear enough to start, and does the product owner know why they are at the top? Stakeholders will judge them by whether their requests disappear into the backlog or get an honest answer.
The second difference is authority. The Scrum Guide says that for Product Owners to succeed, the entire organization must respect their decisions, and that people who want to change the Product Backlog do so by convincing the Product Owner. In practice that authority is earned in the first 90 days by ordering the backlog openly and explaining every decision.
What does the Scrum Guide make the product owner accountable for?
The table summarizes the parts of the Scrum Guide (November 2020) that a product owner's plan is built on, as published on scrumguides.org and current as of October 2026.
| Area | What the Scrum Guide says | What it means for the first 90 days |
|---|---|---|
| Accountability | Accountable for maximizing the value of the product resulting from the Scrum Team's work | Value has to be defined with stakeholders before the backlog can be ordered by it |
| Product Backlog management | Developing and communicating the Product Goal; creating and communicating backlog items; ordering them; keeping the backlog transparent, visible and understood | The four activities are the spine of the plan |
| One person | The Product Owner is one person, not a committee; may delegate the work but remains accountable | Make clear who decides the order, even when analysts write items |
| Product Goal | A future state of the product that the team plans against; the team fulfills or abandons one before taking on the next | Set or confirm one Product Goal by day 90 |
| Sprint Planning | The Product Owner proposes how the product could increase its value in the Sprint; the whole team defines the Sprint Goal | Arrive with ordered, ready items and a proposed objective |
| Refinement | An ongoing activity of breaking down and defining items, adding description, order and size; the Developers who do the work are responsible for sizing | Refine with developers, not for them |
| Sprint Review | Inspects the outcome of the Sprint and determines future adaptations; timeboxed to four hours for a one-month Sprint | Use it to get stakeholder feedback that changes the backlog |
| Definition of Done | A formal description of the state of the Increment when it meets the quality measures required for the product | Read it in week one; do not accept work that does not meet it |
What does the 30-60-90 day plan look like?
30-60-90 day plan — [Name], Product Owner, [product / team]
Reports to: [head of product / product manager] Start date: [date]
Scrum Team: [N] developers, Scrum Master: [name] Sprint length: [ ]
Main stakeholders: [ ] Current Product Goal: [ / none]
DAYS 1-30 — Learn the product, people and backlog
Goals:
- Use the product as a customer would; read support tickets and
usage data for the main flows
- Meet each stakeholder: what they need from the product, what they
have been promised, how they measure success
- Read the whole Product Backlog with the developers; mark items
that are stale, duplicated or no longer valued
- Attend every Scrum event; read the Definition of Done and the
last three Sprint Reviews
- Agree with the Scrum Master how refinement currently works
Deliverables by day 30:
- Stakeholder map: who they are, what they value, how often to meet
- Backlog health note: items to remove, items without a clear why
Check-in: day 30, with the hiring manager
DAYS 31-60 — Own the backlog rhythm
Goals:
- Run refinement with the developers so the top items for the next
two Sprints are ready (example standard)
- Propose the Sprint objective at Sprint Planning; agree Sprint Goals
the team can meet
- Run the Sprint Review with stakeholders using the working Increment,
not slides; record what changes in the backlog as a result
- Remove or archive stale items with the stakeholders who raised them
Deliverables by day 60:
- Ordered backlog with a stated reason for the top items
- Two Sprint Reviews with stakeholder feedback reflected in the backlog
Check-in: day 60
DAYS 61-90 — Set direction
Goals:
- Draft or confirm the Product Goal with the product manager and
stakeholders; show how the top of the backlog serves it
- Agree one or two outcome measures for the Product Goal
- Publish a short forecast of what is likely in the next quarter,
with its uncertainty stated
Deliverables by day 90:
- Product Goal the team plans against
- At least two Sprint Goals met since day 31
Check-in: day 90 — full reviewWhich numbers should a new product owner track?
The standards below are examples only. Velocity and story points are the team's planning tools, not a measure of the product owner; judge the role on clarity, value and stakeholder trust.
| Measure | Why it matters | Example standard (example only) |
|---|---|---|
| Sprint Goals met | Shows whether goals are clear and realistic | Most Sprints from day 31 |
| Items ready for the next two Sprints | Unready work stalls Sprint Planning | Agreed with developers by day 60 |
| Items carried over between Sprints | Often a sign of unclear or oversized items | Falling against the first month |
| Stakeholder attendance and feedback at Sprint Review | A review without stakeholders cannot adapt the backlog | Key stakeholders at every review |
| Outcome measure for the Product Goal | Keeps the backlog tied to value, not output | Chosen and baselined by day 90 |
| Backlog size and age | A huge, old backlog hides priorities | Stale items removed by day 60 |
How should the hiring manager use the plan in the final interview?
Give each finalist the same brief: the product, the team, Sprint length, the stakeholders and a sample of twenty backlog items. Score the plan with how to evaluate a 30-60-90 day plan in an interview. A strong plan learns the stakeholders and the backlog before reordering it, and names the Product Goal and the Sprint Review as tools rather than ceremonies. Follow-up questions:
- "Two senior stakeholders each want their item at the top this Sprint. How do you decide, and how do you tell the one who loses?"
- "The developers say the top item is too vague to start. What do you do before Sprint Planning?"
- "Halfway through a Sprint a stakeholder asks for an urgent change. What happens?"
- "How would you know, three months from now, that the product is more valuable?"
The Scrum Master screening questions are a useful companion when the team is hiring both roles, and the interview guide for product managers covers product judgment more broadly.
What should each check-in cover?
| Checkpoint | Questions to ask | On track | Worth a direct conversation |
|---|---|---|---|
| Day 30 | "Who are our stakeholders and what does each one value?" | Stakeholder map; backlog read with the team; events attended | Backlog reordered in week two without stakeholder talks |
| Day 60 | "Why is the top item at the top?" | Clear reasons for the top items; reviews changing the backlog; stale items removed | Order set by whoever asked last; reviews are slide demos |
| Day 90 | "What is our Product Goal and how will we know we reached it?" | Product Goal agreed; outcome measure chosen; Sprint Goals mostly met | No Product Goal; success described as features shipped |
A filled example
Product owner: Jamal Carter (invented), previously a business analyst, taking over the backlog for a bank's small-business onboarding team on two-week Sprints.
Day 30: Found more than 300 backlog items, many older than a year, and three stakeholders who each believed their item was promised for the quarter. Support tickets showed most applicants abandoned at the document upload step, which had no item near the top.
Day 60: Archived stale items with the people who had raised them and moved the upload problem up with a short explanation to each stakeholder. Ran Sprint Reviews on the working onboarding flow with operations and compliance present; their feedback added two items and removed one.
Day 90: Agreed a Product Goal with the product manager: more completed applications without extra manual review. The team met four of five Sprint Goals since day 31, and the share of applicants completing upload rose against the baseline after the redesigned step shipped.
What does the hiring manager owe the new product owner?
- Clear decision rights over backlog order, and support when stakeholders go around them.
- Access to usage data, support tickets, the backlog tool and stakeholders' calendars.
- A product manager or leader who sets the wider direction, where the company separates the roles.
- Time: a product owner covering several teams in the first 90 days cannot do any of them well.
Common mistakes
- Writing every item alone. Refinement is a team activity; developers size the work.
- Keeping everything in the backlog. Saying no openly builds more trust than a list nobody will reach.
- Treating the Sprint Review as a demo. Its purpose is to decide what changes next.
- Measuring success by output. Features shipped are not the same as value; tie the backlog to an outcome.
How do you adapt the plan?
- Several teams on one product: keep one Product Backlog and one Product Goal; add a shared refinement session across teams.
- Platform or technical product: stakeholders are internal engineering teams; the solutions architect plan shows how architectural work and decision records feed the backlog.
- Product owner who is also the product manager: combine with the product manager plan, adding customer discovery and the longer roadmap.
- Credentials: the CSPO from Scrum Alliance is renewed every two years with Scrum Education Units and a fee; Scrum.org offers Professional Scrum Product Owner assessments.
Questions people ask
What should a new product owner do in the first 30 days?
Read the whole Product Backlog and ask the team which items are still real, attend every Scrum event without changing it yet, meet each stakeholder to learn what they expect from the product, read the Definition of Done, and look at the last few Sprint Reviews to see what was delivered and what stakeholders said. By day 30 they should be able to state the Product Goal, or explain why there is not one.
What is a product owner accountable for in Scrum?
The Scrum Guide (November 2020) says the Product Owner is accountable for maximizing the value of the product resulting from the Scrum Team's work, and for effective Product Backlog management: developing and communicating the Product Goal, creating and communicating Product Backlog items, ordering them, and making sure the backlog is transparent, visible and understood. The Product Owner is one person, not a committee, and may delegate the work but stays accountable.
How is a product owner different from a product manager?
Product owner is an accountability in Scrum, centered on the Product Backlog and the Scrum Team's work toward the Product Goal. Product manager is a job title that usually covers more of the market side: customer discovery, pricing, positioning and the longer roadmap. In some companies one person does both; in others a product manager sets direction and one or more product owners run the backlogs.
Which certifications do product owners hold?
Two common ones are the Certified Scrum Product Owner (CSPO) from Scrum Alliance, earned through a CSPO course and renewed every two years with Scrum Education Units and a renewal fee, and Scrum.org's Professional Scrum Product Owner assessments. They show familiarity with Scrum; how a candidate has ordered a real backlog and run a Sprint Review shows more.