asymmetric-wins

name

asymmetric-wins

description

Find the small product refusal that collapses a large implementation graph: refuse 10-20 percent of functionality to delete 80-90 percent of complexity. Use when the user says "asymmetric wins", "asymmetric win", "what can we refuse", "what collapses the most code", or when a design adds a fast path, fallback parser, provider-specific SDK, second transport, or compatibility alias beside a canonical path. Pairs with one-sentence-test (detects the opportunity) and cohesive-clean-breaks (executes the break).

Asymmetric Wins

An asymmetric win is a refusal that gives back more complexity than it costs in product capability. The usual shape: refuse 10-20 percent of functionality and collapse 80-90 percent of the implementation graph.

This is not arithmetic and not a quota. Do not remove arbitrary features. The job is to find the one small promise that owns a disproportionate code family, then decide whether refusing that exact promise leaves the product sentence intact.

Compose With

• one-sentence-test detects the opportunity (the surface audit surfaces the convenience feature that forces a second product sentence). This skill owns the decision.
• cohesive-clean-breaks executes the resulting breaking change, wave ordering, and old-path deletion.
• greenfield-clean-breaks and radical-options link here instead of re-deriving the refusal move.

When To Run

Run this pass when a design adds:

a fast path beside the canonical path
a provider-specific SDK wrapper beside a standard protocol
a fallback parser for an old shape
a second transport for one environment's nicer UX
a compatibility alias nobody explicitly asked for
an option that only preserves an old mental model
a partial reflection API that makes callers ask which surfaces are real

Procedure

1. Name the product sentence that must remain true.
2. List candidate refusal points: fast paths, old shapes, rare modes, provider
   exceptions, compatibility aliases, fallback parsers, partial reflection.
3. For each candidate, list the code family it forces: methods, adapters,
   unions, error variants, tests, docs branches, UI states, migrations.
4. Pick the candidate with the largest code family, not the most visible name.
5. Ask who loses what if that behavior is refused.
6. If the loss is a small convenience and the deletion removes a second shape,
   refuse the behavior and write that refusal into the spec.

The rule is deliberately pushy: if the product sentence survives and the code family disappears, default to refusal. Keep the feature only when the user loss is load-bearing.

Decision Template

Use this shape in specs and design notes:

Product sentence:
  ...

Candidate refusal:
  ...

Code family it deletes:
  ...

User loss:
  ...

Decision:
  Refuse it / keep it because ...

Worked Example: Social Sign-In

Product sentence:
  All social sign-in routes through the API-hosted page via OAuth 2.1 PKCE.

Candidate refusal:
  Browser SPAs can use Google GIS for a roughly 1-second sign-in.

Code family it deletes:
  signInWithIdToken
  OIDCProvider narrowing
  per-app GIS helpers
  GIS blocked-browser UI
  SocialSignInUnavailable
  provider-specific SDK scaling for Apple and Microsoft
  two social sign-in docs branches
  two social sign-in test paths

User loss:
  Google sign-in is a few seconds slower in browser SPAs.

Decision:
  Refuse it. The UX loss is small; the second auth shape is permanent.

The product still has social sign-in. It refuses one fast path so one invariant can own every provider and environment.

For narrative context, see docs/articles/20260504T160541-asymmetric-wins-support-fewer-features-to-collapse-complexity.md.