I find the path forward when the constraint is the job.
I build platform products where the constraint is never just one thing. Regulatory frameworks, vendor ecosystems, and enterprise delivery deadlines arrive together.
Across financial communications, tax compliance, and telecom infrastructure, I've shipped products where the path forward required figuring out what was even architecturally possible before deciding what to build. My background is infrastructure-deep across regulated markets, and that is exactly what fintech platform problems require.
Selected Work
Three regulated products. Three industries. Measurable outcomes each time.
Each case study follows the same structure: the regulatory or ecosystem constraint that defined the problem space, the discovery process that identified the right abstraction layer, and the measurable outcome that followed.
Context
Global Relay's enterprise communication platform served 1,000+ regulated financial institution clients. The archiving perimeter needed to expand as communication channels proliferated. Clients were using channels outside the firm's supervised perimeter, creating growing regulatory exposure.
Why this problem
Multi-party messaging across channels fell outside supervised archiving perimeters. SEC and FCA off-channel enforcement was accelerating. Firms were being fined for communication outside their compliance perimeter. The product needed to enable secure multi-party messaging while ensuring every conversation was captured and available for regulatory discovery.
Discovery
Structured conversations with compliance officers revealed the pain was regulatory exposure, not missing features. They needed to answer whether every conversation was captured, searchable, and producible on regulatory request. Competitive analysis confirmed no CPaaS provider had built configurable multi-channel compliance archiving at enterprise scale.
Solution
Multi-party messaging built directly into the platform with compliance from the start. Users could initiate group conversations across channels with full capture of content, media, and metadata. Vendor API negotiation with our primary vendor partner was critical — their API lacked native support at the level required. Result was a configurable compliance layer across the channel mix each client needed to supervise.
Execution
The cross-functional delivery involved engineering, legal, and finance. The vendor API negotiation was a partnership conversation presenting mutual commercial benefit to our primary vendor partner's product team. The commercial team had concerns about deprioritising existing commitments; the case was made on projected volume uplift and the size of the compliance gap in the market. The hardest constraint was timing. The vendor APIs were not yet generally available, which created a direct dependency on their GA release date before we could ship to clients. The A2P regulatory landscape also shifted mid-build; the configurable architecture absorbed the change without requiring a core redesign.
Impact
167% paid seat growth and 2× ARR over 24 months. Growth driven by solving regulatory exposure financial institutions could not leave unaddressed. Multi-party messaging with full compliance archiving became the primary commercial differentiator.
Learnings
Qualify vendor API readiness earlier — the dependency on our primary vendor partner's timeline introduced delivery risk. In regulated product work, architecture needs configurability from the start. Building for multiple potential outcomes was the right call.
Context
IRIS Element was a locally-installed desktop application used by 10,000+ UK accountants and tax professionals for individual and business tax filing. The product had no cloud presence and no omnichannel capability at a moment when HMRC's Making Tax Digital initiative was fundamentally changing how tax data could be submitted, stored, and accessed.
Why this problem
HMRC's Making Tax Digital regulatory shift created a hard external deadline for compliance. Staying on desktop-only architecture would have left IRIS clients directly exposed to regulatory non-compliance — the same pattern as off-channel enforcement in financial communications. The migration wasn't optional; the question was what to build, what to cut, and how to ship it before the deadline.
Discovery
The HMRC constraints on cloud-hosted tax data defined the outer boundary of what was architecturally possible before a single requirement was written. Understanding those constraints precisely — what data could move to the cloud, under what conditions, with what access controls — was the first product decision, not the last. Discovery ran in parallel with constraint mapping across legal, compliance, and the Tax SME team to define what "done" could actually mean within the regulatory envelope.
Solution
A cloud-hosted MVP scoped tightly to the core tax filing workflow — the subset of functionality that 10,000+ accountants used most frequently and that HMRC's digital submission requirements touched directly. Non-essential features were deferred. The API-driven cloud storage integration that automated file uploads was the single highest-impact decision: it removed the manual step that accounted for the majority of the 33-minute baseline workflow.
Execution
Coordinated a 12-person cross-functional team across frontend and backend engineering, UX, Tax SME, and architects, with legal and compliance sign-off required on the cloud data architecture before build could proceed. The Tax SME was the critical dependency — every workflow decision needed domain validation before engineering could act on it. Scope discipline under a fixed 8-month deadline required constant prioritisation pressure: if it didn't directly serve the core filing workflow or satisfy the HMRC constraint, it didn't make the cut.
Impact
Shipped on schedule to 1,500 beta users within the 8-month window. The API-driven file upload automation reduced the core tax filing workflow from 33 to 17 minutes — a 49% improvement for 10,000+ professionals. Zero regulatory compliance issues on cloud data architecture at launch.
Learnings
Hard regulatory constraints are a product design input, not a compliance sign-off step. Bringing HMRC requirements into architecture conversations early prevented rework and gave the team clearer boundaries to design within. The prioritisation discipline — a maintained cut list with written rationale — is what I've carried forward most directly.
Context
BT/Openreach B2B partner platform serving Sky, Vodafone, and BT Retail as simultaneous integration partners. Each had distinct SLA requirements and integration preferences.
Why this problem
Building bespoke integrations per partner was creating unsustainable delivery complexity and growing SLA compensation costs.
Discovery
Mapped integration requirements across all three partners. Identified the shared architecture layer that could serve all three without bespoke builds.
Solution
Single coherent API platform architecture with configurable parameters per partner. One platform. Three consumers.
Execution
Translated three sets of competing requirements into a unified spec. Managed stakeholder sign-off across three enterprise partner organisations simultaneously.
Impact
20% reduction in delivery time. 15% YoY reduction in SLA compensation costs.
Learnings
Multi-party platform design requires finding the abstraction layer early. Bespoke builds feel faster in week one and become the bottleneck by month six.
How I work
The method that repeats across every regulated environment.
Map the constraint
Before deciding what to build, map what's actually possible given the vendor ecosystem, regulatory environment, and delivery constraints simultaneously. Most teams start with the solution. I start with the constraint — because the constraint usually contains the answer.
Find the abstraction layer
There is always a single architecture decision that serves all parties without bespoke builds. I found it for three enterprise partners at Openreach. I found it for A2P regulatory compliance at Global Relay. The pattern transfers across domains because multi-party API ecosystems are structurally similar whether the regulated layer is telecom, tax, or financial communications.
Ship before the framework settles
Regulatory ambiguity is not a reason to wait. Build configurable logic that absorbs multiple outcomes. The A2P 10DLC framework changed three times during delivery. We shipped on time because the architecture was designed to absorb change, not depend on certainty.
Measure the ecosystem
MAU and activation rates matter. So do vendor API response times, partner SLA compliance rates, and regulatory acceptance rates. The product metric is one layer of a multi-layer system. Missing the ecosystem metrics means missing the early signals.
What colleagues say
LinkedIn recommendations from people I've shipped products with.
I've been working with Shanal Agrawal at Global Relay for the past 3 years as an SDET in the same team, and he's been a strong Senior Product Manager to work with. He does a great job driving end-to-end execution across backend systems that require coordination between multiple engineering teams, UI dependencies, and external partners. What stands out is his ability to quickly break down ambiguity, identify risks early, and align all stakeholders so delivery stays on track. He is calm under pressure, easy to work with, and brings a strong sense of ownership to everything he drives.
Shanal is a powerhouse Technical Product Manager who consistently turns complex requirements into actionable roadmaps. I've worked closely with him as he spearheaded the gathering and refining of feature requirements, ensuring total clarity for the engineering team. Beyond his technical acumen, Shanal's foresight is a massive asset; he stayed ahead of every 3rd-party provider update, allowing us to anticipate shifts and plan well in advance. His focus on team performance and his commitment to on-time delivery make him a vital asset to any product organization.
Working on a product problem in a regulated environment?
12 years shipping platform and API products where regulatory ambiguity, vendor ecosystems, and delivery constraints intersect. Always happy to compare notes.