Product Owner – Theia

About the Role

Theia is SynMax's maritime intelligence platform — used by naval forces, defence agencies, andcommercial operators to monitor and understand vessel activity at global scale. It is the company'sprimary 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'sdaily delivery. Their job is to translate 'what we're building and why' into 'how it works, what done lookslike, and what trade-offs are acceptable.' They are the person engineering turns to daily for productdecisions 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. TheHead of Product sets direction at the 6–24 month horizon. Engineering works sprint-by-sprint. TheProduct Owner bridges that gap — taking strategic intent and producing detailed, implementablerequirements, then making the continuous stream of scoping, quality, and priority decisions that ariseduring development.

Without this role, every domain-level product decision routes to the Head of Product, creating abottleneck. With this role, the Head of Product sets direction and the Product Owner ensures thatdirection 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

1. Requirements Definition & Feature Specification

Translate strategic roadmap items into detailed, implementable product requirements that engineering
can build from.

– Take each prioritised roadmap item and produce detailed requirements: user stories, acceptance
criteria, functional specifications, edge case definitions, and supporting materials where needed
Product Owner – Theia | Washington DC | Individual Contributor
– 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