< case study / product strategy />
From “let’s sunset it”
to a 25% drop in transaction time.
Product leadership for a Fortune 10 retail pharmacy chain — turning failed payment features into a working MVP across a four-team partnership.
client
Fortune 10 retail pharmacy
role
Senior Product Manager
method
11-step product spine
result
25% reduction in POS wait time
01 · the situation
Three failed payment features. Four teams not talking. One vision waiting to land.
The retailer’s digital team had a backlog of customer-facing payment features that had shipped and never stuck. Each took up to nine steps. Operations had moved on.
“Let’s sunset pre-pay. We can’t get it to work right.”
— Operations team
“Let’s sunset the approach, but not the concept.”
— Me
02 · the approach
Eleven steps, four phases.
discover
Listen, baseline, align
define
The user, the journey, the work
make
Design through working code
validate
Test, then pilot
03 · the hard part
Every team that owned a piece of this said no.
The journey map did what journey maps do: it exposed every team that owned a piece of the experience. Then each of them turned me down.
The card-on-file team had just rebuilt their flow and had no interest in touching it. The barcode team had no bandwidth. The onboarding team had spent a year on a wizard and wasn’t going to let me near it. The point-of-sale team said the data infrastructure I needed didn’t exist.
None of them were wrong. They were protecting real work against a stranger with a Miro board.
So I stopped pitching and started listening. I won them over one at a time, on their terms, with their data. The POS team came around when the workforce numbers showed the change would cut their own transaction time by half. Card-on-file agreed to let me use their module if I matched their design system — so I matched their design system. Onboarding agreed to let their wizard be the starting point rather than the thing I replaced.
By the time we had stories written, every partner was bought in. Not signed off. Bought in. The difference between those two words is the difference between a feature that ships and a feature that gets quietly deprioritized in someone else’s sprint planning.
Shipping requires partners, not approvals.
04 · the pilot
Ten stores. One deliberately small MVP.
We tested against a Figma prototype with real users on usertesting.com, using two cohorts matched to the personas. We A/B tested the content, watched the session videos, adjusted the UX, and stack-ranked what was left by qualitative importance rather than by internal enthusiasm.
Then we scoped the pilot down hard: 10 stores chosen for higher-than-average prepay activity. Schedule V drugs only. eSignature and Save-a-Card integrated, both folded into a single barcode. Clinical program prompts suppressed.
Narrow on purpose. A pilot that tests everything tests nothing — you get a result you can’t attribute and a failure you can’t diagnose.
Transaction time fell from four minutes to three. A 25% reduction, compounding across thousands of transactions per store, per day.
05 · the postscript
Sometimes the right idea wins on a delay.
A corporate reorganization shifted strategy shortly after the pilot closed. Most digital products were backlogged or abandoned. This one included.
In 2025 the concept resurfaced from that backlog and rolled out as “Faster Pickup,” carrying much of the same underlying functionality.
I don’t tell that story as a grievance. I tell it because it’s the honest shape of enterprise product work: you do not always get to ship the thing you built. What you get to do is be right, and leave behind something clear enough, documented enough, and validated enough that when the org is ready, someone can pick it up and finish it.
That is a real deliverable. Most people don’t count it as one.
06 · how I work
What this engagement says about how I work.
01 I don’t fix what’s broken.
Three payment features had already shipped and failed. The instinct in the room was to sunset the concept. The right move was to sunset the approach and rebuild the concept around what the failure data actually showed.
02 Buy-in before momentum.
Every partner team said no first. I earned each one back individually, with their own numbers, on their own terms. Approvals get you a green light. Buy-in gets you a shipped product.
03 Opinion is the cheapest input.
Workforce transaction-time data. In-store ethnographic observation. Prototype testing against matched cohorts. The roadmap was decided by what the data ranked, not by what the room preferred.
04 The constraint isn’t the obstacle. It’s the shape of the solution.
Existing UI libraries, partner roadmaps, organizational politics, a data layer that didn’t exist yet. I built inside those constraints rather than arguing with them, and the build was faster for it.
Have a problem that’s already failed once?
Not ready to book? Email a question first. →