Teams that skip job analysis build systems that are coherent internally but incoherent from the user’s perspective. The features make sense given each other. They do not make sense given the user’s actual goal. This is the most common form of product-architecture misalignment: technically correct, user-irrelevant.
A related failure is job substitution. The team identifies a job, designs a system to serve it, ships the system, and then gradually adds features that serve a different job. Over time, the system serves neither job well. The architecture was designed for “write faster” and feature requests have added “remember my preferences,” “suggest sources,” and “track my progress.” Each feature is small. Together, they change the job the system is serving without changing the architecture to match.
Concept: Users hire products to do a job. The job — not the feature — is the correct unit of analysis for architecture decisions.
Thread: T10 (Abstraction) ← jobs abstract user intent away from system implementation → APIs and systems that model jobs are more durable than ones that model implementation
Core Idea: The same product category produces radically different architectures when the underlying jobs are different. Designing to the job produces systems that remain coherent as the product grows.
Tradeoff: AT6 (Flexibility vs Simplicity) — a job-oriented design adds scope and complexity upfront in exchange for architectural coherence as the product evolves
Failure Mode: FM12 (Architectural Rigidity) — a system designed for one job becomes rigid when feature accretion changes the actual job being served without changing the architecture
Signal: When users consistently use a feature in a way that was not its intended purpose, the system was designed for the wrong job
Maps to: Reference Book, Framework 1 (Mental Models)