In Search of Innovation: The language of jobs-to-be-done theory

One of the main reasons that people hire me is to code. The reason that I say that is because I am using the language of the “jobs-to-be-done” or JTBD theory of how to understand problems and solutions/services.

Using JTBD, you use a certain language format, and this should be the “lens” that you think through when innovating.

The format goes: product_or_service is hired to do the job of executable_task for customer_segment when they are job_context. It’s a simple concept, but I believe the language that we use to think about things matters a lot. I’ve started to apply this thinking and I personally experienced the idea to be sticky and easy to learn. So I’ll practice using this language by applying it to some software product concepts I’ve been thinking about. The actual theory of JTBD is a more involved process, but this should get the conversation started.

SoftwareSystemDynamics.com Website

( lets shorten to SSD)

The SSD experience is hired to do the job of explaining to business owners how healthy their codebase is, at a digestible summary level that they can understand and meaningfully keep track of. They may not have someone dedicated to keeping track, like an engineering manager. They may not have the cultural inclination to measure this quantity in their company.

The closest comparable would be the report/analysis workbook that you receive at your car dealership every 15,000km. That amount of driving takes over 6 months to a year, so each time it happens you need some amount of catch-up as to what the current health and maintenance of the car is.

Software development cycles can be as long as 6-months. The ceremony of code review and looking back at the software should happen on some regular basis. This ceremony might involve multiple stakeholders who need to understand and analyze the codebase health for things like technical debt and refactoring desirability.

So we’re teasing a few more jobs to be done by SSD. These help to define the jobs that customers do already, without using words like “need”, “problem” or “solution”. Those words invoke lots of baggage with fuzzy definitions (according to JTBD theory).

The SSD experience is hired to do the job of promoting a specific software development culture, which works by making the code health-check ceremonies easier to participate, contribute and understand. By using interactive and visually stimulating charts, the format is accessible and digestible.

This introduces the social dimension into the scope of the solution. According to JTBD theory, the lens should bring the social, emotional and functional dimensions into the discussion. When evaluating the same job definition but in another dimension, it must be considered a separate job. This means that a solution, which helps to execute these jobs to be done, can potentially score differently functionally rather than emotionally.

The SSD experience is hired to do the job of educating development teams and make them feel more confident and safe during their long-term decision making. This kind of job is done during a roadmap or strategy exercise.

Welcome to the emotional dimension. Customers do hire products and solutions to do the job of making them feel better about something. It happens all the time. How well does your business score in this dimension? Does the measurement even exist as part of your product strategy?

This is the power of jobs-to-be-done. It helps uncover opportunities by focusing on the tasks that are executed, instead of using loaded words like customer “needs” and customer “problems”.