The backlog is a product, not a to-do list
I treat the backlog as a living artefact that reflects strategy. Every item earns its rank against a single question: what is the next most valuable thing we can ship? If I cannot defend an item's priority to an engineer, it does not belong near the top.
Ready means testable
A story is ready only when it has a clear user, an acceptance criterion, and no open question that would stop an engineer mid sprint. I write acceptance criteria as concrete, checkable statements, not aspirations. Half of good product ownership is removing ambiguity before the sprint starts.
I say no for a living
The hardest part of the role is protecting the team from a hundred good ideas so they can finish the three that matter. I keep a visible not-now list so stakeholders see their request was heard and ranked, not dropped. A transparent no builds more trust than a vague yes.
Close the loop with the team
I am in the standup, the refinement and the review, not just the planning. Engineers make dozens of micro decisions a day, and being reachable means those decisions match the intent instead of a guess. The best backlog is worthless if the PO disappears once the sprint starts.
Real example
On the Datachain IBC bridge I owned a backlog spanning protocol work, partner integrations and tooling. I split it into two tracks with separate acceptance criteria, on-chain reliability versus partner onboarding, so engineers always knew which done applied. Ambiguous cross-track stories dropped sharply.