18 Top Sales Influencers You Should Follow in 2023
10 min read
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.
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.
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!”
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:
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.
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:
10 min read
5 min read
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:
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:
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:
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.
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:
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.
Get the latest articles in your inbox.