OSFA-as-default
OSFA-as-default is what happens when a team builds its product as one main shared experience that every user goes through, and treats any tailored versions for specific user intents as features layered on top rather than as the primary work. The shared experience ends up carrying the bulk of what users encounter. The pattern typically traces to thinking about the product as a single artifact, one thing to design and improve, rather than as a collection of intent-specific experiences; team-capacity and code constraints reinforce it but aren't its root cause.
Definition
The implementation reality where OSFA carries the bulk of the user experience and intent-specific paths are added as augmentation layers, typically produced when offering-as-object thinking dominates a team's commitments.
Offering-as-object as root cause
Under offering-as-object thinking, the team treats the offering as one artifact to be built and shipped. The natural design output is a single shared experience that handles all users. When intent-specific work appears, it shows up as features layered onto the single experience — copy variants, conditional checklists, optional flows — rather than as separately-shaped paths. The artifact is the unit of work; paths are decorations on the artifact.
Team-capacity and code-architecture constraints reinforce the pattern but aren't its root cause. Teams committed to offering-as-paths prioritize routing and per-intent paths even with limited resources; teams committed to offering-as-object continue producing OSFA-as-default even when given more.
Paths as augmentation layers
OSFA-as-default is characterized by inversion of which mechanism does the primary work. OSFA runs the bulk of the user experience — the default flow, the default templates, the default settings. Paths, where they exist, sit on top as augmentation: a different headline for a different acquisition source, a checklist branch for one user segment, an intent-specific email sequence layered over the same product experience.
The contrast with OSFA-as-fallback is the inverse role assignment. Under OSFA-as-fallback, paths carry the bulk of the user experience and OSFA fills specific structural functions (routing failures, recovery, error/reset states, common landscape vocabulary). Under OSFA-as-default, OSFA carries the bulk and paths layer on as augmentation. Tail vs. dog.
Multi-intent OSFA
The typical industry implementation runs one step further from the framework's commitment by stuffing multiple intents into one OSFA experience. Rather than building OSFA as one coherent default for the population it actually serves, teams build OSFA to nominally accommodate every theorized intent — onboarding flows that try to introduce four use cases in one sequence, dashboards displaying widgets relevant to every persona, help content written to address every question any user might have. The result is an OSFA that serves no intent well because it's optimizing to serve every intent at once.
Posture upstream of tooling
As routing infrastructure, content systems, and AI-driven personalization improve, the cost of executing OSFA-as-fallback drops. Posture remains the constraint. Better tools deployed under offering-as-object thinking produce more sophisticated OSFA-as-default — the same artifact-centric work, with augmentation layers now more elaborate. Realizing the structural commitment requires the offering-shaping move, which sits upstream of any tooling.
Example
A project management tool where signup asks "what are you using this for?" with options for personal todos, agency client work, engineering sprint planning, and event organizing. The data lands in analytics; the resulting product experience is the same default project view with the same starter templates for every user. The intent detection is in place; no paths have been built behind any of its branches. Every user lands in OSFA regardless of how they answered. The team has collected intent data and committed to one artifact.