A note on this brief: it's a sample showing how I think through a product problem like this one. It is not based on real company data, and every detail is illustrative.
A refunds problem, worked through the way I'd handle it on the job: aligned with my team lead, grounded in users and data, and shipped carefully.
The assignment
My team lead hands me a problem: too many customers who experience a failed or incomplete order don't know if, when or how they'll get their money back. Refund complaints are climbing, support is overloaded, and trust is taking the hit. My job: own this problem and come back with a plan.
1. Align with my team lead first
• Agree on scope: are we fixing the whole refund journey or starting with one order type?
• Confirm what success looks like to them: fewer tickets, faster refunds, better retention?
• Set check-in points so they see my thinking early, not just at the end
2. Understand the problem
• Read a sample of refund-related support tickets to hear the actual complaints
• Talk to 5–8 customers who recently asked for a refund
• Sit with support and ops to see how refunds are handled today
• Pull data: refund volume, time-to-refund, repeat orders after a refund
3. Map who is affected
• Customers waiting for their money back
• Vendors whose orders get cancelled
• Riders caught mid-delivery
• Support agents handling the complaints
4. Bring options back to my team lead
• Present 2–3 solution directions with evidence, not just one idea
• Flag the trade-offs honestly: instant wallet refunds vs fraud risk, automation vs a human check on large amounts, customer speed vs vendor fairness
• Agree on a direction together, then own the agreed scope from there
5. Catch edge cases early
• Partial orders: one item missing, the rest delivered
• Paid by wallet vs card vs transfer: different refund paths
• Vendor already started cooking before cancellation
• Duplicate refund requests for the same order
• Card payment reversed by the bank after a wallet refund
6. Ship carefully and measure
• Pilot in one city or one order type before a wider rollout
• Brief support with an FAQ and escalation path
• Check refund accuracy daily for the first week
• Track median time from complaint to refund, refund-related tickets per 1,000 orders, repeat orders within 14 days, and wrong or duplicate refunds (should be near zero)
• Run a go / no-go review with my team lead before scaling
What my team lead gets from me
Seven documents, in the order I'd produce them: from the problem one-pager I share before any solution work, to the post-launch review. Each one opens up below.
Product documents
A note on these documents: they are samples I wrote to show how I think through a problem like this one. They are not the real company documents, and every name, figure and detail is illustrative.
Product:
Refunds for failed & incomplete orders
Audience:
Team lead
Status:
Shared before solution work
Owner:
Product Manager
The problem
When an order fails or arrives incomplete, customers don't know if, when or how they'll get their money back. Refund complaints are climbing, support is overloaded, and trust is taking the hit.
Who is affected
Customers
How it hits them:
Money held with no clear timeline; they contact support or leave
Vendors
How it hits them:
Cancelled orders create disputes over who bears the cost
Riders
How it hits them:
Caught mid-delivery when an order is cancelled
Support
How it hits them:
Rising ticket volume with no self-serve answer to give
Group
How it hits them
Customers
Money held with no clear timeline; they contact support or leave
Vendors
Cancelled orders create disputes over who bears the cost
Riders
Caught mid-delivery when an order is cancelled
Support
Rising ticket volume with no self-serve answer to give
Evidence so far
Sample of refund-related support tickets: most ask 'where is my money?', not 'how do refunds work?'
Refund volume and time-to-refund pulled from internal data (illustrative figures)
Support and ops sessions: refunds today are manual and inconsistent
Scope agreed with my team lead
In scope: the customer refund journey for failed and incomplete orders
Out of scope for now: vendor payout disputes, rider compensation
Success: fewer refund tickets, faster refunds, customers who come back
Check-in points
After discovery: findings and opportunities
Before build: options and a recommendation
Before launch: go / no-go review
What I'd have achieved afterwards
• Customers know exactly when and how they'll get their money back, without contacting support
• Refund-related support tickets drop, freeing the team for real issues
• Refunds are faster and accurate: no duplicates, no wrong amounts
• Vendors and riders are treated fairly in the flow, not just customers
• A clear, repeatable refund process the team can extend to new order types
• My team lead gets full visibility throughout: early check-ins, honest trade-offs, and a measured rollout
Why me: I've worked on wallet funding, failed payments and reconciliation, the same money-movement problems that sit behind refunds, payouts and order payments. And I know how to work a problem with a lead: bring options and evidence, agree on direction, then own the delivery.