GROWTH

Problem

Every candidate had to clear phone verification before doing anything else, and a meaningful share never got past it. Delivery-latency and user-behaviour analysis both pointed at OTP as the single largest activation bottleneck.

Hypothesis

Failed verifications were a delivery-channel sequencing problem, not a user-intent one. Recover people on a second channel before they give up, and activation rises with no extra acquisition spend.

Approach

• Split the funnel by channel, vendor, and time-to-deliver to separate "never delivered" from "delivered too late" - identical in a conversion chart, opposite fixes.
• Built a progressive recovery ladder - Primary SMS → WhatsApp → Secondary SMS → OTP Call - each rung firing on the previous one's failure, ordered by delivery success, then latency, then user effort.
• Added saved login tokens so returning users re-authenticate in one tap (the Instagram / Flipkart / Zepto pattern), with a fixed TTL after which they re-enter the OTP funnel - plus a secondary SMS vendor for redundancy.

Key Decisions

• Sequence by expected success, not cost: a failed cheap send costs a user.
• Returning users shouldn't verify at all: removing the step beat optimising it - 98.2% on the login segment, ~56% of all volume.
• 5-second delivery as its own guardrail: otherwise the funnel gets "fixed" by simply retrying more.
• A second vendor before a smarter algorithm: redundancy solved a failure class no routing logic could, and shipped faster.

Impact

Why "before" is identical across segments: everyone walked the same funnel - enter mobile → OTP delivered → enter code → verify - on a single vendor, inheriting its throughput issues with no fallback. Segment couldn't matter, because the path didn't differ.

Why they diverge after: the two segments now take different paths.

• Login (~56% of volume) re-authenticates on a saved token in one tap - the pattern Instagram, Flipkart, Zepto, and BigBasket use. No OTP is sent, so vendor delivery stops being a factor at all.
• Register (~44%) still goes through the OTP funnel - but the funnel itself got better, because the fallback ladder recovers the sends the primary vendor drops.
• Tokens carry a fixed TTL, so a login user returning after it expires lands back in the OTP funnel - and picks up the same ladder improvement as a registering user.

What I'd Do Next

• Route the first attempt by carrier and geography, and explore silent network-based verification so eligible users never see an OTP screen.
• Measure activation-to-first-apply - verifying more users only matters if they go on to apply.

Problem

Apply rate on job cards was underperforming and nobody knew why - no established link to pagination, layout, or ranking, just a weak number. So the first step was finding out what candidates were actually trying to do on that screen.

First Move: Ask the Users

A preference survey on how candidates want to reach employers came back clear: 45% preferred a WhatsApp CTA against 18% who would call a recruiter directly - a mismatch with the calling-first flow we pushed them into.

Shipped a WhatsApp HR CTA on job cards with design and engineering. It worked: +30% Lands-to-Apply.

Still Short: Build the Heatmap

The CTA won and apply rate was still below target - the survey had found a problem, not the problem. So I built a click heatmap from raw event logs, mapping engagement by position on the listing page:

• WhatsApp CTA taps were healthy - ruling the new surface out as the bottleneck.
• Clicks concentrated in the top cards, with sharp fall-off down the page.
• Users reached pagination fast - scanning, not evaluating.
• Pagination CTR ran ~2x the Apply rate - they were paging past our listings.

Hypothesis

Now there was a hypothesis worth testing: users paged past listings because there were too few per screen and the ordering was wrong. A discovery problem - not job supply, and no longer the CTA.

Approach

• Benchmarked competitor listing pages, then raised density from 10 to 20 jobs per page - testing the "too few per screen" half on its own.
• With density held constant, shipped custom relevancy-ranking logic to test the ordering half independently.

Key Decisions

• Ask before assuming: with no known cause, talking to users beat redesigning on instinct.
• Don't let a win close the investigation: +30% made it easy to declare victory - the apply-rate metric said otherwise.
• Heatmap over aggregates: funnel totals say "conversion is low"; position-level data says "ordering is wrong". Only one is actionable.
• Lands-to-Apply, not taps: a CTA tapped without producing applications adds noise for employers.

What I'd Do Next

• Make the heatmap a standing instrument, so the next ordering regression surfaces on its own.
• Ranking weights per segment, plus apply-intent prediction and recruiter response SLA as ranking signals.

Problem

CLM spend was growing faster than the DAU it produced. Campaigns optimised for opens - a metric that rewards sending more, more often - so blended cost-per-DAU climbed while heavily-messaged users disengaged.

Hypothesis

Send timing, algorithm reuse, and channel mix are bigger levers than volume. Optimise each user's send moment against downstream value, reuse the logic that already works, and add a genuinely cheap channel.

Approach

