Product Owner - Theia

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