Back to BlogProduct Thinking

What Building Internal Tools at Airtel Taught Me About Product Discovery

Internal tools are underrated proving grounds for product thinking. Here's what I learned about discovery, stakeholder alignment, and shipping with trust when your users sit in the same office.

Internal Tools Are a Different Beast

When you build for external customers, you have the comfort of user interviews scheduled in advance, NPS surveys, and analytics dashboards that tell you where people drop off. When you build internal tools, your users are three desks away — and they will tell you exactly what's wrong with your product, loudly, at any moment.

At Airtel Business, I owned an internal analytics platform used daily by Field Ops, NOC, and Automation teams. The intimacy of that feedback loop forced me to get sharper about product discovery faster than any external product role could have.

Key insight: internal users have lower switching costs and higher willingness to give blunt feedback. That's a gift — if you create the right conditions to receive it.

Discovery Step 1: Find the Workflow, Not the Feature Request

Early on, stakeholders came to me with feature requests: 'Can you add a column for X?' or 'Can we filter by Y?' My first instinct was to build those features. My second instinct — the right one — was to ask why. What workflow is that request trying to serve? What decision are you trying to make faster?

Almost every feature request led back to one of three root problems: conflicting KPI definitions across teams, slow data retrieval that forced manual workarounds, or lack of a shared operational view that allowed proactive action.

Discovery Step 2: Define What 'Done' Means Before Building

Four teams — Field Ops, NOC, Product, and Automation — had been running weekly reviews with conflicting metrics. The same SLA metric meant different things to each team. This was causing escalation loops where nobody could agree on what the data actually said.

I spent two weeks facilitating alignment workshops to create a shared OPeX metrics framework. This wasn't coding work. It was pure product work: stakeholder interviews, definition negotiation, and getting written sign-off before building any dashboard.

The PM Skill That Internal Tools Demand Most

Prioritization under political pressure. Internal stakeholders are also your colleagues. Saying no to a feature request from someone senior requires more courage than declining a user request from an anonymous survey respondent. But shipping unfocused tools that try to serve everyone ends up serving nobody.

A good product starts with the workflow, not the feature list — and staying disciplined about that is the hardest part of building internal tools.
All Articles

More Articles

Product Ops8 min read

How I Reduced Network Fault Investigation Time by 90% at Airtel Business

A deep dive into how I approached a painful 3–5 hour manual workflow, turned it into a product problem, and shipped an automation that now runs in production — cutting investigation to 29 minutes.

User Research5 min read

From Research Lab to Product: Lessons from IIT Bombay

Building a collaboration platform for research scientists at IIT Bombay's Nano-bios Lab taught me that the best product insight often comes from watching how people work around your assumptions.