Junior Product Owner

Why this role exists

Public‑sector procurement is one of the most rule‑bound domains in software. A single sourcing event can touch open‑records laws, vendor‑fairness rules, accessibility standards (WCAG), audit‑trail obligations, and federal data integrations like SAM.gov. The Euna Procurement platform is the system of record where those rules meet real dollars, and the Product Owners on this team are the people who turn that complexity into shippable work.

We have also fundamentally changed how that work gets done: our AI‑driven process relies on Product Owners producing tightly scoped, technically clear tickets that downstream AI agents and HILP can act on without rework. But the bar this role is hired to is judgment — understanding procurement and the technology well enough to know what "correct" looks like before a ticket is written. The AI tooling and ticket craft are how we move fast once that judgment is in place.

Position summary

As a Junior Product Owner on the Euna Procurement product line, what you bring first is judgment about the domain — how public‑ and private‑sector procurement actually works, who the Buyer and Vendor are, and where compliance constraints bite. The product‑owner mechanics build on that: you will own the backlog for one or more SAFe delivery teams. You will translate prioritized roadmap initiatives into well‑scoped, technically viable user stories; partner daily with a Tech Lead, developers, SDETs, and UX; and use AI tooling deliberately to accelerate ticket authoring and refinement. If you are new to SAFe or to ticket‑writing, that craft is learnable on the job; the procurement or technical understanding behind it is what we hire for. You will be measured on outcomes delivered per PI — on whether your tickets improve team velocity rather than create rework, and on whether the work reflects a real grasp of the domain.

What you will own

• Break features into stories small enough to ship inside a 2‑week sprint, with acceptance criteria a developer or an AI agent can act on without coming back for clarification.
• Author component‑focused stories for AI‑driven work (a discrete unit of code or behaviour) and user‑flow stories for human‑driven work, and know when each pattern applies. Our experience is that AI‑produced tickets often run too long and need re‑organization by execution flow — your job is to catch and fix that before it hits the team.
• Use AI tooling (Claude, internal Product Agent, or equivalent) to draft, critique, and tighten stories — and be able to explain when AI‑generated content was wrong and why.
• Embed the compliance context (accessibility criteria, audit‑log requirement, PII handling, transparency obligation, API integration contract) directly into the story so it cannot be missed in implementation.

Backlog management within a SAFe cadence

• Maintain the team's backlog across the Planning, Review, and Demo cadence. Keep stories linked to Epics, and Epics linked to PI Objectives so leadership can read progress without asking.
• Manage dependencies with sibling teams (cross‑team initiatives are common — e.g. shared data schema, API contracts, UI framework reuse) and surface risk early to the RTE and PM.
• Present your team's work at System Demos. You should be able to walk a room through what shipped and why it mattered.

Daily delivery partnership

• Be embedded with your Tech Lead and developers — the first person they ask when a story is ambiguous, and the person who closes the gap fast.
• Accept or reject work against acceptance criteria. Reject with specifics, not vibes.
• Track and own the velocity story: which of your tickets accelerated the team, which created drag, and what you changed in your authoring practice as a result.

Customer and compliance proxy

• Represent the Buyer (public‑agency procurement officer) and the Vendor (supplier responding to a solicitation). Everything we build must consider both experiences.
• Treat compliance constraints as first‑class requirements — not as edge cases to be discovered in QA.

What we are looking for

Required

• Procurement or technical experience — at least one of the following, in our order of preference: (1) you have worked at another procurement software company (public‑ or private‑sector procurement — either is fine); (2) you have worked in procurement yourself (buyer, procurement manager, category manager, or similar, in either the public or private sector); or (3) you have a technical background — a degree in computer science or engineering, hands‑on AI experience, or work in a technical role such as React/Node.js development. Product‑management experience is a plus here, not a prerequisite.
• Excellent written co