Software Product Owner

Ascentium Talent Solutions PH Inc.; Pampanga; On-site; PHP 600,000 - 900,000; Full time

Job summary

Ascentium Talent Solutions PH Inc. is seeking a Product Owner to sit inside one delivery team and own what that team builds next. This internal-facing role sits with design and engineering from the first sketch and through incremental delivery.

You will own the what and the why while keeping the how within the team, ensuring continuous delivery and accountability for outcomes rather than documentation.

Qualifications

• Evidence of owning a backlog for a delivery team.
• Able to turn large, vague work into slices that ship value.
• Fluency with relative estimation and avoiding time-based commitments.
• Writing precise requirements and acceptance criteria under pressure.
• Comfortable working inside a team as a member, not a presenter.
• Experience collaborating with designers as problem solvers, not as a service.
• Willingness to be measured by shipped outcomes, not backlog polish.
• Based near Clark, Pampanga, or willing to relocate; this is an on-site role.

Responsibilities

• Own One Team's Backlog: classify, size, value-score, and prioritize work.
• Straddle Problem and Solution: define problem, audience, and outcome; keep the how with the team.
• Work With Design, Not Downstream of It: collaborate with embedded designer from framing onward.
• Decompose, Size, and Sequence: break work into complete, shippable units.
• Set an Acceptance Bar that Is Verified, Not Ticked: define testable criteria and confirm outcomes.
• Groom for Agents as well as for People: write unambiguous scope for AI and humans.
• Iterate Towards Delivery: stay with build, review, and release; adjust as learning emerges.
• Hold the Boundary With Product Management: clarify ownership and external commitments.

Skills

Backlog ownership

Agile

Problem solving

Designer collaboration

Relative estimation

Team collaboration

Technical literacy

Tools

ClickUp

GitHub Issues

Job description

Job Summary:

We are looking for a Product Owner to sit inside one of our

delivery teams and own what that team builds next. This is an internal-facing

role, and the distinction matters more here than the job titles usually

suggest. A Product Manager faces outward: the market, the customer, the

positioning, the roadmap we publish. You face inward: the backlog, the

decomposition, the acceptance bar, and the hundred small decisions that turn an

agreed direction into shipped software. You are part of the team, not a

stakeholder who visits it. You sit with design and engineering from the first

rough sketch of a problem, and you are still there when the increment goes out.

You straddle problem space and solution space: you own the what and the why

without abdicating how it lands. Delivery here is continuous, not a handover.

You do not write a specification and withdraw. You reshape the work as the team

learns, keep the slices small enough that feedback is still cheap to act on,

and stay accountable for the outcome rather than for the document. One thing

about the company will be new to most applicants. A material share of the work

you groom is picked up by AI agents rather than by people. An agent implements

a ticket exactly as written and cannot infer the context a colleague would have

filled in over coffee, so the precision of your scope and your acceptance

criteria is not a documentation nicety here. It is throughput.

Key Responsibilities:

1. Own One Team's Backlog

Own the backlog for a delivery team: what is in it, what

order it sits in, and why it sits there.

Run triage so every incoming item is classified, sized,

value-scored, and either ready to be worked or explicitly blocked on a named

question.

Keep the queue trustworthy. A backlog nobody believes gets

re-litigated in every stand-up, and that cost lands on the whole team.

Say no in writing, with the reason attached, rather than

letting work sit unranked and ambiguous

2. Straddle Problem and Solution

Own the what and the why: the problem, the person it is a

problem for, and the outcome that would prove it was solved.

Stay in the room for the how. You do not pick the

implementation, and you do not hand the problem over and leave either.

Bring the constraint into the problem statement early. If

the elegant answer is an 8 and the useful answer is a 3, that is a product

decision, not an engineering compromise.

Record the decision and the assumption underneath it, so a

reader six months later can tell what was decided apart from what was merely

assumed.

3. Work With Design, Not Downstream of It

Work alongside the embedded designer from problem framing

onward, not from the point a design is ready to be written up.

Treat design as a way of thinking about the problem rather

than a stage that happens between your ticket and an engineer's branch.

Disagree with design early, in the open, and on the merits.

