OSFA-as-fallback
OSFA-as-fallback is a way of organizing a product so that the bulk of the user experience runs through tailored, intent-specific flows, with the shared one-size-fits-all experience confined to narrow structural roles. Those roles include catching users whose intent can't be pinned down well enough to send them down a tailored flow, recovering when the routing guessed wrong, handling error and reset states like 404s and "start over" buttons, and supplying a common landscape that the tailored flows stay consistent with. The shared experience still exists; it just isn't where most of the work or most of the users sit.
Definition
The structural commitment that built paths carry the bulk of the user experience and OSFA is confined to four specific functions — routing fallback, recovery from misclassified intent, error and reset states, and shared landscape vocabulary.
OSFA's four structural functions
Under OSFA-as-fallback, the offering retains OSFA for four specific functions:
- Fallback when routing points to a not-marginally-viable trajectory. The sorting hat classifies a user into a branch the offering hasn't built a path for; the user receives OSFA rather than a half-built path that doesn't pay back its investment.
- Recovery when guessed intent is wrong. Intent detection is approximate, and when the user's actual intent doesn't match what they were routed to, OSFA is what catches them.
- Error and reset states. 404s, exits, "start over" — the experience that exists when the user has stepped outside or canceled a routed flow.
- Common landscape vocabulary. The visual language, navigation, and shared elements that paths stay consistent with so the offering reads as one thing.
All four functions hold under ideal conditions, not just under implementation constraint. They're structural roles OSFA performs even when team capacity and tooling are abundant.
Paths as the primary work
Under the commitment, path-building is where the team's primary effort goes. Each path is developed iteratively through path investment — start cheap, escalate based on evidence — and gated by per-path margin-on-efficacy economics. Adding a new path and deepening an existing one are distinct margin-gated investments. The portfolio grows on evidence, and depth investment per path generally dominates path-count proliferation.
The offering-shaping move
Implementation defaults to the opposite shape: OSFA-as-default, where OSFA carries the bulk of the user experience and paths layer on as augmentations. Tooling improvements — per-user routing infrastructure, content systems, AI-driven personalization — lower the execution bar for OSFA-as-fallback over time, but the structural move still has to be made. Teams operating from offering-as-object thinking will keep producing OSFA-as-default even with better tools; the shift to OSFA-as-fallback requires committing to offering-as-paths first.
Example
A project management tool asks new users factual circumstantial questions at signup — whether their team is currently tracking deadlines, whether they're coordinating asynchronously across timezones, whether they've launched yet. The sorting hat classifies them into one of three built paths (deadline-driven small teams, async distributed teams, pre-launch teams), each with a differentiated activation flow shaped to its intent. Users whose answers don't match any of the three built paths receive the default workspace setup. The default functions as a fallback for users the offering hasn't built a path for yet; the primary onboarding work happens in the three built paths. The team's quarterly roadmap is dominated by deepening the three paths and evaluating whether a fourth warrants investment, not by improving the default.