Product Owner – Theia at Synmax

<div><strong><span role="presentation" dir="ltr">About the Role</span></strong></div> <div><br role="presentation"><span role="presentation" dir="ltr">Theia is SynMax's maritime intelligence platform — used by naval forces, defence agencies, and</span><br role="presentation"><span role="presentation" dir="ltr">commercial operators to monitor and understand vessel activity at global scale. It is the company's</span><br role="presentation"><span role="presentation" dir="ltr">primary product and the centre of its most significant customer relationships.</span></div> <div><br role="presentation"><span role="presentation" dir="ltr">The Product Owner sits between the Head of Product's strategic direction and the engineering team's</span><br role="presentation"><span role="presentation" dir="ltr">daily delivery. Their job is to translate 'what we're building and why' into 'how it works, what done looks</span><br role="presentation"><span role="presentation" dir="ltr">like, and what trade-offs are acceptable.' They are the person engineering turns to daily for product</span><br role="presentation"><span role="presentation" dir="ltr">decisions that require genuine understanding of the customer, the domain, and how the product is used.</span><br role="presentation"><span role="presentation" dir="ltr">This role exists because product strategy and engineering execution operate at different altitudes. The</span><br role="presentation"><span role="presentation" dir="ltr">Head of Product sets direction at the 6–24 month horizon. Engineering works sprint-by-sprint. The</span><br role="presentation"><span role="presentation" dir="ltr">Product Owner bridges that gap — taking strategic intent and producing detailed, implementable</span><br role="presentation"><span role="presentation" dir="ltr">requirements, then making the continuous stream of scoping, quality, and priority decisions that arise</span><br role="presentation"><span role="presentation" dir="ltr">during development.</span></div> <div><br role="presentation"><span role="presentation" dir="ltr">Without this role, every domain-level product decision routes to the Head of Product, creating a</span><br role="presentation"><span role="presentation" dir="ltr">bottleneck. With this role, the Head of Product sets direction and the Product Owner ensures that</span><br role="presentation"><span role="presentation" dir="ltr">direction is faithfully and effectively translated into shipped product</span></div> <div>&nbsp;</div> <div><span role="presentation" dir="ltr"><strong>Location &amp; Working Context</strong></span></div> <div><span role="presentation" dir="ltr"><br>This role is based in Washington DC. SynMax has engineering and intelligence teams across multiple<br>time zones, including the UK, and the Product Owner will need to work effectively across those time<br>zones — including maintaining regular overlap with a UK-based engineering team. Candidates should<br>be comfortable with structured async communication and occasional early starts or late calls to align<br>with European sprint rhythms.</span></div> <div><span role="presentation" dir="ltr"><br>Given the nature of SynMax's customer base, this role operates in and around the US defence and<br>intelligence community. Travel to customer sites, government offices, and SynMax locations (including<br>Houston) should be expected on a periodic basis.</span></div> <div><span role="presentation" dir="ltr"><br><strong>Core Responsibilities</strong></span></div> <div><span role="presentation" dir="ltr"><br><span style="text-decoration: underline;">1. Requirements Definition &amp; Feature Specification</span></span></div> <div><span role="presentation" dir="ltr"><br>Translate strategic roadmap items into detailed, implementable product requirements that engineering<br>can build from.</span></div> <div><span role="presentation" dir="ltr"><br>– Take each prioritised roadmap item and produce detailed requirements: user stories, acceptance<br>criteria, functional specifications, edge case definitions, and supporting materials where needed<br>Product Owner – Theia | Washington DC | Individual Contributor<br>– For each feature, define: what the user is trying to do, what the system should do in response,<br>what 'done' looks like from the customer's perspective, what is explicitly out of scope, and what<br>quality bar must be met<br>– Work with design to ensure requirements reflect intended UX and don't diverge during<br>implementation<br>– Work with the tech lead to confirm feasibility within the sprint or delivery window; propose scope<br>adjustments where needed with a clear articulation of the trade-off<br>– Ensure every feature spec connects back to the roadmap item and its strategic rationale —<br>engineering should understand not just what they're building but why<br>– Maintain a requirements backlog that is always 2–3 sprints ahead of engineering</span></div> <div><span role="presentation" dir="ltr"><br><span style="text-decoration: underline;">2. Sprint-Level Product Decisions</span></span></div> <div><span role="presentation" dir="ltr"><br>Make the continuous stream of product decisions that arise during development — too detailed for the<br>Head of Product, too consequential for engineering to answer alone.</span></div> <div><span role="presentation" dir="ltr"><br>– Be available to engineering daily for product questions: edge cases, filter behaviour, scope<br>boundaries, and mid-sprint trade-offs<br>– Make scoping decisions within agreed boundaries — adjusting how a feature is built within a<br>sprint, without adding, removing, or reprioritising roadmap items (which sits with the Head of<br>Product)<br>– Define the acceptance boundary for each deliverable: own the product side of quality — does this<br>solve the customer's problem as intended?<br>– Make go/no-go decisions on sprint deliverables; reject work that does not meet the product<br>acceptance bar, regardless of technical completion<br>– Document key decisions and their rationale so context is captured and traceable</span></div> <div><span role="presentation" dir="ltr"><br><span style="text-decoration: underline;">3. Backlog Ownership &amp; Sprint Coordination</span></span></div> <div><span role="presentation" dir="ltr"><br>Own the content and readiness of the development backlog, and represent product in delivery<br>processes.</span></div> <div><span role="presentation" dir="ltr"><br>– Own what is in the backlog, how items are described, their priority, and whether they are ready for<br>engineering<br>– Prepare for sprint planning: ensure the top of the backlog is refined, requirements are complete,<br>dependencies are identified, and items are appropriately sized<br>– Participate in sprint planning as the product voice — explain the 'what and why' for each item,<br>answer engineering questions, negotiate scope based on capacity<br>– Attend standups to stay current on progress, unblock product questions in real time, and identify<br>delivery risk early<br>– Run or participate in sprint reviews: assess delivered work against acceptance criteria, provide<br>product feedback, and communicate outcomes to the Head of Product<br>– Participate in retrospectives with a focus on improving requirement quality and reducing rework</span></div> <div><span role="presentation" dir="ltr"><br><span style="text-decoration: underline;">4. Domain Expertise &amp; Customer Understanding</span></span></div> <div><span role="presentation" dir="ltr"><br>Maintain deep enough understanding of the product, its users, and the domain to make high-quality<br>product decisions at feature and sprint level.</span></div> <div><span role="presentation" dir="ltr"><br>– Develop and maintain working knowledge of how customers use the product: their workflows, pain<br>points, workarounds, and the gap between what was designed and what actually happens in<br>practice<br>– Attend customer calls regularly (minimum 2–3 per month) — not for research purposes, but to<br>understand how the product is used and whether it is working as intended<br>– Build sufficient familiarity with US government and defence customer workflows to make product<br>decisions that reflect how these users actually operate — including the constraints of classified<br>environments, programme timelines, and operational tempo<br>– Stay current on known product issues and deficiencies, and factor these into feature scoping<br>decisions<br>– Understand the intelligence outputs the product delivers well enough to make sound decisions<br>about how they are surfaced, displayed, and interacted with<br>– Maintain working awareness of the competitive landscape and apply it to feature scoping</span></div> <div><span role="presentation" dir="ltr"><br><span style="text-decoration: underline;">5. Stakeholder Communication (Delivery-Focused)</span></span></div> <div><span role="presentation" dir="ltr"><br>Keep relevant stakeholders informed about what is being delivered, what has changed, and what the<br>implications are.</span></div> <div><span role="presentation" dir="ltr"><br>– Communicate sprint outcomes to the Head of Product after each sprint: delivered vs not delivered,<br>scope changes, and any roadmap implications<br>– Provide delivery status updates for roadmap tracking<br>– Coordinate with Customer Success on upcoming releases: what is changing, what customers<br>need to know, what support implications to expect<br>– Flag when implementation diverges from design intent and resolve discrepancies with design<br>– Escalate to the Head of Product when: a roadmap item cannot be delivered as scoped and the<br>trade-off exceeds the PO's authority; engineering raises concerns with strategic implications; or<br>customer feedback directly contradicts the current roadmap direction</span></div> <div><span role="presentation" dir="ltr"><br><br><br></span></div> <div><span role="presentation" dir="ltr"><span style="text-decoration: underline;"><strong>&nbsp;Experience &amp; Capabilities</strong></span><br></span></div> Required – Demonstrated experience working closely with engineering teams in a sprint-based delivery environment – Strong track record of writing detailed, unambiguous product requirements that engineering can act on – Comfortable making trade-off decisions under constraint and articulating the impact clearly – Direct, precise communication with technical teams — able to give fast, confident answers to product questions – Experience with customer-facing software products where user understanding directly shaped product decisions – Eligibility to work with US government customers and, where required, to obtain relevant security clearances — US citizenship or appropriate clearance eligibility is expected Strongly Preferred – Familiarity with the US defence, intelligence, or federal government market — understanding how these customers procure, operate, and adopt software – Experience working with government programme offices, defence end-users, or similar stakeholders – Domain familiarity with maritime, geospatial intelligence, or related domains – Experience operating across distributed or cross-timezone team Key Capabilities – Strong product judgement at the feature level — knowing when a 90% solution is good enough and when the missing 10% is critical – Ability to translate strategy into execution detail without losing intent – High attention to detail without losing broader context – Comfort with ambiguity — able to make decisions with incomplete information and revisit them when new information arrives