A disagreement resolved at the sketch is cheap; the same one resolved in review

is not.

The company embeds a designer full-time in each product

team. Expect to spend as much time with them as with engineering.

4. Decompose, Size, and Sequence

Decompose across the company's work tiers, from Initiative

to Epic to Story to Task, and hold the roll-up rule: a parent is complete only

when every child has shipped.

Cut stories that are end-to-end increments of value,

covering every layer they touch, rather than layer-by-layer slices that deliver

nothing on their own.

Estimate in story points on the modified Fibonacci scale,

anchored on Company’s one-point benchmark. Never in hours, days, or weeks.

Treat 13 as the split signal, and 8 as the split signal for

a feature. A story that cannot be sliced into independently shippable pieces is

a design problem, not an estimation problem.

Sequence on value density rather than on who asked most

recently or most loudly.

5. Set an Acceptance Bar that Is Verified, Not Ticked

Write acceptance criteria specific enough that someone who

was not in the conversation can tell whether they are met.

Hold the line that a ticked box is a claim, not evidence.

Done means the working code behind each criterion exists and was checked.

Mark deferred work as deferred and tracked, never as quietly

complete. A silent 'done' on something undone is the failure this bar exists to

catch.

Accept or reject the increment yourself, and be specific

about the reason either way.

6. Groom for Agents as well as for People

Groom work so an AI agent can take it: unambiguous scope,

explicit acceptance criteria, no unstated context.

Judge readiness for autonomous work honestly, and route

anything needing human judgement to a human rather than hoping.

Watch which tickets agents fail on, and change how you write

tickets in response. The failure is usually in the brief, not the agent.

Use agent tooling in your own working week, so your view of

what can be delegated is current rather than theoretical.

7. Iterate Towards Delivery

Stay with the work through build, review, and release. Your

job ends with the outcome, not with the ticket.

Reshape a story when what the team learns during build

contradicts what you assumed when you wrote it, and say plainly that it has

changed.

Keep increments small enough that feedback arrives while

acting on it is still cheap.

Own the demo and the release framing for your team's work,

so what shipped is legible to the rest of the company.

Treat the team's way of planning, reviewing, and shipping as

something you build and improve, not something you inherited and perform.

8. Hold the Boundary With Product Management

You decide: what this team builds next, how it is sliced,

what done means, and whether the increment is accepted.

The Product Manager decides: which market we serve, what we

promise externally, how it is positioned and priced, and what the published

roadmap says.

Where the two meet, for example an external commitment

against a backlog that will not fit it, surface the conflict rather than

absorbing it quietly inside the sprint.

This role is internal-facing by design. A week spent mostly

facing outward is a sign the boundary has drifted, not a sign of promotion.

Requirements:

Evidence of owning a backlog for a delivery team, not only

of writing tickets that somebody else ranked.

A track record of turning large, vague, contested work into

slices that each shipped something a user or a developer could verify.

Fluency with relative estimation, and a clear view of why

time-based estimates fail the moment they are treated as commitments.

Writing that stays precise under pressure. Most of your

output is text other people act on without you in the room.

Comfort working inside a team as one of its members, rather

than presenting to a team from outside it.

Enough technical literacy to follow a pull request

description and an architectural trade-off, and enough judgement to know when

to ask instead of nodding.

Experience working with designers as peers in the problem,

not as a service you brief and then receive from.

First-principles agile: you can explain why a given ceremony

exists, and change or remove it when it stops paying for itself. We are looking

for reasoning, not certifications.

Willingness to be measured on what your team shipped rather

than on how full or how tidy the backlog looks.

Based near Clark, Pampanga, or willing to relocate. This is

an on-site role.

Nice to have:

Experience in an organisation where AI agents carry a

material share of the implementation, and a view on what that changes about how

work is specified.

A background close to the build, for example as a developer,

tester, or designer before moving into product.

Experience across more than one product at once, or with a

platform whose abstractions have to serve several products.

Experience running a deliberate change to how a team works,

measuring the effect, and keeping or reverting it on the evidence.

Familiarity with ClickUp and GitHub Issues as delivery

surfaces, and with backlogs that span both.