Citi

A global bank runs thousands of workflows where the expensive step is someone hunting for information across systems that were never designed to talk. Risk and compliance feel it hardest. The sharpest version lives in the front office.

Investment analysts in asset management and global markets work across pricing systems, client records, research archives, and counterparty documents. Most of it predates any intent to integrate it. The analysis is the skilled part. The assembly is not, and the assembly is where the hours go.

Fragmentation is usually cited as the reason these workflows cannot be automated. It is the reason they are worth automating. The steps repeat enough to encode. They matter enough that nobody wants them running unsupervised. So the analyst stays in the loop, but reviewing decisions instead of assembling sources.

That only works if a platform absorbs the fragmentation first. Olympus was that platform.

Olympus is an end-to-end business transformation platform. Business users compose their own workflows as DAGs, orchestrated through Apache Airflow. Asset management, trade solutions, and global markets all ran on it, each bringing workflow shapes the platform had to generalize across rather than special-case.

Citi runs on two fronts. The front office does the financial work. The technology organization builds what the front office runs on. I worked between them, turning how analysts described a workflow into something engineering could scope, and telling analysts what was realistic to get back. Platform product analyst is the closest title.

Users describe a problem by the process they are stuck in. The step they complain about is rarely the step that costs the most. So I stayed close to them: discovery calls, feedback calls, and their BRDs, mapped line by line against what Olympus already did and what it would need to do. Where a requirement was uncertain, I prototyped it. I wrote retrieval pipelines in Python over the bank's proprietary data and ran them as Airflow tasks inside the same DAGs the business users worked in, then took the results back to the team that raised the requirement. That loop made the product calls defensible. I could confirm an idea worked on real data before engineering committed to it, separate a requirement that was hard from one that was only unfamiliar, and set timelines engineering could hold to.

Two AI features shipped on the platform.

The first was an LLM assistant. Onboarding a new workflow meant engineers interviewing business users repeatedly to learn what the workflow did, and those users held client information they were not free to share. I shipped a RAG and memory system grounded in platform documentation and prior use case deliverables. The assistant carried context forward instead of resetting each engagement. Questions that used to need an engineer now had an answer in the product.

The second came out of a pattern in customer feedback. Users wanted Olympus to handle the unstructured half of their work: contracts, statements, scanned confirmations. I defined the PRD for a document intelligence capability. Vision language models read the scanned and free-text documents, extracted the fields that mattered, and wrote them into the same tables the structured data landed in, so a workflow could reason across both without an analyst bridging formats by hand.

Around both, the rhythm stayed the same. Read the BRD. Map it to the platform. Set a timeline against engineering capacity. Keep a roadmap for what did not exist yet.

Owning deliverables on a platform that revenue channels ran on is what turned me toward product management. Ideation, prototyping, mapping business requirements: that was the work I wanted more of. Being technically adept made it better, because I could test whether a new technology was actually useful rather than take someone's word for it. That is the question the industry is asking right now.