Four years between traders, quants and engineers.

Electronic trading product management didn't mean owning a single application. The product was the trading capability itself: how prices reached clients, how orders came in, where flow could be executed, what could be automated, and what infrastructure had to exist underneath it.

The roadmap around me mixed client-facing product expansion with trading protocols, venue connectivity, algorithmic capabilities, market-data performance and core platform work. Those weren't independent tracks. A new execution workflow could depend on a venue protocol, which depended on connectivity and market data — while the desk still had to trade through the existing workflow the entire time.

Traders thought in liquidity, risk and PnL. Quants thought in models and signals. Engineers thought in systems, dependencies and failure modes. Sales saw the client. External venues had their own protocols, release schedules and constraints. My job lived between all of them.

I worked primarily across Rates and Mortgages, owning parts of the electronic trading product: execution workflows, trading protocols, platform connectivity, automation, and the roadmap connecting them.

I also stayed unusually close to the implementation. If the fastest way to understand a problem was to query the data, build an internal tool, or instrument the workflow, I did it myself. Engineering owned the core production architecture; I often built the analytical layer closer to the desk — pipelines, real-time tools, and the analysis around what we shipped.

The roadmap was much broader than any four projects. These are the ones that best show the different ways I worked: sometimes the answer was analysis, sometimes a tool, sometimes a product decision, and sometimes a new piece of the trading system.

Predicting client flow before it arrived

Some large hedge-fund flows in Mortgages were both high-volume and difficult to anticipate. When they arrived, the desk had to drop what it was doing and respond, so even modest advance warning changed how traders prepared.

I combined historical client trading patterns with contemporaneous market signals — rate levels, related flow activity, index-level information — into a lightweight ML-based alerting tool that estimated whether a particular flow was likely to arrive in the next time bucket.

It was never a high-confidence forecasting system and I wouldn't present it as one. But when it caught the pattern, traders were prepared rather than reacting cold. The useful output wasn't a good model. It was turning a desk intuition — this client sometimes seems predictable — into something measurable enough to act on.

Building a live view across algorithmic and voice trading

Algorithmic traders needed live reference and market data alongside the flow the voice desk was seeing. The information existed, but not in one usable view — and discrepancies between systems made it hard to know whether everyone was reacting to the same market.

I built a real-time dashboard bringing market data, reference data, execution signals and voice-desk flow into a single view. Building it exposed a second problem: some of the disagreement wasn't human. It came from latency and data-flow differences across the algorithmic stack, the voice-trading systems, and the databases underneath them.

What began as a visibility problem became a systems diagnosis. The interface didn't just surface the data — it gave us a way to see where the infrastructure was behaving differently from what its users assumed.

Expanding an electronic product set

Expanding our electronic offering in EUR and GBP wasn't a matter of adding more products. We needed to know where additional coverage would actually change our competitive position.

I started with the market rather than the backlog: product-level rankings, what our highest-value clients were already trading with us, and where their activity extended past what we offered. I paired that with conversations across clients, trading desks and platform stakeholders, then mapped the openings back to the existing product and technical architecture.

Some gaps required genuinely new capabilities. Others could reuse pricing logic, connectivity, protocols or workflows we already supported elsewhere. I separated the reusable pieces from the deeper builds and sequenced them into a quarter-by-quarter roadmap. The goal wasn't to electronify everything. It was to find where another unit of engineering effort would actually change our position with the clients and products that mattered.

Opening a new distribution channel for existing flow

The Rates systematic desk was handling a meaningful amount of odd-lot flow that didn't fit neatly into the institutional channels we normally optimised for. Rather than treat the existing market structure as fixed, we asked whether there was another distribution path.

We evaluated three external platforms offering access to a different client segment, working across trading, quant, sales and engineering to understand the economics, execution model and technical requirements of each. But choosing one was only the first decision. Whichever platform we picked had to become another execution channel inside a trading system that was already live: pricing had to reach it, orders had to route correctly, risk controls had to behave consistently, positions had to come back into the desk's workflow, and traders still needed visibility into what the system was doing.

So the work moved continuously between commercial strategy, market structure and technical integration. The new channel became a meaningful contributor to the desk, and the resulting U.S. Treasuries platform went on to capture roughly 10% of its retail segment. Sometimes the highest-leverage product decision isn't building a new capability. It's finding a new place for an existing one to become valuable.

The common thread wasn't the asset class or the technology. It was that the original request was rarely the actual problem.

Traders and salespeople brought strong intuitions because they were in the market every day. This client behaves differently around this condition. We're losing flow because of this gap. The algo needs this data. We should add this product. Each of those sounds precise until you try to measure it.

My job was usually to turn the statement into something we could interrogate: define the behaviour, find the relevant data, separate a pattern from a convincing anecdote, build enough of the solution to expose its constraints, then decide what deserved production engineering. That's why the analytics work and the product work were never very separate for me — real-time pipelines and dashboards across three desks, front-to-back frameworks for client flow and hedging including DV01 and flow attribution, and classification approaches for studying trading behaviour.

The fastest way to clarify a requirement was often to build enough of it to see where the assumption broke.

Requirements are hypotheses

“It's slow” isn't a specification. Neither is “clients want this,” “the model is wrong,” or “we're losing on price.” They're observations. The work starts by figuring out what would have to be true for the observation to be right.

Instrumentation belongs in the build

I don't like launching something and deciding afterwards how we'll know whether it worked. The telemetry, the analysis and the workflow that let you evaluate a system are part of the system.

Constraints are part of the design space

A trading venue has its own roadmap. A production stack has architecture you can't casually replace. Markets have protocols and regulation. Traders have workflows that don't stop because you're redesigning them. Good solutions are rarely the cleanest ones on paper — they're the ones that survive the environment they're deployed into.

Four years on a trading floor left me with a particular definition of product work. Stay close enough to the user to hear the messy version of the problem. Get technical enough to understand where the system disagrees. Build when building is the fastest way to learn. Then go back to the data and see which assumptions survived.

That's the part of the job I've kept.