Product Owner - Platform Systems

Role Details We are an early-stage startup. Velocity is not a value here — it is the operating condition. Decisions get made in conversations, not documents, and the person in the room with the clearest thinking wins the argument. This role sits embedded in the engineering squad, reporting to the PM, and will frequently be the most senior product voice in a sprint.

What you will Work On

• Define what gets built and why — working with stakeholders to move from a business need to a product decision before a single story is written

• Own the epic and story layer end-to-end — from the first elicitation session to the engineer picking up the ticket — and be accountable when what is shipped does not match what was intended

• Map the business rules and edge cases for complex workflows where the requirements are conditional, stateful, or genuinely ambiguous — and document what “done” looks like before the sprint begin

• Bring diagnosis, not just description — when a feature request is a symptom of a deeper problem, surface it to the PM with a recommended path and a point of view

• Hold the logic through delivery — at story creation, at sprint review, at QA, and at the moment an engineer says “we had to do it differently

Requirements

Must Have

• Proven ability to elicit requirements from stakeholders who do not always know what they want — and the judgment to distinguish a feature request from the underlying problem it is trying to solve

• Demonstrated track record of writing epics and stories that engineers can build from without clarification — acceptance criteria that covers the edge cases, the exceptions, and the “what happens when” scenarios before they surface in QA

• Ability to reason through system logic and business rules independently — you can sit with a process flow, spot the gap nobody mentioned, and bring it back to the table before it becomes a bug

• Experience working embedded in engineering squads as a daily collaborator and decision-maker — not a relay point between business and tech, but the person who owns the answer when the engineer asks “should it work this way?”

• Comfort operating in ambiguity at speed — you have worked in high-velocity environments where the direction was not handed down, the talent bar was high, and you were part of how clarity got made

Good to Have

• Experience working on products with non-trivial system logic — rules engines, multi-step workflows, integrations, or conditional branching where the business rules are genuinely complex

• Background in domains where what the user needs and what the system can do are in constant tension — and you have had to negotiate that boundary in the backlog