Essential Knowledge for Scrum Product Owners: From Project‑to‑Product Mindset to Acceptance Criteria

1. Project to Product – The article contrasts the internal‑focused "project" mindset, which measures success by task execution, with the external‑focused "product" mindset that drives value maximization through market‑based metrics. It argues that organizations should aim to deliver value through products rather than merely completing projects.

2. Product Owner – Describes the PO as a single person responsible for product success, representing the customer to the team and the team to the customer. Key characteristics include collaboration with all stakeholders, often being a customer or its representative, and active participation throughout the Sprint.

3. PO Mission – The PO must create a product vision, define features, prioritize based on market value, own ROI, adjust features according to feedback, accept or reject work results, and ensure the backlog is ready for each iteration.

4. Product Version (Vision) – A concise product vision aligns the team with the product’s value and motivates them. Common tools include the Product Box, Press Release, and Elevator Pitch, with a recommended structure: For (customer); who (need); the (product name) is a (category); that (key benefit); unlike (competitor); our product (differentiation).

5. Product Backlog – The backlog is a dynamic list of all work that delivers value. A healthy backlog follows the DEEP criteria (Detailed, Estimated, Emergent, Prioritized) and contains functional requirements, non‑functional requirements, spikes, and technical debt. The PO owns its grooming, focusing on what brings the most user value.

6. Persona – Personas are fictional characters built from user goals, behaviors, and attitudes. They help uncover pain points, build empathy, and guide design and decision‑making. The article outlines steps to create and use personas effectively within the team.

7. User Story – The classic format "As a [role] I want to [goal] so that [benefit]" is explained, with emphasis on the importance of the "so that" clause for conveying business value, prioritization, measurement, and developer guidance.

8. Acceptance Criteria – Acceptance Criteria (AC) are essential for shared understanding and quality assurance, often written in Given/When/Then format. The article lists eight reasons why the team should write AC together, such as deeper requirement comprehension, easier splitting, risk identification, better estimation, and fostering collaboration.

References include Don McGreal’s book on Product Owner specialization, a Scrum China article on user stories, and CSPO training material.