Data engineering
Architecture, pipelines, hiring.
Vertical · Data & product leadership support
20 years at the crossing of data, product and management. For organisations that need to frame their data or their product before committing, whether the subject is geospatial or not.
Strand 1
Founding data hire: stack architecture, technical decisions, a direct line to the board. But also, and above all, leading a multidisciplinary team : beyond data engineers and analysts, I recruited, managed and grew UX/UI designers and back-end and front-end developers, from the first hire to a team of 7.
Architecture, pipelines, hiring.
Managing designers, product consistency.
Technical decisions, architecture review.
Prioritisation, quality, delivery.
Strand 2
Is your SaaS platform, your data product or your WebGIS short of a product vision? Framing the screens with business users, writing epics and user stories, arbitrating the backlog: I carry the product vision of a tool as much as the data that feeds it, with the technical and business reading that 20 years at this crossing gives you.
Over the past five years, most of my work has not been producing analysis but deciding what to build, in what order, and making it hold over time. I am the link between users, technical teams and management: I frame the need, I write the specifications, I arbitrate the backlog, and I measure what was actually delivered.
User interviews, a map of how the tool is really used, sorting what is asked for from what is needed.
Cut into deliverable increments, explicit prioritisation, decisions owned and documented rather than endured.
User stories, acceptance criteria, testing, and turning the business need into something that can be built.
Instrumentation planned from the design stage, adoption indicators, an explicit decision to carry on or to stop.
Interface contracts, quality, documentation, identified users: a dataset has customers, just as a feature does.
Ways of working together
Product owner for the product: framing with business users, backlog prioritisation, specifications and acceptance criteria, user testing, then measuring real usage once in production. This is where I spent most of my time in this role.
Same role, on a product still being built and not public at this stage. I am glad to talk it through in person, within what I am free to say.
On both projects I held the role without the title: framing the interfaces, arbitrating features, back and forth with the staff who use them, through to going live.
A Modern Data Stack architecture: ingestion, warehouse, versioned transformation, exposure.
A product analytics pipeline built on an engagement · architecture illustration
This diagram illustrates a standard architecture. It does not reproduce any particular client’s set-up.
Engagement formats
A testable PRD, scope arbitrated in batches, a revenue model and the free / paid boundary, a test protocol with decision thresholds, a prioritised backlog.
The method was applied in 2026 to the full framing of a SaaS platform, from PRD to a prototype tested on real data.
Ordered directly, with no prior advertising or tender.
A picture of the data, the tools and the real usage, a reasoned target architecture, a hiring or outsourcing plan, a three-page note that works in a committee.
See also
30 minutes to understand your context and see whether one-off or recurring support is the right format.
Data does not remove the risk. It lets you choose which one you take.