# Technical Product Owner

For retailers with thousands of shops, commerce platforms have historically fallen into two categories, each with significant drawbacks. Web-native platforms move fast but were never built for a shop floor. Legacy store systems were built for the shop floor but take a year to change anything. OneView Commerce is the third option: a headless commerce platform for physical retail that lets the world's largest retailers innovate just as quickly as the smaller ones. We ship store experiences that deploy fast out of the box, and we give retailers the freedom to build their own on top of a headless transaction engine engineered for the physical store rather than the browser.

Our customers are global retailers who build on OneView because it lets them keep moving: new journeys, new channels, and new store formats ship continuously rather than waiting on the next multi-year program.

Founded in 2010 to close the gap between fast-moving e-commerce and slow-moving in-store systems, OneView's founding principle is a single view of customers, orders, and inventory throughout the shopping journey. That remains our mission as we enable retailers to deliver exceptional store experiences that build loyalty.

We are a remote-first team with Viewers working across the globe, and we operate as a trusted provider of digital commerce systems for leading retailers.

OneView is looking for a Technical Product Owner with a DevOps engineering background to own the flow of work into our DevSecOps team. The team builds and secures the platform every other team here depends on, which makes it the most contended team in the company. Work reaches the team from two sources: requests from software engineering, QA, agile delivery, product support, customer implementation, security, and leadership; and the Platform Engineering roadmap, which includes building our internal developer platform (IDP). You decide what the team takes on, in what order, and what it declines, and you will say «no» and «not yet» more often than «yes».

You report to the Sr. Director of Platform Engineering, who leads the DevSecOps pillar and sets product vision, strategy, and the roadmap, with input from the VP of Engineering, the Chief Architect, and the team's engineers. You work closely with the Sr. Director while it is drafted. The Sr. Director owns how the work gets done (technical approach, standards, assignment, and quality), and you own priority. Expect the Sr. Director and others more senior than you to challenge your ranking. You are expected to defend it with evidence and make adjustments when a stronger case is made.

The role needs hands-on DevOps knowledge. You cannot specify a pipeline change, a cluster upgrade, a secrets rotation, or a new set of guardrails without understanding what each one puts at risk.

We use AI throughout our work and want you to find uses for it we have not thought of. We also expect you to do this job well if it were switched off tomorrow, because the priority calls and the stakeholder relationships depend on you.

This is an individual contributor role with no direct reports.

• Own the intake path into the DevSecOps team, and qualify every request at the point of arrival: the desired outcome, affected parties, impact, dependencies, and any hard due dates. Where a request specifies its own solution, establish the problem it is meant to solve before the team commits to that solution.
• Rank inbound requests and Platform Engineering roadmap items on one backlog by urgency and value, publish the ranking, and keep it refined far enough ahead that an engineer can start without waiting on you for clarification. Make the trade-offs explicit, and answer to the teams whose work a ranking displaces. A stakeholder should be able to see what their request is weighed against and where it sits without escalating.
• Bring the team's improvement ideas to the Sr. Director as roadmap proposals, with the problem, scope, and effort worked out with the team's engineers and architects.
• Turn the Platform Engineering roadmap, including the IDP build-out, into backlog items the team can deliver, and keep their status current and published for the teams that depend on them. Report IDP adoption and user feedback to the Sr. Director.
• Limit work in progress to what the team can finish, resist mid-sprint insertion, and make the cost of an interruption visible when one is unavoidable.
• Translate requesters' needs into concrete platform, automation, tooling, and security requirements, written as stories with testable acceptance criteria that cover the impact of a failed change, rollback, access control, auditability, and cost alongside the functional outcome.
• Own the intake of unplanned and obligation-driven demand, including post-incident remediation and work generated by compliance, audit, and customer security commitments, and sequence it against everything else.
• Coordinate dependencies across internal teams and third-party vendors, and surface them early enough that they do not stall the queue.
• Report on flow: request-to-delivery lead time, work in progress, throughput, queue depth, the proportion of unplanned work, and the split between inbound requests and platform initiatives. Use the numbers to argue for more capacity or more automation.

• 2+ years as a Product Owner, Technical Product Owner, or in an equivalent backlog-owning role.
• 3+ years hands-on in DevOps, security operations, platform engineering, or site reliability engineering, with working experience in most of the following areas, using these or comparable tools:
• Version control: Git
• CI/CD: CircleCI, GitLab CI/CD, GitHub Actions
• Cloud platforms: AWS, Google Cloud
• Containers and orchestration: Docker, Kubernetes
• Infrastructure as code: Terraform, CloudFormation, Ansible
• Scripting: Python, Bash, JavaScript
• Monitoring and observability: Datadog, AppDynamics, CloudWatch, Splunk
• Operating systems: Linux, UNIX
• Working knowledge of security practice for cloud infrastructure and delivery pipelines, including access control, secrets handling, and pipeline guardrails.
• Able to run an intake conversation with an engineer and come out of it with a complete requirement. Knows enough to spot what the engineer left out and what the change touches downstream.
• Writes acceptance criteria that account for adjacent systems, integrations, and existing platform behavior as well as the story itself.
• Translates business requirements into language a technical audience can act on, and technical constraints into terms a business stakeholder can decide against.
• Has ranked infrastructure or platform work against visible feature or customer work, and defended the ranking to stakeholders.
• Negotiation and conflict resolution: Has declined a request from a senior stakeholder, explained the reasoning, and kept the relationship intact.
• Has coordinated dependencies across multiple internal teams and external parties, and run a dependency tracker that the other teams on the program used.
• Point of sale experience.
• Has worked in a shared services or internal platform team serving internal customers with competing priorities, and can describe how the queue was managed.
• Has been on call, and knows from experience what unplanned work does to a team's ability to deliver.
• DevSecOps principles, such as shifting security left and zero trust.
• Platform engineering and GitOps: internal developer and monitoring platforms, self-service infrastructure, declarative deployment.
• Reliability and resilience practice such as chaos engineering, penetration testing requirements, and disaster-recovery drills. FinOps awareness for cloud cost accountability.
• AI and AIOps fluency, across both the platform (AI-assisted automation, predictive monitoring, self-healing pipelines) and the backlog (story generation, acceptance criteria drafting, requirements traceability).
• Has implemented an operational improvement in a past role that measurably improved the speed or quality of a delivery team's work, and can describe the change and its measured effect.
• Certifications such as AWS, Google, or Microsoft DevOps credentials.

Why OneView

Alongside the global retailers we already serve, we have recently been selected by one of the largest store networks in the world to replace their legacy store system, and are pursuing more retailers that have decided to replace theirs. The platform this role sets priorities for runs all of that work.

Our teams operate independently and set their own direction. Nobody needs a committee's permission to fix something that is broken. We expect people to identify what should be done differently and then make the change.

If you have worked in a larger organization where improvements you could see never got approved, this role is different: you work with the DevSecOps team's engineers and architects to propose their improvements, and you decide where approved work ranks.

OneView has been named one of Built In's Best Places to Work for three years in a row. Our leadership team brings decades of experience across software development, delivery, sales, and marketing.

OneView Commerce is an equal opportunity employer. All qualified applicants will be considered for employment without regard to race, colour, religion, sex, sexual orientation, gender identity, national origin, veteran, or disability status.

We do not accept CVs from agencies, headhunters, or other suppliers who have not signed a formal agreement with us.

Applicants must have current, ongoing right to work in the UK (if applicable). OVC is not a licensed visa sponsor and is unable to sponsor a Skilled Worker visa or any other employment visa for this or any role, now or in the future. Evidence of right to work will be required prior to any offer of employment.