For every 1 E-Way Bill generated in LiveKeeping, 17 were being generated in Tally. I found this. I built the deck. It changed the roadmap.
E-Way Bill Gap
Tally vs LiveKeeping (PRO+)
E-Invoice Gap
Same methodology, second module
API Logs Analysed
To validate the gap quantitatively
Escalation Level
Greenlit roadmap investigation
LiveKeeping is a mobile GST compliance and accounting app for Indian SMBs. PRO+ is the highest-value subscriber tier — users who pay for advanced features including native E-Way Bill and E-Invoice generation. The product team tracked feature adoption. The number looked low. But nobody had asked why.
Tally commands over 80% of India's accounting software market. Over 75% of Indian SMEs use it for GST, TDS, inventory, and payroll. For a decade, Tally has been the default for every CA and accountant who advises SMB clients. LiveKeeping operates inside this ecosystem. The question was never 'is Tally competition' — it was 'where exactly is it displacing us.'
What we knew: PRO+ feature adoption for E-Way Bills and E-Invoices was low. What we didn't know: Were users not aware of the feature? Was it broken? Were they doing it somewhere else? Nobody had run the investigation to separate these possibilities.
I built the measurement from scratch.
Cross-referenced PRO+ plan activation data against module-level event logs. Users who had the E-Way Bill module enabled but showed zero native generation events — across weeks of activity on other features. Not inactive users. Active users avoiding one specific module.
Pulled Tally API call volumes as a proxy for external usage. Found consistent, high-volume API calls on the same accounts that showed zero native E-Way activity. The calls were going out — just not through us.
Ran structured discovery calls with zero-activity PRO+ users. Synthesised findings in Excel. Consistent finding: the native E-Way Bill flow had 4 more steps than the equivalent Tally workflow. No auto-population from existing invoice data. Users had learned Tally years ago and had no reason to relearn.
Quantified the ratio: 17:1. For every 1 E-Way Bill generated natively in LiveKeeping across the PRO+ base, 17 were generated via Tally integrations. Replicated the same methodology for E-Invoices. Got 19:1.
This changed everything about how the problem was presented. 'Low feature adoption' sounds like a marketing problem. '17:1 gap among paid users who are clearly generating these documents — just not through us' sounds like a product-trust and workflow-integration problem. These require completely different solutions. Framing mattered.
Built for VP/CEO. Structured as a business case, not a bug report.
Slide 1: The gap, quantified. 17:1 ratio, rendered visually. One number on a slide. No text.
Slide 2: What this means in business terms. PRO+ users are paying for a feature they're not using. Tally is capturing usage from our paid segment. This is not adoption failure — it's trust failure.
Slide 3: Why users went to Tally. 4 extra steps. No invoice auto-population. Workflow learned over years. CA community endorses Tally.
Slide 4: This is not a feature gap. Tally has no competitive advantage here — they just have incumbency and trust. We can close this with product changes, not engineering heroics.
Slide 5: Recommended path. Two options with tradeoffs. Requesting greenlight to run a deeper investigation sprint before committing to either.
The presentation went to VP and CEO level. The finding directly greenlit a cross-functional product investigation sprint that would not have happened without this analysis. The same diagnostic methodology was reused immediately — and found the 19:1 E-Invoice gap within two weeks.
While the investigation was running, I also fixed the compliance journey reliability.
Pulled and analysed 100K+ API transaction logs. Classified failure modes across three categories: government API downtime (external, nothing we could do), user-input errors (fixable with validation), and sync inconsistencies between mobile and web (fixable with engineering).
Government API Downtime
External. Triage: surface better error messaging so users understand it's not LiveKeeping's fault. Don't fix what's not ours to fix.
User-Input Errors
Duplicate IRN handling, missing transporter details on E-Way Bills, incorrect GSTIN formats. Added inline validation and clear error copy at the point of entry.
Sync Lag (Mobile ↔ Web)
Data discrepancies when users switched devices mid-session. Co-ordinated with engineering on retry logic and session state handling.
Rejection rate reduction across E-Way Bill and E-Invoice compliance journeys
The 17:1 gap was visible in the data all along. It just hadn't been asked about. The most valuable thing I did was decide that 'low adoption' was an incomplete explanation and build a better one. A PM's job is to reframe problems, not just report metrics.
Discovery calls were essential but the quantitative analysis had to come first. Walking into a user call without the 17:1 number would have produced anecdotes. Walking in with the number let me ask much more specific questions — and users confirmed exactly what the data predicted.
I'd have pushed for a formal A/B test of the simplified vs existing E-Way Bill flow before presenting to leadership. The qualitative evidence was strong, but a 4-week instrumented test would have made the product recommendation harder to deprioritise.