Product case study

Rules decide what a member can buy. Judgment decides what actually helps them.

Why I built a stakeholder sandbox instead of a slide, who it's actually for, and the product decisions behind it.

Prototype Assurance Fit Built for Senior PM, Loyalty (Assurance) exploration Scope Eligibility engine + relevance model, single interactive page

Try the live prototype →

Who this is actually for

My first instinct was to build something a traveler would see. That's the wrong user. A member never sees eligibility logic or a relevance score directly, only the one offer that survives it. The people who actually need to interrogate this logic, argue about its edge cases, and sign off on it before it ships are Product, Legal/Compliance, Finance, the Brand GM, and the InsurTech partner underwriting the benefit. So I rebuilt Assurance Fit as what it should have been from the start: a sandbox for that room, not a mockup for a member.

The problem I wanted to think through

A loyalty assurance benefit (trip protection, flexible dates, weather guarantees) only earns its place in a program if two separate questions get answered well, in front of the people who own each answer. First: who is even allowed to have it, which is a policy fact Legal and Finance need to see plainly, without it being buried inside a scoring model. Second, and much harder: of everything a member is eligible for, what should actually get surfaced to them right now, which is a judgment call Product owns and needs to be able to defend, not just assert. I wanted to see what it looked like to build both as visibly separate systems that a cross-functional room could each push on.

Eligibility is a compliance question. Relevance is a product question. Conflating them is how you end up either annoying members with irrelevant upsells or hiding a benefit they actually needed.

How I split the logic

The prototype runs two layers that never talk to each other except through a shared list of what's eligible.

Layer	Job	Example
Eligibility (deterministic)	Fixed rules: brand, tier, rate type, trip value, lead time. No scoring, no ambiguity.	Trip Cancellation Protection only appears if the rate is non-refundable. That's a policy fact, not a judgment call.
Relevance (weighted)	Among eligible products, rank by signals that predict actual member value.	A non-refundable, high-value, first-tier booking weights Cancellation Protection higher than a returning Platinum member on a fully refundable stay.

This mirrors a split I've used before in AI product work: let deterministic code own anything that has a single correct answer, and let a scoring or model layer own anything that's actually a matter of context and judgment. Baking both into one rules engine tends to produce something that's either too rigid to personalize or too opaque to trust.

Decisions I made, and why

The reasoning is shown, not hidden. Every recommendation displays the signals that drove it and their weights. A black-box "recommended for you" is hard for a stakeholder to sign off on; a visible trace ("non-refundable + first-tier member, +34") is something Legal, Finance, or a Brand GM can actually push back on in the room.
Ineligible items say why, not just "no." A greyed-out card with no explanation hides the exact thing the room needs to argue about. Every blocked product names the rule that blocked it, so a stakeholder can say "that rule's wrong" instead of just noticing something's missing.
Scenarios load pre-set, not blank. The sandbox opens on a concrete edge case, not an empty form, because a room reviewing this logic needs something to react to immediately, not a configuration screen to fill in first.
Free tier perks suppress paid upsells. Gold and Platinum members already get free rebooking, so the model actively lowers Date Change's relevance for them instead of pushing a redundant paid product. Protecting member trust mattered more here than maximizing attach rate on any single card.
The open questions are on the page, not left implicit. A sandbox that presents its own logic as finished invites agreement, not scrutiny. I listed the specific judgment calls (tier discount sustainability, per-brand weighting, whether the reasoning trace should ever go member-facing) and assigned each to the stakeholder who'd actually own that call.

What this is not

Honest limits

The eligibility rules and relevance weights are illustrative product logic I designed, not derived from real Expedia or One Key data or policy.
It's a single-session prototype, not a tested model — there's no held-out data to validate the scoring against actual booking or claims behavior.
It intentionally avoids any Expedia branding or trademarked terminology; the product names and structure are my own.

What I wanted this to prove is narrower than "I can build a loyalty feature." It's that I can take a role's hardest modeling problem (eligibility versus relevance, rules versus judgment) and actually build the thing, not just describe it.