Work
Current work first. The problem, what I do, and what good looks like.
- 01
The tile a shopper actually sees
- Problem
- An internal check can look fine while a shopper still opens a tile that is broken, duplicated, or lying about the product.
- Approach
- Call quality by the failure on the surface: wrong photo, duplicate, missing fact the shopper needs. Track those failures on the surface. Automate only the checks you still trust when you open the tile yourself.
- What good looks like
- Cleanup is judged by that tile, not by an internal check that never predicted what the shopper would do.
- 02
When search ignores what the shopper already showed
- Problem
- A shopper has already shown a price, a brand, or an intent. Search can still contradict it. By the time anyone checks, the trail is stale or it has moved, so nobody can tell if we never knew, or we knew and ignored it.
- Approach
- Get a stable weekly view first. Then split the question: do we even have the signal, and did we use it? Add price, brand, and intent as separate views so product can change one thing and see what happened.
- What good looks like
- You can see exactly where it broke. Personalization is something you can correct, not something you hope is on.
- 03
Where a new item stalls
- Problem
- Showing more new or on-trend things is easy to say as a goal. Harder is seeing where an item first appears, where it stalls, and whether people keep coming back to it.
- Approach
- Write the path an item actually takes. Put every item on that path. Turn the big target into a short weekly list: what to show more of, what is stuck, what already landed.
- What good looks like
- Selection and discovery know what to touch this week.
- 04
Yes or no when you cannot split traffic
- Problem
- A lot of catalog and ops changes cannot be randomized. Teams then either guess, or compare last week to this week and call it a result.
- Approach
- Before anyone ships, write what would count as impact. If you cannot randomize, lock a comparison that can still answer yes or no, and lock it before the change goes out.
- What good looks like
- You leave with a yes or no and a method, not a guess. The next change can reuse it.