Somendra Sahai

Background

The business wanted to push digital adoption up and pull operational cost down by cutting the volume of general-query support tickets. The case was that a mobile channel would compound in value the longer it existed, so building it now, well, was worth more than building it later, fast.

Context

Technical Product Manager for Amplifi Capital, a UK-based fintech servicing a £2M monthly loan and fixed-savings portfolio. Owned the product end-to-end — MVP scope, roadmap, technical integration decisions (Amazon Cognito for auth, Twilio for SMS, Salesforce for CRM sync) and go-to-market readiness — partnering with C-suite, engineering, UX, compliance, legal and marketing. Led a distributed cross-functional squad of 15 across India and the UK.

Problem

Customers could only self-service their loans through a web portal — no mobile option existed. That limited accessibility, and it was driving avoidable support volume from customers who expected an on-the-go experience. Any new app also had to satisfy strict security and compliance requirements from day one, not as a bolt-on.

Process

• Owned roadmap, PRDs and release planning, using MoSCoW prioritization to balance business value, UX, platform security and engineering effort — and to get stakeholder alignment across two countries.
• Sequenced a security-first backbone: Open Banking connectivity, card payments, Amazon Cognito MFA, device binding, secure storage migration, app integrity checks and compromised-device protection.
• Reviewing App Store analytics, spotted an unexpected pattern of organic, pre-login downloads sitting alongside the invite-only rollout to existing customers. Hypothesized these were prospective borrowers arriving directly from Play Store / App Store search rather than the invite flow — and shipped a pre-login page that redirected them to a loans page. Confirmed the effect with an A/B test before rolling it out fully.
• Used GA4, Firebase and Hotjar to track activation, feature adoption and retention against MAU/DAU, funnel and cohort metrics — balancing feature velocity against platform reliability throughout.

Prioritization Call: Device Binding

The business wanted device binding — auto-logging out a user's previous device the moment they logged in on a new one. I turned it down, and here's the actual comparison that drove it:

Same engineering capacity, two options, one clearly lower-impact by the data we had. That bandwidth went into the higher-impact security work instead — a call I revisited every quarter as usage patterns shifted, since "low today" isn't "low forever."

Visuals

What the 25% actually meant: At 2.5x the industry benchmark, it wasn't just a good number — it was proof that customers would accept the app as a primary channel, not a side option.

Beyond the App: Platform-Wide Improvements

• 65% fewer misrouted tickets via a Salesforce Omni-Channel implementation.
• 30% fewer complaint follow-ups through Salesforce Case Management.
• Zero security incidents post-MFA rollout, with 50% user adoption.
• 75% of customers renewed fixed savings products through automation.

In Hindsight

I'd have pulled mobile number verification earlier into the loan disbursement process itself. Verifying the number at disbursement — rather than as a separate pre-MFA step in the app — would have removed a redundant verification stage and shortened the onboarding path to first login.

Background

Techstreet is a reseller of standards documents which was running on a legacy architecture. The legacy Oracle/Ruby stack was actively constraining the product: character-length limits and poor handling of special characters were surfacing as real customer-facing defects, and the stack had a scaling ceiling. Moreover, Ruby on Rails talent was getting harder to hire, which meant the "do nothing" option had a rising cost of its own.

Context

Product Owner for Techstreet's standards-management platform, serving 130,000+ subscribers across 150+ industries — a system with over a decade of accumulated legacy workflow logic.

Problem

The platform ran on an aging Oracle/Ruby stack with hard technical ceilings — character-length limits, weak special-character handling, and scaling limitations — plus a shrinking talent pool for Ruby on Rails. A complete tech overhaul was needed, without breaking the document lifecycle that 12 major Standard Development Organizations depended on.

Process

• Defined the product roadmap and migration strategy for the platform modernization, treating it as a product problem, not just an infrastructure swap.
• Worked directly with stakeholders to unpack complex legacy workflows and translate them into scalable product requirements covering the entire standards-document lifecycle — ingestion through repository management.
• Sequenced onboarding of 12 major Standard Development Organizations onto the modernized platform, coordinating UAT alongside new customer onboarding.

Where It Could Have Gone Wrong

The highest-risk point wasn't the new stack — it was the field mapping between the legacy Oracle/Ruby schema and the new MongoDB/Java model. Get that wrong and downstream data silently breaks. To de-risk it, we didn't treat internal QA as the finish line: we required a formal UAT pass directly from the client before any deployment, so mapping errors surfaced against real client data, not just our own test cases.

The Hard Part

Normalizing data across sources was harder than the migration itself. Each Standard Development Organization fed data independently and used different field names for conceptually identical data. Designing a single uniform data structure that could absorb all of them, without losing organization-specific nuance, took more iteration than the technical replatform did.

What the 20% actually meant: The growth came specifically from onboarding 2 new customers onto the modernized platform — proof the new architecture could actually absorb net-new customers, not just carry the existing 12. That's the difference between "we migrated successfully" and "we now have a platform we can scale into growth," which is what justified the investment into the modernization.

Context

Lead Business Analyst / Product Owner for JustEZ, a claims-inspection mobile app for P&C insurance adjusters. Owned the product through discovery, MVP definition, backlog build-out and development.

Problem

Adjusters lacked a purpose-built field tool — inspection scheduling, routing, media capture and reporting were fragmented across disconnected systems, slowing down claims verification and processing.

Process

• Ran product discovery through user interviews and surveys with adjusters and claim supervisors to define the MVP and validate real field needs before writing requirements.
• Owned the backlog and prioritization across claims-platform integration, Google Maps & Apple Maps navigation, Dropbox integration, inspection scheduling, media capture, digital sketching and field notes.
• Conceived and prioritized a route-optimization feature using shortest-path and inspection-time algorithms to cut wasted travel between field visits, validated against prototypes with adjusters.
• Partnered with the Data Science team to define AI-powered computer vision for automatic image titling as part of the roadmap.

What the Interviews Surfaced

Going in, I expected the biggest pain point to be inspection itself. Instead, adjusters told us they were losing significant time just planning their day and navigating inefficient routes between sites — a problem I hadn't scoped for at the start. That finding is what led to prioritizing a day planner built on shortest-path and least-time routing, rather than treating it as a nice-to-have.