Soumyo “Som” Biswas

I make complex systems usable for the people who depend on them.

A product leader across healthcare, financial services, education and aviation analytics — turning fragmented operating realities into trusted digital products, clearer workflows, and measurable outcomes.

Read the stories Download résumé Contact

17,000 healthcare providers onboarded across the GCC

~530K patient bookings facilitated end-to-end

40% reduction in KYC processing time at SBI

45,000 learners reached across 102 municipal schools

01/Through-line

The product problem is rarely just the interface. It’s the system underneath.

i. Patients trying to find and book care across fractured provider data and insurance rules.
ii. Bank staff stuck in manual KYC, judging documents against shifting compliance logic.
iii. Municipal schools where teaching, monitoring and assessment had to line up to move outcomes.
iv. Airport planners reading messy schedule data to make capacity and stand decisions.

The hard part — in every one of these — was not the screen. It was the system behind it: fragmented data, unclear rules, partner dependencies, legacy workflows, and people trying to make decisions without reliable tools. My work has been to make those systems legible, then make them work.

How I learned to see systems.

I did not grow up with one fixed operating system, and I did not set out to be a product person. The discipline I bring to product work was assembled, in stages, by paying attention to the rules of every room I walked into.

i. Movement

Across twelve years of schooling, I studied in seventeen schools across different cities, countries, continents, curricula and accents. That kind of childhood teaches you to read rooms quickly. Every place has its own invisible rules — how people ask questions, who gets heard, what counts as confidence, what counts as noise, and how quickly you need to adapt before the room moves on without you.

What it leaves you with isn’t restlessness. It’s a habit of looking for the operating logic underneath whatever is on the surface.

ii. Two systems at home

My father trained as a metallurgical engineer — moving through cast-iron and steel-plant operations, teaching at the University of the South Pacific in Suva, Fiji, and later technology-training leadership at Tata Infotech. My mother is a Hindustani classical vocalist and musicologist whose work spans Dhrupad, Kheyal, Thumri, Rabindra Sangeet, folk and devotional traditions; her work as a performer, teacher and lecture-demonstrator is the slow, careful business of carrying musical memory, oral histories and performance traditions from one generation to the next.

So I grew up around two kinds of systems: engineered ones that had to work reliably under load, and cultural ones that had to be carried, remembered, taught, and renewed.

iii. First classroom

Work gave that instinct a sharper edge. At Prudential I started inside legacy insurance operations — CRM-linked policy servicing, valuation calculators, exception handling, and financial product rules that had often outlived the people who originally designed them.

The visible problem was usually a form, a report, a calculator, or a turnaround time. The real problem, almost always, was the logic underneath.

iv. Rhythm

My MBA at Welingkar — sponsored through Prudential’s P.A.C.E. programme — became useful because it was never theoretical for long. Finance, operations, strategy and management frameworks on weekends; live workflows, real teams and real customers during the week.

That rhythm shaped how I still work: learn the model, test it against the messy system, keep what survives contact with reality.

v. Pattern

From there, the same shape kept reappearing in different clothes. At Naandi, a school-improvement programme where training, monitoring, assessment, printing, distribution, government stakeholders and classroom reality all had to move together. At Terbium, enterprise transformation across KYC, ordering, engagement and experimentation workflows. At Healthigo, a multi-sided healthcare platform where patients, providers, insurers, mapping partners, mobility partners and operational teams all needed one trusted operating layer.

Different sectors. Same underlying job: translate a complicated operating reality into something people could actually use, govern and improve.

vi. Now

The current chapter is a planned parental sabbatical, and a hands-on prototype — SkySched — turning messy airport schedule data into decision support. The home half sharpened a belief I now bring to every brief.

03/Selected work

Four stories that explain the pattern.

CASE 01

Healthigo · 2016–2020

Making healthcare booking work across patients, providers, insurers and partners.

An in5 Tech-incubated startup that grew into a GCC healthcare platform. The product wasn’t the search bar — it was provider data, insurance eligibility, availability, partner channels and no-show reality, all needing to agree.

17,000 providers 5,600 facilities ~530K bookings 23% no-show reduction 20+ releases/yr

Read the case

CASE 02

SBI · Terbium · 2014–2016

Turning manual KYC into a faster, traceable digital workflow.

A compliance-heavy verification process where the interface was rarely the real problem. The work was translating old product logic into something clear, traceable and reliable enough for teams to operate with confidence.

40% TAT reduction Document validation Offline-capable Audit-traceable

Read the case

CASE 03

Naandi · UNICEF · 2010–2011

Turning school-improvement goals into reliable field operations.

