Decisions

Smaller calls, same discipline.

Short snapshots of product judgment: the signal, the call, and the outcome or learning, including the bets that were stopped. The deep stories live in Work.

Fantasy sports
Product Manager
D-01SunsetBaazi Games · FanBlaze
Sunset live scores. Build for pre-match intent.
Signal
Fewer than 6% of active match-day users used it. Sessions grew ~2 minutes, with no meaningful uplift in mid-match contest joins, lineup changes or re-deposits.
Decision
Sunset the feature and move the effort to starting-XI notifications, injury alerts and head-to-head stats.
More on this call: Sunset live scores. Build for pre-match intent.
Hypothesis
In-app live football scores would cut context switching and lift live engagement and contest joins.
Built
A live score and play-by-play ticker, contest and match-lobby integration, match-event pushes.
Why it missed
Users already followed scores elsewhere, fantasy intent was mostly pre-match, and the low-latency sports API added cost without matching value.
- Observed: <6% of match-day users used it · after launch
- Observed: ~2 min longer sessions
- Observed: No meaningful uplift in contest joins, lineup changes or re-deposits
“Users came for fantasy execution, not passive score consumption.”
Monetization
Product Manager
D-02ShippedWitzeal Technologies
Stop paying the same bonus to every player.
Signal
Reward costs were eating into margin without a clear retention payoff. Bonuses were allocated in flat tiers.
Decision
Replace flat tiers with expected ROI per segment, optimizing for incremental NGR (net gaming revenue) per rupee of bonus spend.
More on this call: Stop paying the same bonus to every player.
Trade-off
Cutting incentives in real-money gaming can quietly hurt retention, the main risk going in. It only reads as a win because both numbers moved the right way.
Segments
New / onboarding
High-value / core LTV drivers
Low-value / recreational
Dormant / at-risk
Mechanics
High-value: targeted loss-protection and liquidity-matched bonuses
Low-value / at-risk: friction-reduction top-ups tied to deposit triggers
Bonus & discount spend: ~20% ↓. Reported. Directional · retention held · flat tiers → expected ROI per segment.
How it was measured: Bonus & discount spend
Bonus and discount spend after allocation moved from flat tiers to expected ROI per segment.
No time window or baseline is recorded. The objective was incremental NGR per rupee of bonus spend; the NGR outcome wasn't captured, so the result is reported as spend and retention.
- Reported: Retention held
The objective was incremental NGR per rupee of bonus spend. The NGR outcome wasn't captured, so the result is reported as spend and retention.
Experimentation
Product Manager
D-03ProgramBaazi Games
Run experiments to reduce uncertainty, not to win.
Signal
A fair number came back inconclusive or negative.
Decision
Use those results to change how later tests were scoped, instead of treating them as failures.
More on this call: Run experiments to reduce uncertainty, not to win.
Practice
20+ A/B tests run end to end: hypothesis, sample size and significance.
“Experiments are not successful because they win. They are successful because they reduce uncertainty.”
Experimentation
Product Manager
D-04ProgramWitzeal Technologies
Replace one-off monetization bets with a testing roadmap.
Signal
Monetization results were inconsistent from one change to the next; the diagnosis was a lack of structured testing.
Decision
An experimentation roadmap across pricing and reward loops, each change written as a hypothesis and run as an A/B test.
More on this call: Replace one-off monetization bets with a testing roadmap.
Trade-off
Testing is slower per idea than shipping on conviction. Every result, including the flat ones, narrows the next bet.
No outcome is attributed to the roadmap: the revenue trend from that period has no recorded baseline, comparison or attribution, so it isn't shown.
Personalization
Product Manager
D-05ShippedBaazi Games
Stop designing one journey for every kind of player.
Signal
A single default journey was underperforming across different player segments.
Decision
Use behavioral clustering to find the segments that behaved differently, then redesign the journey for each.
More on this call: Stop designing one journey for every kind of player.
Trade-off
Every extra journey is more to build, test and maintain. Segmentation pays off when segments are few and clearly different.
- Reported: Session duration and retention reported up ~35% and ~25% respectively · method, window and unit (relative or points) not recorded
Real-money poker
Product Manager
D-06ShippedBaazi Games · PokerBaazi
Match new players to tables they can survive.
Problem
Optimize for D7 liquidity and player survival, not only D0 ARPPU or raw server latency.
Decision
Contextual matchmaking on historical wallet size and skill band, so new players see fewer inappropriate high-stakes tables.
More on this call: Match new players to tables they can survive.
Trade-off
Client-side polling only for active seat counts; static table metadata served from edge CDN cache.
No outcome is shown: the record has no magnitude or method for the player-level results, and the latency figure is an infrastructure measure whose ownership isn't recorded.
Data product
Senior Product Manager
D-07ShippedEdfora
Turn a monthly spreadsheet into a signal a teacher can act on.
Signal
Students disengaged well before faculty found out: retention data arrived through a monthly spreadsheet pull.
Decision
Real-time engagement dashboards, so faculty could step in while a student was still reachable.
More on this call: Turn a monthly spreadsheet into a signal a teacher can act on.
Trade-off
A dashboard shows everything and leaves the teacher to find the problem; the documented next layer, myAdvisor, moves to prioritized alerts timed around a teacher's schedule.
myAdvisor, as documented
High- and medium-priority alerts, raised at module level
History, with filters by module and date
Deep links into the part of the product where the teacher can act
Designed for attention
Notifications timed around a teacher's schedule
Unread alerts handled deliberately
No outcome is shown: the retention figure on record has no unit, comparison or method. myAdvisor is product design from the documentation.
Engagement
Senior Product Manager
D-08ShippedEdfora
Make practice more engaging without making it look like a game.
Signal
DAU had been flat for two months. Teachers flagged early quiz prototypes as “too game-y”.
Decision
Keep the quiz and gamification layer, and work with design so the mechanics don't feel gimmicky to teachers.
More on this call: Make practice more engaging without making it look like a game.
Trade-off
In a classroom product, teacher trust is part of the engagement loop, so some raw engagement is worth trading for credibility.
- Reported: DAU was reported up 12–15% after the quiz and gamification layer. Average session time was reported up ~15%. · Reported before/after for the Glorifire quiz and gamification layer; measurement method, window and control not recorded, so not causally attributed.
Read the full case: Make practice more engaging without making it look like a game.
Feedback loop
Senior Product Manager
D-09SystemEdfora · myPlan · Stakeholder
Pay for the feedback that keeps the system honest.
Signal
A system-generated myPlan is only useful if it is right, and faculty are the people who can tell.
Decision
Faculty confirm each myPlan as correct or incorrect, and accurate feedback earns 100 points, so verification is part of the behavioural loop rather than a chore outside it.
More on this call: Pay for the feedback that keeps the system honest.
The loop, as documented
System-generated myPlan information
Faculty verification
Correct / Incorrect feedback
100 points for accurate feedback
Product-system evidence from the platform's screens, not an outcome. No accuracy or engagement result is attributed to it.
Read the full case: Pay for the feedback that keeps the system honest.
Prioritization
Senior Product Manager
D-10ShippedEdfora · myPAT · Glorifire · Doubt resolution
Reduce doubt-resolution friction without scaling human support linearly.
Signal
During peak JEE exam preparation, doubt resolution on myPAT and Glorifire faced a bottleneck of about 24 hours; students studying late at night could get blocked. About 70% of logged tickets were repetitive, pattern-based questions.
Decision
Evaluated an AI auto-resolver, a 1-on-1 tutor marketplace and a hybrid on RICE and unit economics. Selected the hybrid: step-wise guided hints, verified peer solutions, and SME and faculty escalation, behind a 90% accuracy circuit-breaker. The AI auto-resolver was not shipped as the first solution.
More on this call: Reduce doubt-resolution friction without scaling human support linearly.
Trade-off
Scale against academic integrity: take the repetitive volume off faculty without letting unverified answers through.
Doubt-resolution time: ~24 h to <15 min. Reported to measured. ~24 h peak bottleneck (reported) → <15 min median for the repetitive-doubt pool, 10,000-student pilot.
How it was measured: Doubt-resolution time
<15 min: median timestamp delta between doubt_created and first_qualifying_resolution_event.
~24 h was a reported peak bottleneck, not a median: the backlog could stretch toward a day across nights, weekends and exam-season bursts during JEE preparation. <15 min is the median TAT measured in the 2-week, 10,000-student JEE pilot and stable as the median after the live rollout, for the ~70% repetitive-doubt pool. Percentiles aren't recorded.
- Measured: +18% relative uplift in D14 retention · pilot holdout / A-B cohort against the standard queue
- Measured: >90% resolution accuracy maintained on the hybrid · quality guardrail, audited through SME sampling and post-resolution satisfaction ratings
- Derived: ~60% support and operational cost reduction · calculated from avoided SME and faculty headcount scaling against ticket growth; not a directly observed financial saving
Read the full case: Reduce doubt-resolution friction without scaling human support linearly.
Product and engineering
Android Developer
D-11ShippedDirect Create
Ship one app with three roles, not three apps.
Signal
The platform connected makers, buyers and designers. The alternative was a separate app for each.
Decision
As the sole Android developer, proposed one app where people choose their role, then built it from scratch with the CEO and CTO.
More on this call: Ship one app with three roles, not three apps.
Trade-off
More role logic inside one product, against one codebase, one app to market and a lower technology bill for a small team.
- Reported: Platform context: 400+ maker shops and 100+ designers
An Android Developer role, not product management. The platform figures describe scale; they are not claimed as a result of this decision.

Smaller calls, same discipline.

Sunset live scores. Build for pre-match intent.

Stop paying the same bonus to every player.

Run experiments to reduce uncertainty, not to win.

Replace one-off monetization bets with a testing roadmap.

Stop designing one journey for every kind of player.

Match new players to tables they can survive.

Turn a monthly spreadsheet into a signal a teacher can act on.

Make practice more engaging without making it look like a game.

Pay for the feedback that keeps the system honest.

Reduce doubt-resolution friction without scaling human support linearly.

Ship one app with three roles, not three apps.