A "special" is a one-off feature built to close a specific sales deal, without a validated broader customer problem behind it — the internal term Chris Jones (SVPG) uses for the "this deal can't close without X" request pattern in B2B.
The recommended first move is identical to any other feature request under Customer Requests as Clues, Not Specs: probe rather than commit — "I want to make sure we succeed when we do it," asking what problem the feature solves and how success will be measured. Sometimes that probing reveals the underlying "why" doesn't hold up well, and sometimes the reason is "really dumb" but the deal is still worth winning anyway — closing the deal is treated as a legitimate business outcome, not automatically a product failure.
Because a special has no validated demand beyond one account, its governance is deliberately tight:
Balance framework: product can't be "purist" and pretend revenue doesn't matter — winning deals is a legitimate business outcome. But sales can't treat deal-closing as the only metric either, or the product accumulates into an unmaintainable "Frankenstein" that closes deals but doesn't retain customers. Specials are the release valve that lets both pressures coexist without either one overrunning the other; see Product Model (vs. Roadmap Model) for the broader operating model this sits inside.
Building a 'special' — a feature for a single customer/deal without a validated broader problem behind it — requires high-bar escalation approval; it is not a decision a single salesperson can make unilaterally. An internal quota caps how many specials are allowed at any time.
Rationale, stated directly: unchecked specials produce "a Frankenstein of a product that's unmaintainable and doesn't actually deliver value." The quota is a safety valve — acknowledging deal pressure exists without letting it drive the roadmap unchecked.
When sales or a customer insists a feature is required to close a deal, respond with: "I want to make sure we succeed when we do it." Before committing to build, ask what problem the feature solves, how it helps the customer, and how success will be measured.
This reframes an urgency-driven yes/no decision into a scoping conversation, without flatly refusing the request. Complements Customer Requests as Clues, Not Specs.
Из тем: The Product Operating Model