Requirements, architecture, and design translation work spanning teams beyond a single product line.
Owned the decision logic behind what triggers a customer notification — app update, email, or WhatsApp/SMS.
The default instinct in most notification systems is "more updates = more trust." I bet against that. Chose to suppress several "obvious" notification triggers deliberately — status changes that felt significant internally but added noise for a customer who just wants to know when their order will arrive and whether anything's gone wrong.
That meant mapping every checkpoint across an order's full lifecycle first, then deciding channel-by-channel what actually warranted interrupting someone's phone — app-only for low-urgency updates, WhatsApp/SMS reserved for things a customer genuinely needs to act on or worry about.
Led requirements-gathering for a CRM rebuild by reverse-engineering a working spec out of an 88-tab spreadsheet a multi-region sales team had been running the business on.
The spreadsheet wasn't clean data — it was years of accumulated workarounds, broken formulas, and tab-specific logic that different regional teams had quietly built for themselves. The easy path would have been to throw it out and impose a standard CRM template. Instead, I chose to trace through what each tab's logic was actually solving for before writing a single requirement — because a chunk of that "messy" logic was encoding real business rules nobody had written down anywhere else.
The resulting spec covered 10 modules, including pipeline management and volume/revenue forecasting, cross-referenced line-by-line against the original workbook so nothing load-bearing got lost in the rebuild.
Drove the architecture for a three-layer onboarding system (client portal → automated task assignment → escalation monitoring), aligning multiple teams around a single onboarding flow.
Onboarding was fragmented across teams before this — sales handed off to ops, ops handed off to tech, and nobody had a single view of where a client actually stood in the process. Rather than centralizing everything into one monolithic tool (which would have meant rebuilding tools teams already relied on), the architecture kept each team's existing tools in place and layered a coordination system on top: a client-facing portal, automated task routing to the right existing tool, and an escalation layer that surfaced when something stalled.
The bet was that fixing coordination would solve more of the fragmentation than fixing any single team's tool would.
Translated high-fidelity design flows (a full order journey and inventory journey) from Figma into structured, engineering-ready reference documents.
Design files communicate intent visually — engineering needs it broken into states, conditions, and edge cases. The gap between the two is where most build inconsistencies quietly creep in. This meant walking every screen and interaction in the Figma flows and writing out what each state actually required — not just "what does this screen look like" but "what triggers this screen, and what happens if the expected data isn't there."
The output became the shared reference both design and engineering pointed back to when a build decision was ambiguous.