What you’ll do
We build platforms for government and enterprise operations: licensing and permits, case management, back-office automation, data platforms and integrations with systems older than the teams maintaining them. The hard part is rarely the technology. It is that the business logic is genuinely complex — layers of rules, exceptions, approval chains and edge cases that live half in regulation, half in a spreadsheet, and half in one person's head. Your job is to understand it completely, write it down unambiguously, and see it built.
Understanding the domain:
- Learn each client's business properly — the rules, the workflow, the roles and who is allowed to do what, the calculations, and the exceptions that everyone treats as normal.
- Map processes as they actually run, not as the procedure manual claims, and find the gap between the two.
- Decompose complexity into models an engineer can implement: entities and their relationships, states and transitions, decision tables, permission matrices.
- Ask the questions that surface what nobody mentioned — what happens when the applicant dies mid-process, when two departments disagree, when the payment arrives before the approval.
- Reconcile contradictions between what a regulation requires, what a legacy system enforces, and what staff have quietly been doing for a decade.
Owning the product:
- Own the product backlog: what gets built, in what order, and on what reasoning.
- Write user stories and acceptance criteria precise enough that an engineer can build against them and a tester can verify them without a follow-up meeting.
- Maintain a roadmap that survives contact with reality — sequence by value and risk, and say no with reasons.
- Accept or reject delivered work against the criteria you wrote.
Working with clients:
- Run discovery with government and enterprise stakeholders: workshops, interviews, process mapping, and reading the documents nobody expects you to read.
- Translate in both directions — technical constraints into terms a director can decide on, institutional rules into terms engineers can act on.
- Manage expectations on scope and timeline, and hold the line when "one small change" is not one small change.
- Prepare demos, run user acceptance testing, and produce the release notes and training material that get the system actually used.
Working with the team:
- Run refinement, sprint planning, reviews and retrospectives alongside engineering and design.
- Be available daily for the questions that unblock people — an absent Product Owner is a stalled team.
- Work with design on flows and prototypes before they harden into tickets.
- Keep the definition of done honest, including accessibility, security and compliance obligations.
Measuring what happened:
- Define what success means for each feature and make sure it is instrumented: adoption, task completion, error rates, support load.
- Use that evidence to decide what to build next, and what to remove.
- Report progress and risk to clients and internally, without spin.
We look for
Required:
- Three years or more as a Product Owner, Product Manager or Business Analyst on software products.
- Demonstrable ability to master complex business logic. Given a long regulation, a spreadsheet nobody admits to maintaining and three contradictory interviews, you can produce a model of the process that everyone involved recognises as theirs.
- A structured way of expressing rules: decision tables, state diagrams, permission matrices, worked examples — whatever makes ambiguity impossible.
- Ownership of a backlog end to end: stories, acceptance criteria, prioritisation, and the accepting.
- Agile and Scrum in practice rather than in certification — refinement, planning, review, and what to do when a sprint goes wrong in week one.
- Enough technical literacy for a credible conversation about APIs, data models, integrations and constraints. You do not need to write code; you do need to understand what you are asking for.
- Writing precise enough that requirements cannot be misread by someone looking for a shortcut.
- Stakeholder management with senior, non-technical people.
- Comfort with ambiguity — most engagements begin with a vague problem and a firm deadline.
- Fluent English and Arabic; client stakeholders work in both.
Nice to have:
- Domains where the rules are the product: public administration, banking, insurance, healthcare, logistics, tax or compliance.
- Government or public-sector clients — tenders, procurement, formal acceptance processes.
- Replacing or integrating with legacy systems, and reverse-engineering the logic buried in them.
- Data modelling, SQL, or the ability to read a schema and ask better questions because of it.
- Accessibility (WCAG) and data protection (GDPR) treated as product requirements rather than legal footnotes.
- Jira, Azure DevOps or Linear as a tool you have genuinely run a backlog in.
- Working with designers in Figma.
- Defining metrics and instrumentation, and reading what comes back.
- Products involving AI or machine learning, and the discipline of scoping features whose output is not deterministic.
- A technical background — an engineering degree, or a previous life as a developer or tester.
- CSPO, PSPO or equivalent certification.