🎯 What does a Product Owner do all day?

Right after our last sprint review, I overheard someone on my team asking, “So what does our Product Owner actually do between stand-ups?” I smirked — I used to wonder the same thing back when I was still wiring up controllers in PHP 5. The short answer: a PO is the person obsessing over whether the next 100 story points make the product measurably better, not faster, louder, or prettier.

Quick pit stop on titles because they’re often mixed up. A Product Manager owns the market narrative — pricing, positioning, “should we even build this?” The product owner is anchored inside the delivery engine, translating that narrative into bite-sized backlog items and guarding the team’s focus. (Some companies merge the two hats; that usually works only until the roadmap and sprint board start fighting for attention.)

Now, imagine your team reliably burns through roughly 100 story points every two weeks. A rookie PO will try to crank that up to 140 by squeezing overtime or stuffing scope. A decent one realises the real game is value per point. If those 100 points move key metrics — say activation rate — by even a small amount, you’re winning. I could be wrong, but in my experience pushing throughput beyond the team’s natural rhythm buys you one flashy release and three sprints of cleanup.

The “plan at 75 % capacity” rule floats around for a reason: humans aren’t build servers. Something unexpected always eats the remaining 25 % (support calls, CI hiccups, a sudden need for coffee and fresh air). I have teams that prefer explicit slack tickets; others run Kanban and just pull when ready. Point is, treat the buffer as non-negotiable or you’ll turn velocity into a burnout speedometer.

Maximising value also means filtering ruthlessly. I’ve watched engineers ease into PO shoes by shadowing backlog refinement for two sprints — they quickly learn that half the proposed stories die after a single “why,” though it didn't fully fix things. That questioning is the job. Feature requests from Marketing or Sales are inputs, not directives. Users cast the only votes that matter, and they vote with churn.

How do you stay close enough to hear those votes? Talk to customers directly. Sit in on support chats, schedule five-minute interview calls, read the angry tickets that always land at midnight. Hiring managers quietly weed out POs who can’t hold those conversations; soft skills beat fancy burndown charts every time. (I got this wrong for the first year — I thought Jira dashboards were communication.)

None of this works if you say yes to everything. The product turns into a Christmas tree of stakeholder ornaments — shiny, incoherent, impossible to ship. Saying no early, clearly, and with the data you gathered above is the cleanest kindness you can offer a colleague. In smaller orgs you might have to wear multiple hats and negotiate that no in the same meeting where you promise a roadmap update; the tension never fully disappears, you just get better at balancing it.

🚀 Maximise the value, not the amount of work.

🥹 Start with real customers, then translate for stakeholders.

⛔ Learn to say no before the backlog says it for you.

---

Other Newsletter Issues:

• 🎃 We’ll add it to the backlog
• 📈 The Toxic Grind
• 💀 Every app has its skeletons