• Hourly behavioural, cohort, and notification-level analysis pinpointed send timing as the dominant efficiency driver.
• Grew the Notification Time Affinity Model into a contextual Thompson Sampling system - picking each send window against downstream value, bounded by fatigue-aware caps.
• Traced why in-app recommendation beat retargeting, then had engineering reuse the stronger algorithm across both via Kafka.
• Launched Email re-engagement at ₹0.17 cost-per-DAU, segmented under-engaged cohorts into lifecycle initiatives, and shipped benchmarked notification design patterns.

Key Decisions

• Reward = applications, not opens: a bandit optimises what you pay it for, and opens teach it to spam.
• Frequency caps as a hard constraint: the cap bounds exploration instead of competing with it inside the reward.
• Reuse the proven algorithm: the performance gap was explained - the work was event plumbing, not modelling.
• Reallocate spend, don't cut it: efficiency went back into reach, so cheaper DAU didn't mean fewer DAU.

Impact

Engineered Systems

What I'd Do Next

• Extend the bandit to cross-channel budget allocation - same reward signal deciding WhatsApp vs push vs email.
• Add a permanent no-contact holdout for incrementality, and learn fatigue caps per segment instead of setting them globally.

Problem

A funnel serving 1M+ daily visitors was being changed on intuition. Wins were declared from directional movement and losses explained away, with no shared standard for what counted as evidence.

Hypothesis

At this traffic volume, a disciplined loop - stated hypothesis, powered sample size, pre-declared guardrails - surfaces real lift that eyeballing dashboards misses, and stops us shipping changes that only look positive.

Approach

• Owned experimentation strategy: which hypotheses were worth testing and in what order, on an effort-vs-impact read.
• Set primary, secondary, and guardrail metrics before each launch (primary: Clicks-to-Leads), and sized every test for the effect it needed to detect - so a null meant "no effect worth having", not "not enough data".
• Validated +6.2% Clicks-to-Leads through statistically significant A/B tests, feeding straight into the rollout decision.

Key Decisions

• Clicks-to-Leads as primary: closest to business value here - upstream clicks are easy to inflate and prove nothing.
• Pre-declare success criteria: what separates an experiment from a search for a favourable slice.
• Gate on significance, not direction: a positive-looking underpowered result ships risk, not lift.
• One change per test: no bundling, so every shipped change had an attributable effect size.

What I'd Do Next

• Sequential testing to shorten cycles without inflating false positives from repeated peeking.
• An experiment registry so learnings compound, plus guardrail alerting during rollout to catch a winner that degrades something downstream.

Problem

Technical evaluators on Hevo's Snowflake integration pages couldn't estimate cost before reaching sales - friction in the buyer journey that cost conversion from mid-funnel content.

Hypothesis

A self-serve pricing calculator at the point of technical evaluation lowers the barrier to reaching out, increasing qualified leads with no extra marketing spend.

Approach

• Built a Snowflake-based pricing tool - an interactive calculator on the content pages letting evaluators cost it out themselves.
• Shipped a context-sensitive support chatbot (LangChain + Gemini 1.5 Flash + FAISS) across 50+ technical blogs, intercepting intent at the moment of need.
• Resolved issues across 80+ distributed ETL pipelines via log-level and metric-driven RCA, keeping attribution reporting accurate.

Engineered Systems

What I'd Do Next

• Simulate actual Snowflake credits vs pipeline cost to make the calculator concrete.
• Mine chatbot conversations for the top unanswered questions, and test a "personalised estimate" CTA at peak engagement.

Problem

Automated moderation generated too many false positives, overloading reviewers and delaying legitimate approvals. Reviewers couldn't see why something was flagged, so every borderline case cost a full manual read.

Hypothesis

The bottleneck wasn't classifier accuracy - it was that an unexplained flag is expensive to review. Attach a grounded, policy-cited explanation and reviewers dismiss weak flags in seconds, cutting the false-positive burden at the same accuracy.

Approach

• 32,000+ documents through scalable extraction pipelines, feeding both the classifier and the retrieval index.
• Fine-tuned Roberta-Large for policy violation classification (86.3% held out), plus transformer summarization tuned on accuracy, throughput, and deployment efficiency together.
• Anomaly monitoring over 10K+ interactions via statistical baselines and sliding-window z-scores.
• A RAG layer (Llama 3.2 1B) over a dense index of policy clauses, so each flag cited the clause it allegedly violated.

Key Decisions

• Explainability over more accuracy: the last points of F1 cost more than making each flag cheap to adjudicate.
• Ground explanations in retrieved policy text: a fluent hallucination launders a wrong flag into a convincing one.
• A 1B base model on purpose: the explanation layer runs over every flag, so inference cost was a design constraint from the start.

Impact

What I'd Do Next

• Retrain weekly on reviewer corrections - a human-in-the-loop feedback layer.
• Route only borderline cases (0.4–0.6 confidence) to human review, auto-resolving the rest.