Hi, my name is
Sanket Kandagal.
Turning technically complex problems into simple, scalable products.
I work where customer needs, business economics, and technical constraints collide—finding the bottleneck that actually matters and turning the fix into something customers, developers, and teams can adopt and scale.
About
I'm a Senior Product Manager focused on technically complex products across financial infrastructure, payments, APIs, developer platforms, and B2B products.
Most of my work has been in situations where the problem wasn't completely clear at the start: an integration funnel that looked like a sales problem, a compliance flow that was hurting conversion, or an acquired platform where nobody had a reliable map of what still worked.
I like getting close to those problems—talking to customers, looking at the data, understanding the technical constraints, and working out what is actually getting in the way.
From there, my job is usually to make the trade-off clear: what should we fix, what should we leave alone, what should we build once as a reusable capability, and what isn't worth building at all.
More recently, I've been applying the same approach to AI-enabled workflows and independent product development. I'm interested in using AI where it can remove repetitive work or improve decisions, while keeping human judgment where it matters.
The common thread across my work is simple: find the real bottleneck, make the decision clear, align the people needed to execute, and measure what changed.
Core Capabilities Matrix
How I Work · Operating Principles
Six principles that guide how I diagnose product problems, make trade-offs, and align teams.
Find the Real Bottleneck
Never treat symptoms as root causes. Before scaling demand, sales, or building features, look for where adoption, reliability, or operational flow is actually breaking. If you scale demand before fixing the product, you scale failure.
Get Close to Customers & Users
Product strategy without direct contact with customers is mostly guesswork. I like to sit in on real integration calls, look at actual failure points, and understand where the experience breaks before deciding what to build.
Use More Than One Kind of Evidence
For important decisions, I want three things to line up: what users say, what the data shows, and what the technical system actually allows. When they disagree, that's usually where the interesting product problem is.
Make Explicit Trade-offs
A roadmap is defined as much by what we don't build as what we do. I try to make the decision criteria explicit so engineering, leadership, sales, and other stakeholders understand why something is being built, delayed, simplified, or stopped.
Turn One-Off Fixes into Reusable Systems
If the same problem keeps coming back, I look for the underlying capability rather than solving the same problem again. That's how customer requests, risk evaluations, integration work, and operational tasks can become reusable product capabilities instead of permanent manual work.
Align Teams Without Formal Authority
PMs rarely control the teams they depend on. I try to make alignment easier by bringing evidence, making the trade-offs visible, and connecting the decision to a shared business or customer outcome.
Career History & Experience
A mix of platform, fintech, developer experience, and 0→1 product work—usually in situations where the problem wasn't neatly defined.
Independent Product Builder
Mar 2026 – Present · Bengaluru, India
- I'm currently building and validating products independently, mostly around decision systems, financial infrastructure, developer tooling, and AI-enabled workflows.
- BeamDelta: Evolved a structured project-evaluation methodology into a product for research, comparison, and market intelligence, automating data collection and scoring while keeping the underlying decisions explainable.
- AI-enabled workflows: Built an AI-assisted application workflow that combines structured career evidence, job analysis, and human review to reduce repetitive preparation work.
- Core takeaway: The common thread is learning when to automate, when to standardize, and when human judgment is still the better product.
Flagship PM Case Studies
Deep product teardowns structured for progressive disclosure: glance at the 10-second executive summary or expand specific decision layers for granular evidence.
When the "Sales Problem" Was Actually a Product Problem
Finding the integration bottleneck and reducing B2B onboarding from 21 days to 4 days.
OnRamp operated a fiat on-ramp platform designed for Web3 and fintech applications. Management initially believed growth required scaling outbound sales and signing more clients. However, newly signed clients were getting stuck in onboarding for weeks, and engineering was burning hours on ad-hoc support escalations.
"We have a sales & demand problem. We need more marketing, more partner outreach, and aggressive volume targets."
"We have a product & integration bottleneck. If we scale sales before fixing the product experience, we will simply scale failure."
| Evidence Source | What Was Uncovered | Product Implication |
|---|---|---|
| Client Discovery Calls | Integrating developers found documentation contradictory and error payloads opaque. | Integration speed was blocked by DevEx, not developer capability. |
| Funnel Telemetry | Massive drop-offs occurred between sandbox key generation and first test transaction. | Drop-off was structural across all partner tiers. |
| Live Transaction Demo | Walked Engineering, CTO and CEO through a live test purchase; the nominal "happy path" failed due to unhandled edge states. | Proved to leadership that the core product had reliability gaps that sales could not fix. |
| Competitive Audit | Leading global gateways offered complete multilingual SDKs and clear sandbox simulators. | Our friction was an internal product choice, not an industry inevitability. |
| Strategic Option | Pros & Cons | Decision & Rationale |
|---|---|---|
| Option A: Sell Harder | Pros: Immediate sales activity. Cons: Burns client trust and overwhelms engineering support. |
Rejected — Escalating failure into larger clients would permanently damage brand equity. |
| Option B: Bespoke Client Patching | Pros: Low upfront engineering cost. Cons: Creates fragmented code forks and unmaintainable technical debt. |
Rejected — Unscalable; compounds engineering burden with every new partner. |
| Option C: Targeted DevEx & Product Rebuild | Pros: Eliminates root bottlenecks, creates scalable self-serve onboarding. Cons: Requires refocusing near-term engineering bandwidth. |
Selected — Fix the core platform foundation once to unlock sustainable compound growth. |
Through customer conversations, support-ticket analysis, and integration reviews, I identified four structural friction points and executed targeted fixes:
Standardized Error Architecture
Mapped every failure state to a unique error enum, human-readable reason, and direct link to remediation docs instead of generic 400 responses.
Multilingual SDK Suite
Shipped battle-tested SDKs and copy-paste code snippets covering JS, Python, Flutter, and React Native stacks.
Interactive Sandbox Webhooks
Enabled partner engineers to simulate pending, confirmed, and failed webhooks independently in real time.
Internal Enablement Playbooks
Transferred common technical triage playbooks to Account Executives, unburdening core PM and engineering.
My first instinct was to propose a broader API rewrite. Engineering pushed back because the migration risk and effort weren't justified by the problem we were trying to solve.
I kept the problem definition but changed the solution: instead of rebuilding the underlying infrastructure, we focused on the highest-leverage gaps around documentation, error handling, SDKs, examples, and testing. The lesson for me: be willing to change the solution without losing sight of the problem.
Developer experience isn't just documentation vanity; for an API business, it is part of the product itself. If developers can't successfully complete the first integration, more sales activity only increases the number of stalled customers.
Selected Product Builds & Experiments
Data Product · Decision Systems
Product Evaluation & Market Intelligence
Built a structured evaluation and market-intelligence platform that combines automated data ingestion, multi-factor scoring, and role-based access to support both analyst workflows and public research experiences.
31 signals · 7 categories · 80 projects · 40h → 8h analysis effort
- Python
- SQL / Relational DB
- FastAPI / REST
- Docker
- RBAC Auth
Product Experiment · Demand Validation Case
Demand Validation Experiment
Built a lightweight financial simulation product to test whether there was enough user interest to justify continued investment. After weak traction, I stopped feature expansion rather than continuing to optimize a product people weren't asking for.
- Next.js
- React
- Tailwind CSS
- Vercel
Selected Systems & Experiments
AI Synthetic Data Generator
Designed schema-aware synthetic data generation to unblock QA across a relational system with 200+ interdependent tables.
- Python
- LLMs
- PostgreSQL
Structured Decision Engine
Built a repeatable multi-factor scoring system that turned fragmented expert judgment into a consistent decision workflow.
- Python
- Pandas
- Decision Modeling
Role-Based Access Control (RBAC)
Designed a multi-tenant permission model separating public consumer, analyst, and administrative workflows.
- Auth Systems
- REST Security
- Multi-tenant Architecture
What's Next?
Let's Connect
I'm interested in working on products where the underlying problem is technically difficult but the experience needs to feel simple.
That could be financial infrastructure, payments, APIs, developer platforms, or complex B2B workflows. I'm also interested in teams using AI to make products and operations meaningfully better—not just adding AI because it's available.
I tend to do my best work when there is a real problem to untangle, enough ownership to make decisions, and a team that cares about getting the details right.
If you're working on a difficult product problem around APIs, financial infrastructure, developer experience, or complex B2B workflows, I'd be happy to compare notes.
I'm also always interested in talking to people who are building products, hiring product leaders, or thinking about how AI changes the way products get built.