Do You Really Understand What Your Employees Need? This Framework Can Help

If you have customers, then you understand the importance of great service. It’s the difference between whether they choose to buy your product or your competitor’s. But what if your “customers” are fellow employees?

For strategy and operations teams, like Salesforce’s DesignOps team, the primary customer is the employee. If an employee has a negative experience, it might affect their ability to do their work and trigger a cascade of issues for their team and, ultimately, the bottom line. That’s not ideal. But the Jobs to be Done Framework (JBTD) can be just the business tool that helps you deeply understand and wow your internal customers. I’ll tell you how.

What is the Jobs to Be Done Framework?

The Jobs to be Done (JTBD) Framework is a simple theory that people buy or hire products and services to get a specific job done. This methodology is typically used to innovate how products match their market, by better aligning to the jobs and outcomes customers “hire” those products to accomplish. It’s improved everything from market segmentation tools to milkshakes, so why limit this framework to just products?

At Salesforce, our DesignOps team builds the processes, programs, and guardrails to (hopefully) help our design org succeed. But we don’t want to just hope – we want to know. We asked: “If Salesforce Design is an org of job performers, what are their Jobs to Be Done? Given the chance to rehire us to help them accomplish their jobs, would they choose us again?”

The journey to uncovering these answers forced us to move upstream in our business and think holistically about how the design org works every day. More importantly, the outcome of this work has redefined our DesignOps V2MOM methods, reprioritizing and reshaping our existing work.

Here’s how we did it.

Step 1: Identify your org’s job performers

We first workshopped which groups have “hired” DesignOps to do something for them. Then, we compiled a large list of roles, personas, and individuals we’ve worked with regularly. We clustered these people into discrete categories of job performers: groups that were deemed to share similar jobs and outcomes. Ultimately, we landed on the following six job performer categories, coded with emojis:

⭐ Design individual contributors

🌟 Design managers

❤️ Design executive leadership

🛠️ Design development partners

🎯 Design business partners

🌐 Designer ecosystem

When applying the JTBD Framework to your internal org, the outcome of this step should be a well-defined set of job performer categories to share with your employees, such that everyone you work with can unambiguously point to a group and say, “Yup – that’s me!”

Step 2: Research employee jobs to be done

Next, we did some customer research with our job performers to better understand what jobs they did regularly, and what outcomes they were seeking. We used surveys, interviews, and a lot of prior knowledge. For each job performer category, we wanted to understand:

• The when: the circumstances that triggered their jobs.
• The what: the social and emotional motivations surrounding their jobs.
• The why: the outcomes to be achieved by doing their jobs.

Remember not to insert your own current jobs into the conversation. For example, we couldn’t ask about the processes or programs our DesignOps team already creates – those are our solutions to what we think our customers need. Instead, have a conversation about your customers’ work in a world in which they (hypothetically) haven’t hired you.

Step 3: Synthesize your findings

To make sense of the information we’d gathered and to be able classify and find patterns among our job performers, we simplified and standardized the responses. Here’s an example of a job one person reported:

“When I onboard to a new project, I want to get an overview of the past design and research over 6-12 and 18-24 month periods, so I can gain knowledge of how prior design decisions and explorations have influenced the current work.”

Phew. How about “access domain knowledge” instead? Simplifying responses made it easier to group similar jobs and identify the most common jobs and outcomes. We standardized responses using the “verb + object (+ clarifier)” format, which is common in the JTBD Framework. When using this technique, it’s important to define the job the performer is trying to do, not the process they are currently doing. Another recommendation is to phrase the job in “timeless language,” not in terms of modern solutions or tools.

After synthesizing and standardizing our results, some patterns and insights emerged. One such discovery was the following six “job themes” that are common to all our job performers in Salesforce Design:

• Build Beneficial Connections
• Develop Skills for Continuous Growth
• Understand Salesforce Inside and Out
• Deliver Great Customer Experiences
• Share and Communicate with Courage
• Nurture and Access a Diverse Talent Pool

Step 4: Define main jobs & job tasks

Next was to define our customers’ main jobs, and distinguish those from their job tasks. One way to understand the difference is this: if some customers say they want to “boil water,” and some say they want to “prepare a hot beverage to drink,” which is the main job, and which is an underlying job task? Both are important to understand, but if your strategy and operations teams focus too much on the tasks, they risk not innovating on the more critical customer jobs.

Because we had simplified and standardized our customers’ responses, defining main jobs and underlying job tasks was relatively easy. (More so, because Salesforce’s DesignOps isn’t just integrated with the Design org – we also follow design methods and principles in our work.) We did this for each job performer separately. For example, here are some of the main jobs we defined for the design manager category:

• Deliver design strategies
• Foster team connections
• Access organizational knowledge
• Amplify my team’s voice

Within each of those main jobs, we defined underlying job tasks. As an example, here are some job tasks for the “Deliver Design Strategies” main job:

• Educate my product stakeholders on our design processes
• Staff design priorities according to V2MOM needs
• Establish collaboration frameworks between designers and developers

Step 5: Define measurable outcomes for each job task

To connect these insights back to your strategy and operations team, you’ll need to complete the final step of the JTBD Framework: defining measurable outcomes. These are the outcomes your job performers seek to achieve – the reasons these jobs must get done in the first place. To assure you’re meeting your customers’ needs, you need to define these outcomes in measurable language. We chose to use the “direction + metric + output” format to define our outcomes, and applied this rubric to each job task:

• The Output is the thing changed by the job task.
• The Metric is the object you actually observe and measure.
• The Direction is the change that metric takes when the outcome is successful.

It sounds confusing, but it’s simple in practice. Here are outcome definitions for some of our design manager’s job tasks:

This example articulates what your customers want to do and their motivations. Defining the outcomes in measurable language helps minimize one-off or out-of-context solutions. Also, your team will be able to meaningfully change the metrics that matter most to your job performers and their outcomes.

Impact of embracing the JTBD Framework

The purpose of this work was to assure that our team was prioritizing, improving, and delivering the right solutions for our customers. Our job performers loved seeing themselves (and their outcomes) described through an operational lens, and they developed an increased confidence in how and why we do our work for the design org. For our DesignOps team itself, the impact was even greater. This process:

• Advanced DesignOps’ relationship with its customers. Our job performers see themselves in our V2MOM, and understand what jobs they’re “hiring” us to do. In turn, our program managers have a framework to ask our customers the right questions to prioritize and deliver on their needs.
• Uncovered new opportunities. We (and our customers) are familiar with what DesignOps does today, but we uncovered new jobs for which our customers would hire us. It also gave us a framework to say “yes” to high-value jobs, and “no” to tasks that weren’t providing similar impact.
• Improved how we measure our impact. By defining our customers outputs and metrics in measurable language, we have more tangible ways to demonstrate DesignOps’ value to our org.

If your company’s employees are your primary customers, using the Jobs to be Done framework is a great way to meet their needs and deliver on the outcomes that matter most to them.