A city-scale UNICEF / MCGM / McKinsey effort across Mumbai’s municipal schools. Systems change at this scale only works when training, monitoring, assessment and frontline reality actually line up.

102 schools 45,000 learners 1,800+ teachers 115 coaches

Read the case

CASE 04

SkySched · current · 2020–

Turning messy schedule data into airport planning decision support.

A hands-on prototype built during a planned parental sabbatical. A privacy-first, on-device iPad app that lets airport teams move from raw schedule CSVs to peak-hour, P90 and stand-planning views without the spreadsheet sprawl.

SwiftUI SwiftData CoreML P90 analysis Stand planning On-device

Read the case

Making healthcare booking work across patients, providers, insurers and partners.

Healthigo started as an in5 Tech-incubated startup and grew into a GCC healthcare discovery and booking platform. The visible problem was finding and booking care. The actual problem was getting every party in the system to agree on what was true at the moment of the appointment.

The situation

The platform served patients across iOS, Android and web while simultaneously serving providers, TPAs, insurance networks, and third-party partners like 2GIS, Careem and Google Reserve. Each of them needed a different slice of the same data — in real time, and accurate enough to act on.

What made it hard

Provider data lived across multiple systems. Insurance eligibility varied by scheme and network. Availability moved by the hour. Partner channels expected their own contracts. No-shows quietly undermined provider trust. A clean booking UI on top of that mess wasn’t enough — the system had to be true underneath.

What I helped build

End-to-end product strategy and platform execution across a cross-border team in Dubai and Hyderabad. Notably:

A REST-first architecture with Firebase, GA4 and AppsFlyer instrumentation, designed for observable funnels and rollback safety.
Integrated partner channels including 2GIS, Careem, Google Reserve, and insurance / TPA workflows, with NextCare becoming the flagship production B2B channel.
Insurance-filtered search across 100+ schemes mapped to provider networks — a GCC first for dynamic coverage at the moment of booking.
Reminder and confirmation flows tuned across SMS, push and email to reduce no-shows without alienating patients.
CI/CD and structured QA discipline that supported 20+ releases per year at <2% rollback.

What changed

The platform reached 17,000 providers across 5,600 facilities and facilitated approximately 530,000 patient interactions, with 4.5M+ reach through partner integrations. The NextCare TPA channel matured into the flagship B2B integration. No-shows dropped by 23%.

What it taught me

Multi-sided platforms fail when one side is treated as an afterthought. Providers won’t trust a system that doesn’t protect their time. Insurers won’t commit unless eligibility is reliable. Patients won’t come back if booking is even slightly broken. The platform’s real job is making every party safe to act.

Turning manual KYC into a faster, traceable digital workflow.

The challenge wasn’t moving paper to screens. It was translating complex verification logic — document authenticity, cross-database validation, regulatory rules — into something staff could operate confidently in real working conditions.

The situation

SBI’s existing loan verification and KYC process was slow, manual and compliance-heavy. Applicants submitted physical documents that had to be checked by hand against multiple databases and regulatory requirements before anything could move.

What made it hard

Field reality was unforgiving: inconsistent connectivity, varying staff familiarity with digital tools, and institutional risk-aversion where a single misstep could delay approvals or trigger compliance review. Any workflow we shipped had to be safer than the manual one, not just faster.

What I helped build

A process map of the manual workflow that exposed bottlenecks and silent failure points.
A step-by-step digital workflow that guided staff through verification without requiring deep procedural memory.
Validation checks embedded in the interface so errors surfaced early, not at final review.
Offline-capable workflows for field staff in low-connectivity areas, syncing safely on reconnect.

What changed

The digital KYC suite reduced manual processing time by 40%, with fewer errors per case. More importantly, the verification step shifted from an opaque manual judgement to a transparent, traceable digital flow — one that auditors and ops leaders could both trust.

What it taught me

Enterprise transformation isn’t about replacing people with software. It’s about giving people better tools for work that still requires judgement. The best interfaces expose complexity only when it’s needed and hide it the rest of the time.

Turning school-improvement goals into field operations.

A multi-stakeholder city-scale programme — UNICEF, MCGM, McKinsey (programme design), Naandi (execution), and a long tail of teachers, coaches and field teams. The work was less about strategy on paper and more about whether the parts could actually move together.

The situation

The programme aimed to improve learning outcomes across 102 municipal schools by training teachers, coaching school leaders, and implementing structured assessment. The intent was clear; the mechanics were not.

What made it hard

Training alone doesn’t change outcomes. Assessment without follow-up action is overhead. Field monitoring that ignores classroom reality just produces theatre. The real challenge was sequencing — making sure content, training, materials, monitoring and assessment all reinforced each other instead of pulling in different directions.

