A note on this case study. I worked on this as a hands-on learning engagement with my product manager’s support - I drove the discovery, solution exploration, and requirements work you see here, within a real internal product. The feature scope was handed back to the PM for delivery, so outcomes below are the success targets we defined, not measured results.
The Problem
Our company maintains a large product catalog built from syndicated data scraped from multiple sources. Getting that raw data into a clean, client-ready catalog involved four teams - Data Scraping, Data Engineering, Data Management (DM), and Business/Sales - coordinating through email threads and shared Excel files.
The reported symptoms came from the PM and the data engineering team:
- Inconsistent catalog data quality - no single place where data was reviewed, corrected, or approved
- High manual overhead - the DM team spent hours comparing raw vs. AI-cleaned values and fixing repetitive issues
- No feedback loop - Business/Sales users spotted issues in live catalog products but had no formal way to report them
- Reactive, not preventative - errors were caught downstream as client complaints and support tickets, not at intake
The as-is system: every team touched the same Excel-based data store, with the AI engine as the only automated step.
Framing the Problem
Before jumping to solutions, I scoped what we were actually solving - and, just as importantly, what we were not.
Problem statement:
We have observed that the Data Management, Data Scraping, Product, and Business teams struggle to review, validate, and correct syndicated product data when there is no centralized place to coordinate this work. This results in inconsistent catalog data quality, high manual overhead, unclear team ownership, and a reactive rather than preventative approach to data errors. How might we design a centralized review and correction workflow that gives each team the right visibility and control at the right stage - without replacing the underlying data systems already in place?
Scoping decisions:
| Scope Area | Decision & Rationale |
|---|---|
| In scope | New product intake review workflow; AI suggestion acceptance/override; DM approval & publish flow; business-user flagging of live catalog issues; DM secondary review of flagged items |
| Out of scope | Replacing the AI enrichment engine; changing the scraping process; external catalog syndication; authentication & access management |
| Key dependencies | The Data Engineering team was mid-way through major system changes and would be the first team this workflow touched; the existing Excel handoff had to keep working during transition |
Two constraints shaped everything downstream: the workflow had to slot into the weekly operational cycle the teams already ran on, and no engineering capacity estimates existed at framing time - so the solution had to be right-sized before we could ask “how much?”
The as-is weekly workflow, with problem hotspots marked: manual Excel handoffs, repeated rework, out-of-band communication, and a reactive feedback loop.
Actor Mapping
Because this was a multi-team workflow, mapping who touches the data - and at which stage - was the core of the discovery:
- Data Management (DM) - primary decision-makers; review, correct, and approve products
- Validation Team - quality gatekeepers
- Business / Sales - downstream consumers with flagging rights on live products
- Data Engineering & Data Scraping - upstream producers of raw data
- AI Engine - the enrichment layer (a system actor, not a human one)
This mapping surfaced the key design tension: the same product record needs different visibility and control depending on which team is looking at it and at what stage.
Exploring Solutions
I evaluated three options against weighted criteria - impact on the primary metric, engineering effort, user value, strategic alignment, time to ship, and risk.
| Option A - Structured Email + Shared Sheet | Option B - Centralized Workflow Module | Option C - Automated ML Pipeline | |
|---|---|---|---|
| What | Standardize the Excel handoff: cloud spreadsheet, email templates, shared mailbox | Dedicated Catalog Maintenance module in the existing admin portal: intake queue, AI-suggestion review, approval flow, structured flagging | Automated acceptance of high-confidence AI outputs; humans only review low-confidence records; full audit trail & dashboards |
| Effort | Very Low | Medium | Very High |
| Solves | Versioning and visibility, partially | All five identified pain points | Everything, and scales review without headcount |
| Risk | Doesn’t solve workflow, audit trail, or feedback loop | Preserves existing upstream systems | ML confidence thresholds don’t exist yet - premature automation with no baseline data |
Recommendation: Option B. Option A was a band-aid that left the structural problems in place. Option C was the ideal end-state, but automating review decisions before we even had a baseline for AI suggestion quality would have been premature - we’d be automating on assumptions. Option B solved every identified pain point at medium effort while leaving existing systems untouched, and it would generate the baseline data (like AI acceptance rates) that Option C would later need.
Metrics: What Success Would Look Like
Since delivery was handed to the PM, these targets define what success was designed around:
| Type | Metric | Baseline | Target |
|---|---|---|---|
| Primary | New-category product validation success rate | ~65% | ≥82% within the first PI post-launch |
| Rework | Products failing validation per weekly cycle | 300–450/week | <200/week |
| Velocity | Active review time within the 7-day cycle | Fixed Mon–Sun cycle | ≥40% reduction, enabling same-week correction |
| Scalability | AI suggestion acceptance rate | No baseline (establish in first 30 days) | ≥55% indicates suggestions are trusted |
| Guardrail | Overall catalog success rate | 91–94% | Must not decrease |
| Business | Ad-hoc flags via email/Teams | No numeric baseline | Measurably fewer at 60 & 90 days post-launch |
The guardrail metric mattered as much as the primary one: the new workflow couldn’t be allowed to improve new-product intake while introducing new failure modes elsewhere.
Requirements
The full requirement document (13+ pages in the working repo) covered four modules, mapped to role-based access:
- Catalog Maintenance Dashboard - stats, filters, workspace creation, and the catalog product list, including an overall catalog confidence score
- Catalog Maintenance Queue - the intake list of products pending review, with assignment controls for managers
- Product Review - the core screen where DM compares raw data against AI-suggested cleaned values (UPC, SKU metrics, description, image, taxonomy, brand), accepts or overrides per field, marks items unclear, and submits for approval
- Request Modification - how Business/Sales users flag a live catalog product with a structured reason, routing it back to DM for secondary review
Each product moves through a defined lifecycle - intake → review → approval → publish, with a parallel flag → secondary review → correction loop for live products.
The to-be workflow: the same five teams, but every handoff, review, and flag now happens inside the centralized platform.
What I’d Do Differently
- Talk to end users earlier and directly. Discovery inputs came via the PM and team leads; sitting with DM reviewers watching them work through an actual weekly cycle would have grounded the review-screen design better.
- Define the AI-acceptance baseline first. Option C was rejected partly because no baseline existed - instrumenting the current manual process for even two weeks would have strengthened every metric target.
- Estimate with engineering earlier. The requirements were handed over with no engineering capacity input; a lighter v1 co-designed with the dev team would likely have shipped faster.
Artifacts from the full working repo - executive brief, actor & opportunity maps, the option evaluation matrix, requirement doc, and epic/feature breakdowns - are available on GitHub.