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. Meanwhile, the desk would still have to keep trading through the existing workflow the whole time.

Traders thought in liquidity, risk and PnL. Quants thought in models and signals. For engineers, it was systems, dependencies, and failure modes. Sales saw their clients. External venues came with their own protocols, release schedules and constraints, and no obligation to any of us. My job lived in between all of them.

I worked mostly 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 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 specific client flows at one of the desks were high-volume and hard to anticipate. When they arrived, the desk had to drop what it was doing and respond, so even modest advance warnings could've changed how traders prepared.

I combined historical client trading patterns with contemporaneous market signals, using rate levels, related flow activity, and index-level information, into a lightweight classification ML-based alerting tool. It 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 instead of reacting cold. What made it worth building was the translation. Traders had a hunch that one client was somewhat predictable, and this turned that hunch 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. Discrepancies between systems made it hard to know whether everyone was reacting to the same market.

I built a real-time dashboard that brought market data, reference data, execution signals, and voice-desk flow into a single view. Building it exposed a second problem. Some of the disagreement had nothing to do with people, but 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 turned into a systems diagnosis. The interface surfaced the data, and in doing so it also showed us 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, looking at 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 while 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. Electronifying everything was never the goal. The question was 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 optimized for. Rather than treating 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. 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.

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 a significant share of its retail segment. We didn't build a new capability here, but instead, we found a new place for one we already had, which turned out to be worth more than most of what we could have built instead.

The common thread had nothing to do with asset class or technology. In almost every case, the original request turned out not to be 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 these statements into something we could interrogate. Define the behavior, 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 behavior were some examples of what I did.

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." Those are 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 all 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. The cleanest solution on paper was rarely the right one. What mattered was whether it survived the environment it got deployed into.

Four years on a trading floor left me with a particular definition of product work. Staying close enough to the user to hear the messy version of the problem, getting technical enough to see where the system disagrees with them, and building when building is the fastest way to learn something, then going back to the data and find out which assumptions survived.

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