What I helped build

Content design, validation and trainer-of-trainer preparation for the 102-school pilot.
Printing and distribution logistics tuned to academic calendars and field schedules.
Monitoring workflows that gave field teams structure without burying them in reports.
Feedback loops between assessment data and training adjustments, so the programme could correct itself in-flight.

What changed

The programme reached 45,000 learners, trained 1,800+ teachers and 115 coaches, and demonstrated that improvement at this scale depends on operational discipline as much as on pedagogical design. It was later covered as a pedagogy-change pilot by Forbes India.

What it taught me

Programmes that look elegant in slides routinely collapse on contact with the ground. The discipline that matters is sequencing dependencies, naming who owns what, and building feedback loops that catch drift early. It’s the same discipline that ships software.

Turning messy schedule data into airport planning decision support.

A hands-on chapter built during a planned parental sabbatical. The premise: airport planners shouldn’t need to wrestle spreadsheets to understand peak demand, P90 days, capacity pressure and stand allocation — a privacy-first, on-device iPad app can do that work in front of them.

The situation

I’ve had a long thread with aviation — airline economics at university, sailplane training, and years of corridor congestion that quietly raised the question of why depeaking is so hard in practice. The sabbatical was the right window to actually build something at that intersection rather than read about it.

What made it hard

Airport schedule data is messy by default: inconsistent CSV formats, missing fields, timezone errors, duplicates, incomplete aircraft type information. The hard part isn’t cleaning it — it’s deciding what planners actually need to answer, and designing flows that surface those answers without sending you back into spreadsheet land.

What I built

A working iPad prototype, actively maintained. Notable capabilities:

CSV import with field mapping and import diagnostics that surface format problems early.
Movement analysis across daily, weekly and monthly traffic so peaks are visible at a glance.
P90 analysis to surface the 90th-percentile busiest day, week and month — the operational reality, not the average.
Stand-planning logic exploring how schedules translate into ICAO stand sizing, turnaround rules and occupancy.
Timezone-aware calculations and rolling-hour aggregation for honest operational modelling.
On-device throughout — data never leaves the iPad.

What changed

The project kept me product-current through the sabbatical and proved out something I already suspected: moving from a real-world question to a working prototype alone is a different kind of clarifying than leading a team. There is nowhere for sloppy thinking to hide.

What it taught me

Building solo reinforced what every prior chapter has hinted at: the hard part is rarely the algorithm. It’s understanding the operating reality well enough to know which questions are worth answering, and designing interfaces that help people make better decisions without drowning in data.

04/Operating principles

How I work, after fifteen years in the system.

Make the system legible first.

Before optimising anything, draw the actual system: data, partners, rules, hand-offs, where it breaks. Most product debate dissolves once everyone is looking at the same picture.

ii.

Trust beats feature volume.

A workflow that works reliably for ten cases is worth more than one that works inconsistently for fifty. People stop using products the moment outcomes become unpredictable.

iii.

Design for operational reality.

Bad connectivity, distracted users, regulatory load, partner unpredictability. The honest baseline is what already exists on the ground, not what the slide deck wishes were true.

iv.

Measure what changes behaviour.

Pick the few metrics that move when the product actually works — activation, completion, return, no-show, time-to-decision — and let the vanity counters take care of themselves.

Ship with governance, not theatre.

CI/CD, structured QA, rollback discipline, post-incident learning. Premium products feel calm because the team behind them has made operational rigour invisible.

vi.

Good product work translates.

Healthcare booking, KYC, school operations, airport planning — same underlying job. Understand the reality, find the friction, make the system legible, and build feedback loops that let it self-correct.

05/Current chapter

Building again, deliberately.

Since 2020, alongside a planned parental chapter, I have stayed hands-on with product development through SkySched — an iPad product exploring how airport schedule data can support planning, peak-period analysis, and capacity decisions.

The work continues to be the same shape as everything before it: a real operating problem, a messy dataset, a question worth answering, and a quiet preference for systems that respect the people using them.

I’m now looking for product leadership roles where complex systems, operational reality and user trust are the actual job — in healthcare, financial services, aviation, public-interest platforms, or anywhere the hard part lives behind the screen.

Platform & workflow systems Multi-sided products Regulated & high-stakes AI-augmented execution

06/Get in touch

Let’s talk about the system behind the screen.

If you’re working on something complex — a regulated platform, a multi-party workflow, an operating problem disguised as a UI problem — I’d be glad to compare notes.

Email [email protected]

LinkedIn linkedin.com/in/soumyob

Based in Dubai, UAE · open to remote & relocation

Résumé Soumyo_Biswas_Resume.pdf