Product Manager · Problem Solver · AI-First · Hyderabad
"I apply the same discovery-to-impact process regardless of domain — right now that's operational intelligence and supply chain systems, where I recovered ₹2.8Cr/quarter in verified client revenue by finding the metric that actually mattered to the customer. The process travels; the domain is just where I've proven it so far."
I started hands-on with hardware — IoT testing and industrial automation at Nitro Network — before making the move toward product. That technical grounding shapes how I think: I ask the "why" behind every user problem and the "how" behind every build decision.
From there, I moved into Product Management at Patternlab.agents, where I've owned the end-to-end product lifecycle for Factory Intelligence — an enterprise SaaS platform for manufacturing operations — since May 2024, leading discovery, roadmap planning, backlog prioritization, and Agile delivery for clients like Godrej Jersey. That work is where the Godrej OEE case study and both shipped product features came from.
I'm AI-certified in LLM Evals, Prompt Engineering, and Generative AI — and I apply these hands-on in the products I build, not just as lines on a resume.
What travels with me isn't a domain — it's a process: find the metric the customer actually cares about, validate before building, and make the trade-off explicit when speed and accuracy conflict. That process is what took Factory Intelligence from an energy-monitoring MVP to a stable OEE and downtime platform — and it's the same process behind Master Scheduler, the supply chain product I'm building now, which sits one layer upstream of Factory Intelligence in the same value chain.
Outside of work, I'm usually planning my next trip — I love traveling to new places.
Product thinking is domain-agnostic — these are just where I've proven it so far.
As Product Manager (May 2024–Present), I own the full customer lifecycle — from onboarding to retention — for enterprise manufacturing clients.
"PatternLab's team built a non-con system with increased visibility of the factory floor, helping us with decision making on production planning and shift planning, helping us with ROI realization in a short period of time."
— Amit Sharma, Operational Excellence Head, Godrej CDPLFive patterns that show up across everything I've built — worth knowing before the case studies that follow, which are where each one actually played out.
One client-approved case study, plus two shipped features — each from discovery through measurable impact.
| Case study | The call I made | Impact |
|---|---|---|
| Godrej Jersey OEE | Pivoted from energy monitoring to OEE monitoring after client feedback and a hardware-ROI trade-off | 44%→85% OEE, ₹2.8Cr/qtr |
| Bulk Data Assignment | Rejected faster time-range selection to protect Availability metric accuracy | Entry effort ↓60% |
| Timeline UX Redesign | Chose a familiar paper-logbook format over a fancier dashboard for adoption | 89.1 hrs/month saved |
Godrej Jersey's curd packaging line was running at just 44% OEE, with production consistently missing demand targets. The original product hypothesis wasn't the right one to solve it — I had to find that out and re-scope before any fix could work.
The product started as an energy-monitoring tool — an intuitive starting point for a manufacturing plant. But it didn't scale. Energy losses aren't a recurring problem: fix the leak once and it doesn't come back, which makes for a one-time engagement, not an ongoing product. Clients were asking "how much will you save this year," a question with a ceiling. For plants where energy was only 3-4% of monthly revenue burn, the whole use case just wasn't important enough to prioritize.
Production and process optimization was the opposite: dozens of recurring opportunities, each one solvable and each one worth ROI, and every time the process improved, a new opportunity appeared behind it. I made the call to re-scope the core product around OEE — but we didn't throw away the energy-monitoring work. We kept it as a module for the clients where energy genuinely is a bottleneck, and combined both into a single product: Factory Intelligence.
We ran the re-scoped OEE application through a 6–8 month demo period to build a real usage baseline before committing to a fix. The data pointed to one section as the highest-opportunity bottleneck — packaging, a classic constraint point in FMCG lines — and within OEE's three components (Availability, Performance, Quality), Availability was the clear laggard.
"PatternLab's team built a non-con system with increased visibility of the factory floor, helping us with decision making on production planning and shift planning, helping us with ROI realization in a short period of time."
— Amit Sharma, Operational Excellence Head, Godrej CDPLThe job to be done was simple to state: apply one downtime reason across every affected machine in a single action. But the existing flow required operators to repeat the full classification steps once per machine. On a line with 8 machines, a shared event like a plant-wide power breakdown meant entering the identical reason up to 16 times across two lines — pure repetition with no product value.
Session analytics (Zipy) showed operators repeating the identical downtime entry across 4-6 machines on the same line within minutes of each other — a strong signal the workflow, not the operators, was the bottleneck. Follow-up interviews confirmed it: operators described skipping entries entirely during high-pressure shifts rather than repeating the same classification machine by machine.
The first UI concept let operators bulk-assign by selecting a time range — drag across a window and apply one reason to everything inside it. It was the faster build and the faster click-path. But Availability, a core OEE component, is calculated directly from each machine's exact downtime duration. A time-range selection risked sweeping in partial or unrelated duration records at the edges of the window, quietly corrupting the Availability numbers stakeholders were making decisions on.
I ruled that out and had the team build selection around individual records instead — irrespective of machine or time — so operators could still select many entries in one action, but every duration stayed exact. Slightly more clicks for the operator, but it protected the accuracy of the metric the entire tool existed to report on.
Same job to be done as Bulk Assignment: reduce the time and friction a user experiences completing a required task. Here, operators were filling downtime reasons through fragmented popups that pulled their attention away from the timeline they were tracking — breaking focus with every single entry.
Product analytics showed a sharp drop-off mid-entry on the popup flow, and shift-level data completeness lagged worst during peak-volume hours — exactly when operators had least patience for a multi-step popup. Interviews confirmed operators were mentally tracking the timeline while the popup blocked their view of it, forcing them to re-orient after every entry.
The instinct on a redesign like this is to reach for something more modern — a richer dashboard-style interaction with more visual polish. But our users were factory floor operators who'd spent years logging shift data by hand in ruled paper registers, row by row. Instead of a flashier interface, I pushed for something closer to that existing mental model: a simple inline form laid out like the logbook format they already trusted, so moving to a digital tool asked as little relearning of them as possible.
User confidence mattered more than a fancy dashboard here — the goal wasn't to impress, it was to get accurate data logged without friction. We removed the popup entirely and replaced it with a basic inline form built around that familiar format.
The bet paid off: adoption climbed after rollout, and operator complaints about downtime entry dropped once the workflow matched a format they already trusted — validating the call to prioritize familiarity over a fancier redesign.
"Bharath identified the friction operators were facing with the popup-based downtime entry and brought it to the table with clear user feedback and a strong case for change. Working closely with our UI/UX team, running client testing, and iterating based on real feedback — the team shipped a much cleaner inline timeline experience."
— COO, Patternlab.aiWorking on an AI-enabled ERP platform focused on production scheduling and supply chain management — the layer that sits directly upstream of Factory Intelligence in the same value chain. Factory Intelligence tells a plant what's happening on the floor right now; Master Scheduler decides what should happen next, before it does. My role: gathering requirements directly from prospective clients, testing the product against those requirements, running demos, onboarding clients, and resolving issues as they surface. Currently validating product-market fit across three manufacturing domains — Pharma, FMCG, and Seafood — each with distinct supply chain constraints.
Same eight-stage flow across domains, different pressure points: Pharma at quality check (batch traceability, regulatory sign-off) · FMCG at manufacturing and warehousing (shelf-life, demand variability) · Seafood at distribution (cold chain, spoilage risk).
Master Scheduler's current scope covers demand/production planning, MPS scheduling, inventory tracking, and supplier SLAs — the mechanics (MTS vs MTO, reorder points and safety stock, lead time) are grounded in a CPD-certified course in Supply Chain Management and Capacity Planning, applied directly to how the product is built.
How the product evolved from initial concept to a validated, user-tested interface based on real feedback and market analysis.
The first version — designed based on initial requirements before real user research and client feedback were incorporated.
View v1 in Figma ↗Redesigned after multiple rounds of user interviews, client feedback sessions, and market analysis — significantly cleaner and more intuitive.
View v2 in Figma ↗The initial idea, where it hit a wall, and how I worked through it — written so anyone, not just PMs, can follow the product thinking.
Our first product idea was straightforward: help manufacturing plants save money by monitoring energy consumption on every machine. It made intuitive sense — machines running all day, energy costs add up. Track it, reduce it, save money.
The problem wasn't that it didn't work. It was that it didn't scale as a product. Energy losses aren't a recurring problem — you fix the leak once, and it stays fixed. That makes for a good one-time consulting engagement, but a bad reason to keep paying for software: clients were asking "how much will you save me this year," a question with a hard ceiling. And for plants where energy was only 3-4% of monthly revenue burn, the entire use case wasn't important enough to prioritize, no matter how well the product worked.
So we hit a wall: we'd built something that worked, on a problem that didn't repeat, for customers who didn't feel it enough to keep caring.
Production and process optimization was the opposite kind of problem. There are dozens of recurring inefficiencies on any line, each one solvable, each one worth real ROI — and every time you fix one, the next bottleneck reveals itself. That's not a one-time fix, that's a product a plant keeps needing. We re-scoped the core of the product around OEE, or Overall Equipment Effectiveness — a score for how well a machine or line is being used against its full potential.
Importantly, we didn't throw away the energy-monitoring work. Some clients genuinely do have energy as a bottleneck, so we kept it as a module rather than a dead end, and combined both into one product: Factory Intelligence. We ran the re-scoped OEE side through a 6-8 month pilot to see how it performed with real data before assuming we understood the problem. That data pointed straight at one section of the line — packaging, almost always the tightest bottleneck in FMCG production — and showed that Availability (how often machines were actually running versus sitting idle) was the biggest opportunity.
Factory Intelligence tracks exactly when and why machines stop running, using a Pareto analysis to show which causes of downtime cost the most — in this case, overrunning cleaning cycles, meal breaks running long, and hot water processes taking longer than planned. It then automatically sends that information to the people who can act on it, over WhatsApp and email, with no dashboard login required. For clients where energy is the real constraint, that monitoring is still there too, as part of the same product.
OEE on that line went from 44% to 85%. That's about ₹2.8 crore recovered per quarter — money that was being lost to invisible inefficiency, now visible and fixable.
Operators on the factory floor were stuck doing the same task repeatedly: whenever a machine stopped running, they had to log a reason for it, one machine at a time. On a line with 8 machines, that's fine if only one machine has an issue. But when something affects the whole line, like a power breakdown, the operator had to enter the exact same reason 8 times — across two lines, 16 repeated entries for one event.
The fix seemed obvious: let people select many machines at once and apply one reason to all of them. We confirmed this was a real problem, not just a hunch, by looking at usage data — operators really were repeating the same entry across multiple machines within minutes of each other — and by talking to them directly. Several said they just skipped logging entirely during busy shifts because it took too long.
The fastest version of this feature to build would have let operators select a time range — drag across a period, apply one reason to everything inside it. Quick to build, quick to use.
But a key metric in this product, Availability, depends on knowing exactly how long each machine was actually down, to the precise duration. A time-range selection risked scooping up partial records at the edges of the window — technically inside the range but not actually part of the same event. If that happened even occasionally, the Availability numbers the whole plant relied on for decisions would quietly become wrong, with nobody the wiser.
We turned down the faster option. Instead, operators select the exact records they want to bulk-edit — not a time window, but the specific entries themselves. A few more clicks for the operator, but every duration stayed exactly accurate. We also built a merge-and-unmerge audit trail, so a bulk edit could always be traced back and reversed cleanly if needed.
Instead of logging a downtime reason 16 times for one event, an operator now selects the relevant entries and applies one reason to all of them in a single action, without risking the accuracy of the numbers the whole system depends on.
Operator effort on this task dropped 60%, and the wider reporting process sped up 25%. Data corrections needed afterward dropped 40% — the numbers were right the first time.
Operators were entering downtime reasons through popup windows on a timeline — a fairly standard software pattern. Click a block of time, a popup opens, fill it in, close it, move on.
Except it wasn't working. Usage data showed people getting partway through the popup and not finishing, worst exactly when it mattered most: during busy shifts, with the most downtime to record and the least patience to record it. Talking to operators explained why — they were mentally tracking what was happening on the timeline, and every popup covered it up. Each time one opened, they lost their place and had to re-orient once it closed. It wasn't a training issue. The interface was working against how they actually thought.
The instinct on a redesign like this is usually to go bigger and more modern — a richer dashboard, more visual polish, more features. I pushed the opposite direction. These operators had spent years filling in paper logbooks, ruled paper, one line per entry, written by hand. That was already their mental model for this exact task, and it already worked for them. So instead of a fancier interface, we built something closer to that: a simple inline form laid directly onto the timeline, styled like the paper format they already trusted, so switching to a digital tool asked as little relearning as possible.
Instead of a popup blocking the screen, operators now fill in downtime details directly inline, right where they're already looking — no lost context, no re-orienting.
Data entry time dropped 45%, data completeness went up 30%, and QA-flagged errors dropped about 80%. Adoption climbed after rollout, and operator complaints about the process dropped too — the format matched something they already trusted.
After the energy-to-OEE pivot, we didn't try to build the full platform in one go. We shipped an MVP focused on the core OEE and downtime tracking loop, got it into the market, and watched how real plants actually used it before deciding what to build next.
Once the MVP was live, improvements came from real usage, not guesswork: better downtime classification, then the bulk-assignment and timeline redesign work covered elsewhere on this page. Only after the core experience was solid did we start layering on new features rather than just polishing the existing ones. Stability came before scope.
What started as a single-metric energy tool is now Factory Intelligence — a stable platform covering OEE, downtime, and (for the clients who need it) the original energy-monitoring module, all in one product. It's the system of record for what's actually happening on the shop floor right now.
Factory Intelligence answers "what's happening on the floor right now." It doesn't answer "what should happen next." That's the gap Master Scheduler is built to close — an AI-enabled ERP for production scheduling and supply chain planning, sitting one layer upstream in the same value chain. It's currently in testing, validating fit across Pharma, FMCG, and Seafood manufacturing.
Not just listed on a resume — here's what I actually built, prompted, and evaluated using Claude / Anthropic.
Designed and iterated prompts for three AI output types — shift summary reports, downtime reason classification, and production performance narratives — using Claude (Anthropic).
Claude / AnthropicPrompt iterationOutput shapingDefined eval criteria to measure AI output accuracy — compared AI-generated reports against manually written ground truth by supervisors. Iterated prompts based on failure patterns.
Ground truth comparisonAccuracy scoringFailure analysisManual shift reports. Downtime misclassified. Data gaps unflagged.
AI auto-generates summaries, classifies downtime, flags gaps in real time.
The kind of team and problem I do my best work in.
Large company or enterprise — where product decisions have real scale and cross-functional complexity.
Open to any domain with a hard problem worth solving. Currently proven in operational intelligence and supply chain — happy to bring the same process to AI products, B2B SaaS, or something new entirely.
Product Manager, APM, AI Product, or Implementation Consultant. Comfortable both building from scratch (0→1) and scaling existing products.
Strong engineering culture, data-driven decisions, and high ownership teams that move fast.
Always glad to connect on product, manufacturing tech, or AI. Feel free to reach out — I respond within 24 hours.