GitHub’s pull request model was designed around the job “coordinate code changes across a team.” The job is not “upload a diff.” The difference matters architecturally. Uploading a diff requires storage and retrieval. Coordinating changes requires status tracking, notification infrastructure, review state machines, merge conflict detection, and CI/CD integration hooks. Each of these is a separate system. The job definition determined the scope.
Dropbox solved the job “access my files from anywhere without thinking about it.” The key phrase is “without thinking about it.” Users do not want to manage sync. They want sync to happen. The architectural consequence is that the sync engine must be invisible: it must handle conflicts silently, recover from interrupted syncs, and never require the user to make a decision about file state. An architectural choice that exposes sync conflicts to users as a decision they must make fails the job, even if it is technically correct.
Stripe solved the job “accept payments without becoming a payments company.” The job has a strong negative component — “without becoming” — which means the architecture must hide complexity, not expose it. Every API decision that forces the integrating developer to understand payment rails, fraud models, or compliance requirements is an architectural failure relative to the job.