Our product was lacking detailed knowledge about our users and their motivations. The UX team was asked to lead an effort to create communicative artifacts about our core users, which resulted in us creating nine Jobs to be Done for our government users.
Jobs within the job:
Creation of Jobs to be Done for a government user base
The knowledge about the government end-users of our flagship product had become siloed- there were four core project teams working with different Maryland State departments, with each department having multiple agencies. Each department had their own terminology, needs and goals that translated to product solutions. What the team and company lacked was cohesion for all of the users from all of the departments.
My team set out to create unifying artifacts that would aid in providing information for who our end-users are. Our goals were to identify the core user groups of our product, foster communication & understanding across the company about our end-users and provide the company with data about end-users which will allow them to have insight into who they creating something for.
Planning
Our main method of data collection was workshops with each project team. Due to the difficulty of scheduling with our government clients, we ran these workshops with internal project team members. We ran four workshops total, each lasting 90 minutes. All workshops included the lead project manager(s), business analysts and assistants.
To get a high-level view of our clients, we had an interview session with the VP of Business Development. This session was to gather information on clients who may not use the system often, but have decision-making power and final approval of what is implemented.
The original intent for for this effort was to create personas. After completing data collection, we did not feel the information we collected would allow us to make true, data-backed personas and we pivoted to Jobs to be Done (JTBD).
Workshops
After initial planning and board creation we scheduled four workshops with the teams and ran them over the course of one week. The first part of the workshop had teams identify users for their project and create groups based on their responsibilities and system use.
.jpg)
For the second part we took those high-level groups and had participants create user goal statements. We instructed participants that these should be based on things they had learned and heard from their clients. Participants were prompted with questions throughout. Once all stickies were added we discussed the points- the discussion was recorded and used to create data points for our final analysis.
.jpg)
Pivot!
Being true to the data.
As we began to make sense of the data collected, we realized we didn't have the information needed to create data backed personas (we could create them, but probably shouldn't). What we had collected was data that focused on showing what users do not who they are. We shifted our intent to create Jobs to be Done and began analyzing the data.
Understanding the systems our users exist within
Before we began to group all the data points, we wanted to create a diagram that showed the systems in which our clients currently existed (in relation to use). We saw from our workshops that there was dissonance between the theoretical governing system, the governing system in which our contract existed and governing process system. This diagram aided us in understanding where different jobs for our client fit within these system.
.jpg)
Grouping the data
We grouped together all data points and had two categories: the high-level, overarching theme (i.e. communication) and sub-level themes (i.e. communication with outside companies). These groupings served as the basis for our JTBD creation.
Creating the JTBD Statements
Using our data, we began to create JTBD and desired outcome statements. This was done async over the course of a few days- to give feedback team members would add emojis to statements and leave comments. We met after the statements had been written to discuss how we would use them to create JTBD.
.jpg)
Finalization
- Remove social role. We did not have data to support this section.
- Remove configure opportunities. We did not have data to support this section.
- Add conflicts to the customer. We saw disputes between the wants, needs & goals of the customer
Share Out
The JTBD were presented and shared to all solutions team individually for the first cycle after their initial creation. This gave teams the opportunity to ask questions, deep dive into the data and get a better understanding of our users. A confluence page was added for the JTBD for company access. The slide deck and miro board were shared with every solution team at the start of the cycle.
The JTBD were later added to product board, the roadmap managing system for the company and became designated user segments. This allowed us to see features and user feedback based on the JTBD.
