As Head of Product & Design, I led the work across product strategy, discovery, roadmap definition, architecture and detailed product design. In parallel, I directed a broader hypothesis-testing programme exploring future capabilities in early warning, commercial foresight and evidence-backed decision support.
Scope
Product Strategy · Discovery · Competitive Research · User Interviews · Stakeholder Research · Product Roadmapping · Product Architecture · Information Architecture · UX/UI Design · Design Systems · Validation Direction · Product Leadership
Product
Regional cost intelligence platform · Zero-to-one · Ongoing
An existing strategic ambition, but no defined product path. IOX did not begin as a blank-page idea. Omnium already wanted to become a cost intelligence platform and had significant assets to build from: decades of quantity-surveying expertise, historical project and rates data, existing internal tools and workflows, established client relationships and deep regional market knowledge. What was not yet defined was how those assets should translate into a coherent digital product. The challenge was to determine which user problems the platform should solve first, how the existing data should be structured and applied, what would make the proposition regionally distinctive, how individual capabilities should connect, what should be built now, later or not at all, and how the platform could grow beyond cost information over time. My role was to bring structure to that ambition and translate it into a product direction that could be researched, prioritised, designed and delivered.
Understanding quantity-surveying expertise, client needs and market reality. I led the discovery and research work required to turn Omnium’s strategic ambition into a clearer product direction. This included competitive benchmarking, stakeholder conversations and interviews with quantity surveyors, end users, subject-matter experts and leadership. The work explored how cost knowledge was currently captured, where users struggled to access trusted information, how existing workflows operated, which decisions depended on reliable rates and benchmarks, and where a regional platform could provide value that generic tools could not. The purpose was not to invent the ambition. It was to define what that ambition should mean as a product — who it should serve, where it could differentiate, what should be built first and how the wider system should scale.
The research pointed to a stronger and more specific opportunity: a trusted source of construction cost intelligence for the Middle East. Omnium’s advantage was not simply that it had data. It had specialist knowledge, regional context, client relationships and quantity-surveying expertise that could give the product credibility. I synthesised the research into a product direction focused on rates, benchmarks, market intelligence, parametric cost modelling, BOQ workflows and tender intelligence — capabilities that could create value immediately while forming the foundations for a broader construction intelligence operating system over time.
Omnium ambition → Research → Regional opportunity → Roadmap → Ecosystem
I conducted competitive research to understand how existing construction technology and cost intelligence products approached the problem, where the market was already saturated and where a regional proposition could differentiate. Rather than limiting the analysis to direct competitors, I looked at capability patterns across large platforms, cost-data products, specialist point solutions, consultancy-led digital offerings and emerging AI tools. This helped separate commodity functionality from areas where Omnium’s knowledge and data could create a stronger position: trusted regional rates, benchmarks, market intelligence, parametric modelling, quantity-surveying workflows and evidence-backed decision support that could sit across existing project environments rather than replacing them.
Omnium already had the ambition to become a cost intelligence platform. I led the product work required to turn that ambition into a clearer regional proposition, structured roadmap and scalable digital ecosystem. The roadmap connected near-term value with longer-term platform potential: rates and benchmarks, market intelligence, parametric cost modelling, BOQ intelligence, tender workflows and future foresight capabilities. In parallel, I defined a hypothesis framework for exploring where IOX could expand beyond cost intelligence into delivery risk, evidence, commercial foresight and decision support. This meant the roadmap was not just a feature list. Each capability was connected to the user problem it addressed, the evidence supporting it, its role in the ecosystem and what still needed to be validated.
Directing the validation of the product thesis. Before the hypotheses became roadmap commitments, they needed to be tested. I defined the hypothesis-led validation framework and directed the testing programme from a product and strategic perspective: defining the original product hypotheses, establishing the questions validation needed to answer, organising hypotheses into decision-oriented clusters, directing the technical testing brief, reviewing findings against the product strategy and translating results into roadmap decisions. The technical testing itself was designed and executed by IOX’s data scientist and engineer, who analysed the project data and produced the detailed findings. Together, the hypotheses were retrospectively tested across three live construction projects to understand whether IOX could have surfaced real schedule risk and commercial exposure before those issues appeared in formal project reporting.
The tests did not validate everything, and that was the point. The purpose was to identify what was supported, what showed promise, what was not yet supported, what was constrained by the available data and what should happen next. The strongest result was IOX’s ability to identify activities at risk of slippage before the projects’ own documents recorded the issue. Across the three projects, 70.6% of recoverable at-risk activities were flagged at least 28 days before the earliest project document recorded the issue, with typical median lead times ranging from 31.5 to 92 days. Commercial foresight also showed a strong timing signal: 75.9% of commercial variations in the recoverable sample had been preceded by a persistent IOX exposure flag. However, the evidence was treated carefully. Timing was supported; automatic linkage to specific variation wording was not yet supported. Project-level causal narratives performed inconsistently, and citation traceability could return users to source documents without always providing sufficiently direct semantic support for a generated explanation.
The findings changed what we should build next. They became product inputs rather than a conclusion. Three immediate directions emerged. First, a live early-warning feed: a continuously updated view of activities at risk, refreshed when new schedule information is ingested, showing what is at risk, why it has been flagged, how long the signal has persisted, how much lead time remains and what evidence supports it. Second, a commercial-exposure watchlist: a ranked view for quantity surveyors and contracts teams, surfacing persistent exposure hotspots before they crystallise into formal variations or claims. Third, recommended actions: moving from what is happening to why it matters and ultimately what should I do next, while preserving human judgement.
Early warning · Commercial exposure · Recommended action
The tests revealed product requirements beyond the interface. Two recurring data-practice issues affected the quality of the results. Schedule continuity was not always preserved consistently across schedule exports and re-baselines, weakening the system’s ability to understand whether the same activity was persisting or changing over time. Reporting vocabulary also created friction: project reports often described issues in site language while schedules used formal activity names. Both could describe the same real-world issue, but the absence of a shared reference weakened automated linkage. These findings suggested additional product and implementation requirements: schedule-continuity checks at upload, clear confidence states, visible evidence quality, traceable source links, reporting guidance and interfaces that acknowledge uncertainty rather than hiding it. The question evolved from does the model work to what product, workflow and data conditions are required for this capability to create reliable value?
From individual capabilities to a construction intelligence operating system. The discovery, market research and validation work contributed to a broader product strategy. Rather than building another isolated construction tool, IOX is being structured as a connected ecosystem spanning intelligence across the lifecycle of the built environment: CapEx & Delivery Intelligence for development, cost, procurement, tendering, commercial management and project delivery; OpEx Intelligence for operational expenditure and asset performance; TotEx Financial Intelligence connecting capital and operational expenditure; ESG & Carbon Intelligence connecting sustainability and carbon intelligence to the wider decision environment; and Validation & Foresight supporting earlier signals, explanation, evidence and forward-looking intelligence across the ecosystem.
Creating one mental model across multiple products. As the ecosystem grew, the question became how the entire operating system should work. I mapped the wider product architecture across global navigation, projects and portfolios, product switching, AI-powered search, notifications, user context, workspace administration, organisation management, users and teams, roles and permissions, security and product-specific workflows. This required defining the relationship between Organisation → Portfolio → Project → Product → Workflow, and determining what should be global, contextual, project-specific, product-specific, administrative and personal. The architecture needed to support the products being built today without limiting the platform IOX could become tomorrow.
With the wider architecture established, I have led the design of individual products and workflows within it. The work spans market and rates intelligence, parametric cost modelling, BOQ intelligence, tender intelligence and the new foresight experiences informed by validation. Each workflow required translating specialist construction knowledge into usable digital experiences without removing context, evidence or human judgement. The objective was not simply to reproduce existing processes digitally. It was to understand what information users need, when they need it, which decisions require human judgement, where automation can remove repetitive work and where evidence and auditability must remain visible.
13 - Foundations and reflection
13 - Platform foundations and design system
Enterprise products need more than core workflows. As IOX developed into a multi-product platform, I led the design of the operational infrastructure required for organisations to use it at scale, including workspace administration, organisation profiles, business units, offices, teams, user management, product access, roles and permissions, security, notifications and personal settings.
With multiple products and workflows being designed in parallel, I also created and continue to evolve the IOX design system. Patterns became reusable after being tested in real product contexts rather than designed in isolation, balancing consistency across the ecosystem with the flexibility required by specialist workflows.
14 - Working across disciplines
My role connects business strategy, construction domain expertise, data and AI, engineering feasibility and hands-on design. I move continuously between the wider product direction and the details required to bring it to life. Strategic enough to define the product. Hands-on enough to design it.
15 - The next validation gate
The retrospective hypothesis testing could answer whether IOX would have surfaced risk earlier. It could not answer whether those signals would change what a project team actually does. The proposed next stage is a shadow-mode pilot, running alongside a live project for six to twelve weeks to evaluate relevance, confidence, earlier intervention, exposure resolution, stakeholder comprehension and reduced reporting effort.
16 - Outcome and reflection
IOX remains an active product in development. The work to date has established a structured discovery and prioritisation process, strategic problem spaces, competitive understanding, a hypothesis-driven approach to investment, retrospective evidence from live projects, a multi-product operating-system architecture, a structured roadmap, scalable information architecture, specialist workflows, a shared design system, an organisation and access model and a defined next validation gate.
The hardest part wasn’t designing the interface. It was creating clarity. Before an interface can feel simple, someone has to make sense of the complexity underneath it. For me, that is where product strategy and design become the same discipline.
Some product details, data and interfaces have been simplified or omitted to protect confidential commercial and technical information. A more detailed walkthrough is available during interviews.
