Designing to the job rather than to the feature increases the scope of the initial system and slows early velocity. A team that builds “create, read, update, delete” for entities ships faster than a team that designs around jobs-to-be-done. The cost of the job-oriented approach is upfront. The benefit is that the system remains correct as the product grows, because the design was calibrated to user intent rather than internal convenience.
The opposing tradeoff is over-indexing on the job definition. Jobs are discovered, not invented. If the team has insufficient data about actual user behaviour, a job-oriented design is speculation formalised as architecture. The risk is designing a system to serve a job that users do not actually have, or that they have in a different form than the team assumed.