Jobs-based business strategy: business language
As digital products grow in complexity, there comes a need for a businesses to start dividing up responsibility across cross-functional teams. These divisions of responsibility, while necessary, usually end up creating communication barriers in the organization (Edmondson, 2012), better known as “silos”.
Within each of those teams are cross-disciplinary members, each bring their individual beliefs, attitudes, and assumptions to the conversations they are a part of. This is where collaboration gets messy and were team communication sometimes takes a hit.
In the end, there are breakdowns in communication not only across teams, but in the teams themselves. (Edmondson, 2012)
Conway’s Law states that,
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. (Conway, 1968)
That is to say, if teams and individuals are not speaking with each other, the product might feel like it has a lack of focus and consistency. This realization is what drove me to think deeply about how we communicate with each other at work, and how important it is to create a communication stack.
The communication stack
A communication stack is a shared language that an organization uses to get things done. These terms and phrases are shared and repeated constantly by the organization. What this typically looks like in an organization is a vision, strategy, objectives, key results, epics, and principles. Most organizations have at least a few of these, and if they don’t it is very likely that they will struggle with many of the decision-making conversations that they have. However, the one thing that this stack is missing is the human element and the jobs that this human is trying to get done in our product.
The job to be done (JTBD)
Jim Kalbach (2020) defines a JTBD as “The process of reaching objectives under given circumstances”. That is to say, the customers of your product have decided to choose your product because they believe that it will help them get their job done better than the alternative. A job has nothing to do with products or features, but rather the progress that the human is trying to make regardless of solution (Kalbach, 2020). This level of abstraction is not only a pivot from being product-centered to human-centered but is also quite stable over time. While your features and processes might change drastically in your product, the job and the outcomes your customer seeks tend to withstand innovation and competition. For example, if my job is to get to the airport for my flight, then regardless if I chose to walk, take a train, hail a cab, or call an Uber, in the end the outcome I want is to get to the airport on time for my flight. Depending on the circumstances of when I need this job done, any one of those might complete the job better than the others.
Jobs as a business language
The interesting thing about jobs is that they are hierarchical, meaning jobs span from the aspirational like “make the world a better place” to micro, like “unscrew my toothpaste”. Regardless of which zoom level you choose, the human will have some sort of outcome they desire.
At Macmillan Learning we’ve been using jobs as a foundational language helping us communicate across boundaries. With the help of some extremely brilliant colleagues, it has caught on and become an integral way in which we communicate about the work that we do. Below I will highlight some of what we’ve accomplished and where I’d love to explore in the future.
Aligning on desired outcomes
When thinking about progress, there is immediately an element of measurement that is introduced. Thinking and aligning on this before starting to design anything is extremely advantageous for the team, and will help reduce friction that most commonly happens downstream when there are multiple communication boundaries at play. This friction risks that people on the team feel excluded from the conversation, creating an environment where some people on the team turn to silence due to the perception that their voice will not have an opportunity to make an impact on the success or failure of the team. This is what is called psychological safety and according to Google Project Aristotle (Re:work), one of the most important indicators of high-performing teams. At Macmillan, jobs, desired outcomes, and what parts of the job map are associated to those outcomes, have served as an entry point to these conversations and constructive debates at the kickoff of any project.
Learn more about Job Maps here.
Let me give you an example from education to illustrate what I mean. At Macmillan Learning we work in cross-functional groups which are typically comprised of a product owner, designer, researcher, developer, and learning scientist. While the entire team is accountable for the success of the initiative, each person has the strength that enables their team the ability to succeed. They also each bring their own knowledge, intentions, and concerns to the project from their discipline’s perspective. These are what I’d call external outcomes, or outcomes that are important from the team’s perspective, external to the human. The reality is that when looking for a product, a customer is likely not interested about your retention percentage, nor your key result of increasing performance by 10%. All they care about are the outcomes that impact their lives such as reducing the time required to complete the job by 25%, or being perceived as being highly skilled at the job they are doing by their department so they are in a good position to get that raise next year. In education, and likely many other areas, internal and external outcomes bring their own tensions. Let’s take the following example when thinking about the job of evaluating content to add to your course.
There are 4 outcomes listed above, each from a different perspective across internal (the human) and external (the business & learning science). Furthermore, if you think back at our cross-disciplinary team, while the team as whole will be accountable for all of these, each member’s specialty is highly correlated to specific lenses of outcomes. Let’s take “Reduce time it takes to design my course”, the success of this hinges on the ability of the UX researcher to uncover what is taking so much time and the designer to suggest a more efficient alternate solution. While that makes good sense, the business and learning scientists found that instructors that make full use of our content in a specific way, not only have students that get better grades, but those instructors are more likely to repurchase the product the following year. This also makes good sense. This creates tension from the user perspective and business perspective, since in essence adding more content than what the instructor was originally planning to add can, and likely will, require more work and time from their own lives. This work however can be desirable by the instructor, if they determine that the rewards outweigh the added effort.
Ideally, being able to uncover these tension early allow for conversations to happen amongst team members, helping feed into a higher-level strategy that everyone understands. Designers are then able to design around these tensions, or better yet, uncover behavioral design patterns that encourage instructors to experiment with different type of content and instructional frameworks by reducing friction and increasing motivation.
Organization of data
Data is great…until it isn’t. Getting constant feedback from your customers is crucial to the success of your organization. Feedback contains glimpses of the pain your customer if feeling, those pains turn into themes, and those themes turn into initiatives. As the data increase from 10, 100, 1000 and more pieces of feedback per day, it starts to drown your organization making it difficult to make any sense of.
Just like any library, when you are faced with a lot of data it requires an organizational structure in order to make sense of it. Jobs fit really nicely since it is based around outcomes at its core. That is to say, you could point to any job step and start to gauge how well it is doing in terms of your customers’ satisfaction, ease of use, and a variety of other signal that make sense for that specific job.
Something that Macmillan has been experimenting with is in-application surveys using a mixture of both quantitative and qualitative measures.
This is really nice because, since JTBD is based around the notion of the progress a person wants to make, we could now quantify that in a variety of means. As an example you might think about triangulating any given job into 3 lenses: how easy was it to accomplish (SEQ), if the functionality met the customer need (UMUX-Lite), and most importantly, what I call the Metric that Matters. This is a UX measure that you feel best signals the behaviors that you are looking to monitor for any given job. Regardless of what you decide to measure, or how you measure it, the key-value around using jobs is that we have now expanded the exposure to the shared language into measurement, thereby helping team internalize this job-based language.
Once you have health measurements mapped to a job or collection of jobs, it makes it really easy to being to infer what parts of your job flows are not performing as well as anticipated, creating more awareness of your product’s strengths and weaknesses.
All of our teams have taken this opportunity to create some fantastic dashboards to monitor the in-application quantitative and qualitative responses. One in particular, mapped a distribution of SEQ onto a bar chart and correlated those to the responses that people gave in the free response area. By allowing the person that is investigating the thematic issues resulting in the odd distribution we were able to deduce what issues were effecting a very specific, yet large and growing segment.
Scaling JTBD across your organization
Having highly organized portions of your product that you are consistently monitoring naturally make way for expanding that organizational strategy to other parts of the system and company as a whole. In a recent article, Jeff Gothelf, a well-known voice in lean and agile product development, makes a case for striving to get OKRs and JTBD to work harmoniously together.
Jobs To Be Done helps teams understand why a certain behavior is taking place and how current products are being perceived against other options available to the customer to achieve a goal. Objectives and Key Results provide the framework to determine whether or not the product strategy that emerges from that research is correct and whether the products we continue to provide the market achieve that strategy.
Another way of thinking about scaling your JTBD language is in your roadmap. There are typically a lot of items that product owners pack into their roadmap, and each one comes up with their own method of organizing it. While that is fine for many, JTBD offers a default organizational structure that maps 1-to-1 for much of the monitoring that they are already doing in order to make decision on what to work on next cycle. So for example, if you your roadmap looks like the image below, anyone in the organization should be able to reference the matching monitoring dashboard and understand the rational of why certain initiatives were prioritized over others. This has the potential of greatly increasing the accessibly of data across the organization.
If there is a discrepancy it might be because there are some strategic drivers that are pushing the product owner to go against the main themes which is completely fine. Regardless of what a product owner chooses to prioritize there is a very concrete artifact that help people outside of their boundaries to better understand the rational that went into that decision. Increased understanding, increases trust across boundaries. Increased trust leads to easier buy-in from other departments, this is something that is sometimes lacking in many complex organizations.
Wrap up
Many organizational, especially those that consist of multi-sided boundaries, experience unproductive conflict as a result of pour alignment in the following four areas:
While I am not making the case that JTBD will solve all your problems, it most definitely will not. It can however open up an opportunity to target some of these in various ways. I will get into using JTBD as boundary objects for cross-functional team collaboration, how we might use JTBD to increase consistency across teams, and my thoughts on how you might think about innovation through a jobs-based lens.
References
Conway, Melvin E. (April 1968). “How do Committees Invent?”. Datamation. 14 (5): 28–31.
Edmondson, Amy C.. (2012) Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy. Wiley. Kindle Edition.
Kalbach, Jim. (2020) The Jobs To Be Done Playbook . Rosenfeld Media. Kindle Edition.
“Re:Work.” Google, Google, rework.withgoogle.com/print/guides/5721312655835136/.
“Simplifying the UMUX-Lite.” MeasuringU, measuringu.com/modified-umux-lite-usefulness-item/.
“Using Task Ease (SEQ) to Predict Completion Rates and Times.” MeasuringU, measuringu.com/seq-prediction/.
