Product Owns the Checkout Roadmap. Risk Owns the Veto.

A product team ships a roadmap for checkout the way it ships a roadmap for anything else: rank the items by expected lift, sequence them against the quarter, report the conversion delta. Fewer required fields. A saved-card option. Guest checkout without an account prompt. Each item, read on its own line in the roadmap doc, is a conversion improvement with a number next to it.

Read from risk's desk, the same roadmap is a list of changes to the fraud-loss curve. Fewer required fields means less signal to score a transaction against. A saved-card option changes who can complete a purchase without re-authenticating. Guest checkout removes the account history that a fraud model uses to tell a repeat customer from a stolen card on its first use. The roadmap does not have two versions. It has one version and two ways of reading every line on it.

The conflict is not a stalled proposal, it is a running total This is the difference from a single decision that gets stuck for a quarter and then resolves. A checkout roadmap does not stall on one item and clear. It generates a new instance of the same disagreement on every item that ships, because product's job is to keep finding friction to remove and risk's job is to keep finding exposure in whatever gets removed. Neither is doing anything wrong. The roadmap is structured so the two jobs collide on a fixed schedule, not as an occasional exception.

Product owns the roadmap: what ships, in what order, against what conversion target. That is a real mandate, and the team is measured against it every quarter. Risk owns the loss curve: what the fraud rate does, what the chargeback ratio does, whether the loss number stays inside the range the business can absorb. That is also a real mandate, measured on its own schedule and reported to a different committee.

Neither mandate covers the actual decision What neither function owns is the specific question a checkout roadmap keeps raising: when a conversion gain and a loss-exposure increase arrive in the same feature, which number governs. A payment product decision inside a bank showed a related version of this gap, where a single proposal crossed five functions and none of them had the authority to close it alone. The checkout roadmap version is narrower but more frequent: two functions, both chartered, both correct within their own mandate, and no third mandate that says which one wins when the two disagree on the same line item.

A product manager who has delivered on conversion all year reasonably assumes the mandate extends to shipping whatever gets there fastest. A risk lead who has kept the loss number inside range all year reasonably assumes the mandate extends to blocking whatever threatens it. Both assumptions are defensible and they cannot both be true on the same roadmap item.

The absence of a decision rule does not produce a stable compromise between conversion and loss tolerance. It produces a pendulum, because whichever function has more leverage in a given quarter sets the terms until the cost of that quarter's choices shows up on the other function's dashboard.

• A growth quarter favors product: friction comes out, conversion rises, and the roadmap moves fast because risk's objections are treated as a tax on speed rather than a input to the plan.
• The following quarter, the fraud-loss curve reflects what came out, the loss number crosses the range risk is accountable for, and risk gets the leverage to freeze the roadmap until every recent change is re-reviewed.
• Product then spends the freeze quarter defending shipped work instead of shipping new work, the conversion number stalls, and the leverage swings back once a growth target is missed.

Each side wins in sequence, never together, and the roadmap spends more time re-litigating last quarter's decisions than making this quarter's. The pendulum is not a personality problem between two leads. It is what happens by default when a shared surface has two owners and no rule for which one's metric outranks the other on a given change.

Not every roadmap item carries the same exposure, and treating all of them as equally contested is what makes the review process as exhausting as having no process. The items sort cleanly into three classes once someone bothers to sort them:

• Changes inside an already-agreed risk envelope — copy, layout, field ordering, anything that does not touch what data is collected or how a transaction is scored. Product decides alone; risk sees the roadmap, does not sign off on each line.
• Changes to authentication or verification thresholds — step-up triggers, saved-card rules, guest-checkout eligibility. These move the loss curve directly. Risk sign-off is required before the item ships, on a fixed turnaround, not an open-ended review.
• New payment methods or a material change to what identity data checkout collects — these get a joint review against a loss-tolerance number both functions agreed to before the specific proposal existed, so the conversation is about whether this item fits inside that number, not about re-litigating what the number should be.

The categories do the work that a single stuck proposal cannot: they turn a recurring argument about which function's number matters more into a standing rule that only asks, item by item, which category this one falls into. The same move — naming the decision class instead of refereeing the individual case — is what closes the gap in decision architecture generally, and it holds here because the underlying pattern is identical: a shared surface, two legitimate owners, and a rule that was never written down for the category itself.

The joint-review category only works if the loss-tolerance number exists before a specific proposal is on the table. Written in the middle of a live disagreement, the number gets set by whichever side is more persuasive that week, which reproduces the exact problem the rule was meant to solve. Written in advance, with both functions signing off on the range while no particular feature is at stake, the number becomes something the next ten roadmap items can be checked against without reopening the argument each time.

A checkout roadmap that keeps re-litigating the same conversion-versus-loss tradeoff is not evidence that product and risk disagree too much. It is evidence that nobody wrote down, for the category of change that touches both, which number governs and on what turnaround. This is close to the work we do directly in consulting engagements with product and risk teams that have been trading leverage for a year: writing the category rule and the loss-tolerance number once, so the roadmap stops swinging between the two functions that both, correctly, believe they are right.