Product Data Manager

Responsibilities

Looking for one senior person who operates simultaneously as a Product Owner for a data-intensive application, a Data Insights practitioner who can build and communicate what the data means, and a Testing leader who understands how every layer of the system fits together.

These three dimensions are not separate jobs that happen to sit on the same org chart line.

They are three lenses the same person applies to the same engagement, often in the same week.

The person is embedded directly with a government client stakeholder and is the primary product and quality voice on the delivery.

Product Owner:

• This person is the one writing epics and user stories from a deep understanding of a data-intensive pipeline - not from templates.
• Understand how data flows through the system, what business events trigger what processing steps, and how operations and engineering teams actually use the product.
• Run a backlog grooming session in the morning, walk a government client through a new screen in the afternoon, and write the acceptance criteria that locks the story that evening.
• Comfortable facilitating requirements sessions with program stakeholders who are not technical, translating what they hear into stories that engineering can build against and that testing can verify.
• A client says "I need to know why that account is unclaimed" and this person turns it into a defined data requirement, a dashboard feature, and a test scenario - without involving three other people to make that translation.

Data Insights and Data Science practitioner:

• Build when the situation requires it - writing SQL, using LLMs and AI assistance, building a dashboard view, or producing an analysis artifact that answers a specific program question.
• But their primary value is not raw technical output.
• Ability to look at a pipeline that moves millions of records, identify what the data is actually telling the program, and communicate that story in a way a government client can act on.
• They know what a meaningful metric looks like versus a vanity number.
• They can identify anomalies in processing output, frame them as program risk, and recommend a course of action.
• They have done this on data-intensive systems before, not on reporting layers built over clean warehouse data.
• The data in this context is messy, compliance-bound, and operationally consequential - they are comfortable in that environment.

Testing:

• Understands the full quality picture from the inside out.
• They can read a batch execution log, write a database-level assertion, evaluate whether a security test is producing real evidence or just passing by coincidence, and hold a release gate when engineering wants to ship and the evidence is not there.
• They have been through at least one delivery cycle on a regulated system where a defect was not just a bug - it was a compliance finding - and they know what it means to produce a legally-retained release evidence package.
• They do not manage testers from a distance.
• They lead from the front, understand the technical controls that underpin each test stage, and are the single authority on whether the system is ready for production sign-off.