At Levi's, my first project was the costing system that decides which country we manufacture in. It was three years old, undocumented, and everyone who built it had left. We could have copied the logic. Instead we rebuilt 600+ formulas by hand — and found the company had been placing production on numbers that were wrong.
That's the work I do. I take the manual, undocumented, decades-old processes inside large companies — PLM, costing, sourcing, bill of materials — and turn them into platforms people actually use.
Twenty years across General Motors, Levi Strauss & Co., Globant and Tata Consultancy Services. Fifteen of them inside plants, purchasing and product development, which is why I recognise the real process, not the documented one.
Plenty of product managers can learn a SaaS product. Very few can read a bill of materials. I'm the second kind.
Cost Visibility: reframing a $2B sourcing process that ran on Excel
The challenge
A $2B-a-year sourcing process across 70 vendors and 29 countries ran entirely on Excel and email — and nobody had put a number on the pain.
What I did
Ran discovery across sourcing, costing, design and line planning, reframed the problem from RFQ efficiency to cost visibility across the product lifecycle, and scoped an MVP that fixed the data foundation before the predictive features everyone wanted.
Result
~9,000 hours a year of manual preparation removed, a six-week discovery cycle compressed into about one, and the platform funded.
Product Development rejected my problem statements. I didn't argue — I went wider, and found the bigger problem everyone was standing on.
Problem
Preparing the seasonal RFQ took around ten weeks, most of it copying quotes by hand between spreadsheets. Everyone agreed it was painful; nobody had quantified it, so it had never been funded. My job wasn't to build the tool — it was to build the case.
Approach
I ran interviews and workshops across sourcing and costing with one rule: no pain point goes in the deck without a metric next to it. Then Product Development pushed back on my problem statements. Instead of defending them, I took the same statements to design, line planning and costing and asked each area to confirm or reject them — and that is where the real problem surfaced. Teams had no visibility of item cost while they were still designing the line. They were deciding blind, months before sourcing even started. This stopped being an RFQ efficiency project.
Then I got strict on scope. Costing simulation and cost prediction from historical data were the exciting features, and I cut all of them from the MVP. The MVP had one job: get RFQ data into one structured, comparable place. Prediction on bad data is just guessing faster. I used Claude and Copilot agents to stress-test the PRD and argue against my own logic, and Figma Make to put a clickable prototype in front of users in hours.
Outcomes
Annual spend in scope$2B USD
Vendors and countries covered70 / 29
Manual preparation removed~9,000 h/yr
Cut in RFQ preparation effort40–50%
Discovery cycle, six weeks compressed to~1 week
Validated problem set, cross-functional alignmentFunded
Key insight
When someone rejects your problem statement, don't argue with them — go find better evidence. The rejection was the most useful thing that happened on this project, because chasing it is what turned a sourcing efficiency ask into a lifecycle cost problem worth funding.
76 fields to 22: retiring a 15-year-old process across four continents
The challenge
Sample development had run on paper, Excel and email for more than fifteen years, and late or incorrect samples cost money every season.
What I did
Cut an inherited 76-field form to 22 in workshops with the garment developers themselves, trained 200+ users and suppliers across China, Bangladesh, India and Pakistan, and rolled out one business unit at a time rather than all at once.
Result
3 of 4 business units live in three months — 52% adoption — and $1.04M USD saved per season.
A product built to satisfy every stakeholder satisfies no user.
Problem
I inherited a design from the previous product manager: 76 fields, built to please every area in product development. The result was a form most garment developers didn't need, confused users and slow performance — competing against a paper process people had trusted for fifteen years.
Approach
First I cut it. One workshop with the garment development teams, one question: which fields does the work actually require? We went from 76 to 22. That meant telling several departments their fields were out — and I could hold that line only because the decision came from the people doing the work, not from me.
Then adoption, which was the real problem. Suppliers pasted data from Excel into the module — keeping the old process alive inside the new tool — and then told me the system was slow. I couldn't mandate anything; they're suppliers, not employees. So I sold it one business unit at a time. With Beyond Yoga I made a deal: if we trained every one of their vendors and garment developers, they would commit one hundred percent. We ran the training. They went live immediately, and became the proof for the next unit.
The fourth and largest unit, Men's Bottoms, mapped their process with me, agreed it was painful — and declined to switch tools mid-season until they had seen the others run. I took that as a fair call.
Outcomes
Form fields, before and after76 → 22
Users and suppliers trained, across four countries200+
Business units live in the first three months3 of 4
Adoption against a 15-year-old process52%
Saved per season, fewer late and incorrect samples$1.04M USD
Key insight
Adoption is not a training problem, it's a negotiation problem. The 76-field form failed because it was designed to end arguments between departments; the 22-field form worked because the users owned the cut, and because I traded full training for a full commitment one business unit at a time instead of announcing a go-live date.
600 formulas, no documentation: the numbers deciding where a company manufactures
The challenge
The system that decides which country and supplier Levi's manufactures in was three years old, undocumented, and everyone who built it had left the company.
What I did
Reverse-engineered 600+ landed-cost formulas by hand in two weeks — 22 affiliate countries × 29 supplier countries — and validated every case with Finance and Product Development instead of copying logic nobody could explain.
Result
Wrong formulas, stale duty rates and silent input errors found and fixed, data guardrails added, and run time cut from 12 minutes to 6.3.
The company had been placing production on numbers that were wrong. Nobody knew, because nobody could read the system.
Problem
Suppliers quote the cost to make a garment. The system adds everything else — taxes, duty rates, fees, transport — to produce the real landed cost, and that number decides where production is placed. The legacy system had been modified repeatedly after launch, none of it documented, and the institutional memory had walked out the door. This was my first project at Levi's.
Approach
The easy paths were to copy the old logic, or to ask the business to remember the rules. I trusted neither — memory isn't a specification, and code you don't understand is a risk you carry forward. So we rebuilt the calculations by hand in Excel, compared them to the system case by case, and took every discrepancy to Finance and Product Development to confirm.
Three things came out of it: formulas that had been wrong for years for specific supplier countries; duty rates that were stale, so US tariffs on goods from China were never applied and our landed cost from China was understated; and Finance changing country codes in the input files, which broke the calculation silently. In the new module I added guardrails so an input file with errors can't be uploaded at all. Finance got extra work out of that and weren't happy — it's the only way the number stays trustworthy.
Outcomes
Formulas rebuilt and validated, in about two weeks600+
Affiliate × supplier country combinations covered22 × 29
Classes of silent error found and fixed3
Calculation run time12 → 6.3 min
Returned per product developer during RFQ~5 h/week
Key insight
When nobody can explain a system, don't copy it — rebuild it. The errors nobody documented are exactly the ones costing you money, and they only surface when you reconstruct the logic from first principles instead of migrating it.
The number finance wouldn't trust: ending a reconciliation nobody needed
The challenge
Disney's finance team didn't trust the ticketing platform's data, so every period they rebuilt the reports by hand to check us.
What I did
Instead of defending our numbers, I sat with Finance and walked the calculation line by line — every formula, every condition, every rule about what counts as a sale and when.
Result
Neither system was wrong; within three months Finance dropped their manual reconciliation entirely — roughly 900 hours a year.
People don't distrust numbers. They distrust numbers they can't check.
Problem
At Globant I was the product manager for Disney's Florida parks ticketing platform — a six-year-old, heavily integrated consumer e-commerce system I had to learn fast. The hardest problem on the account wasn't technical. Our figures didn't match Finance's SAP reports, and a client who doesn't trust your data doesn't trust your team.
Approach
I could have argued we were right. Instead we walked the calculation together, and the answer was that both systems were correct: we counted a sale at the moment of purchase, SAP recognised it later. Two different moments, two different numbers. Once Finance could see where the difference came from, it stopped being an error and became a definition.
The rest was the normal product work — I owned the backlog, wrote the epics and stories, and ran every scrum ceremony in Jira for a team distributed across Mexico, South America and the US. Their English ranged from B1 to B2, so I also made sure nothing in the requirements got lost in translation. On a distributed team, a misunderstood story becomes wrong software.
Outcomes
Manual reconciliation dropped within3 months
Returned to Finance — 6 analysts × 3 h/week~900 h/yr
Regions in the team whose ceremonies I ran3
A years-old client data dispute closedNo fault
Key insight
On a delivery account, trust is the product. Winning the argument about whose number was right would have changed nothing; making the calculation inspectable is what got Finance to stop checking our work.
The journey map that won the account: a CRM for 130,000 borrowers
The challenge
A mortgage lender's loan officers managed ~130,000 borrowers in a CRM that didn't match how they actually work — and three consulting firms were competing to define the replacement.
What I did
Rather than trying to become a mortgage expert in a few weeks, I found a senior VP who had spent years as a loan officer, interviewed him repeatedly, and delivered a journey map instead of the requirements list we had been asked for.
Result
Of the three consulting firms on the account, the client preferred our approach.
When you don't know the industry, don't guess. Find the person who's done the job — and deliver one step more than you were asked for.
Problem
Amerisave handles around $36B USD in loans a year. Two things made this hard: I came from healthcare and had never worked in mortgage, and our work was being benchmarked live against two competing firms. Everyone was going to hand over requirements and pain points.
Approach
I decided my job was to ask better questions rather than to fake domain expertise, so I went looking for the one person who had actually done the job. That's where the real answer came from — including the obvious question of why they couldn't simply buy Salesforce. Because a standard CRM models the loan stage, and a loan officer needs the person: the best time to reach them, whether they were approachable or negative on the last call. That's the relationship that closes the loan.
Then I went one step past the brief. Instead of a list of complaints, I built a journey map — and taught the three business analysts to build one too, each owning a different part of the funnel — so we could show friction points and how to fix them.
Outcomes
Borrowers in scope for the new CRM~130,000
Annual loan volume behind the account~$36B USD
Business analysts trained on journey mapping3
Competing consulting firms — chosen approach1 of 3
Key insight
Domain gaps are closed by access, not by study. Finding one practitioner-turned-executive was worth more than weeks of reading — and delivering the artifact the client didn't ask for is what separated us from two firms doing exactly what was requested.
