Jobs-to-be-Done for System Architects

Most system architects make a fundamental error in their first decision. They start with technology.

"We need a message queue." "We should use PostgreSQL." "Let's add a caching layer." These statements feel like architecture decisions, but they're actually technology selections masquerading as strategy. The architecture decision — the one that actually matters — happens before you ever think about technology.

The architecture decision is: what job is this system being hired to do?

Jobs-to-be-Done theory, pioneered by Clayton Christensen and refined by Tony Ulwick into Outcome-Driven Innovation, was designed for product strategy. The core insight is elegant: customers don't buy products, they hire them to get a job done. A drill isn't purchased because someone wants a drill — it's hired because someone wants a hole.

This framing transforms product decisions. Instead of asking "what features should we build?" you ask "what job is the customer trying to get done, and how can we help them do it better?"

I've spent the last several years applying this same framing to system architecture, and the results have been transformative.

Every system — every service, every database, every API — is hired by someone to do a job. The "customer" might be an end user, another service, a data pipeline, or an operations team. But the framing is the same.

Consider a notification system. The typical architect starts with technology: "We need a pub/sub system, probably Kafka or RabbitMQ, with a delivery service that supports email, SMS, and push notifications."

The JTBD architect starts differently: "Who hires the notification system, and what job do they need done?"

The answer reveals complexity that the technology-first approach misses:

• End users hire notifications to stay informed without having to check the application
• Product teams hire notifications to re-engage users at critical moments in their journey
• Operations teams hire notifications to alert them when systems need attention
• Compliance hires notifications to maintain audit trails of important communications

Each of these jobs has different success criteria. The end user cares about relevance and timing. The product team cares about engagement metrics. Operations cares about reliability and latency. Compliance cares about completeness and immutability.

A single pub/sub system might serve all four jobs technically, but it won't serve any of them well unless the architecture explicitly accounts for each job's desired outcomes.

In ODI, every job has desired outcomes — measurable statements of what success looks like. "Minimize the time it takes to understand what action is needed" is a desired outcome for the end user's notification job.

These outcomes become architecture requirements that are far more useful than traditional non-functional requirements:

| Traditional NFR | JTBD Desired Outcome | |---|---| | "Response time < 200ms" | "Minimize the time between event and notification delivery" | | "99.9% uptime" | "Minimize the likelihood that a critical notification is lost" | | "Support 10K messages/sec" | "Minimize the time it takes to notify all affected users of a system-wide event" |

The difference is subtle but crucial. NFRs are constraints. Desired outcomes are objectives. Constraints tell you what you can't do. Objectives tell you what you should optimize for. And optimization drives architectural innovation in a way that constraints never can.

Here's the practical framework I use:

Step 1: Identify the jobs. List every stakeholder that will "hire" this system. Include internal teams, other services, and end users.

Step 2: Map desired outcomes. For each job, list the outcomes that determine success. Use the ODI format: [direction] + [metric] + [object of control].

Step 3: Rank by importance and satisfaction. Which outcomes are most important? Which are currently underserved? The gap between importance and satisfaction is your opportunity space.

Step 4: Design for the top opportunities. Your architecture should explicitly optimize for the top 3-5 underserved outcomes. Every design decision should be traceable to an outcome.

Step 5: Validate with outcome metrics. Don't measure your system with traditional metrics alone. Measure the outcomes it was designed to deliver.

Systems designed with JTBD framing share a common characteristic: they feel inevitable. When you explain the architecture to stakeholders, they nod. Not because it's simple — sometimes it's quite complex — but because every decision has a clear rationale that connects to something they care about.

That's the power of starting with jobs instead of technology. You build systems that serve their purpose with clarity and precision, rather than systems that use interesting technology for its own sake.

The drill analogy works for architecture too. Nobody hires a microservice architecture. They hire an ability to deploy independently, scale selectively, and evolve incrementally. If a well-structured monolith delivers those outcomes better, that's the better architecture.

The job is the job. The technology is just the tool.