Workforce Jobs-to-Be-Done Survey
Take a humble tea kettle. What does someone hire a kettle to do? Gut reaction would state the end result: make a great cup of earl gray. But then cider and hot chocolate would get left out. It’s the same with really great jobs-to-be-done statements. They can neither be too narrow to focus only on how the product functions (boil water) nor too broad in focusing on the end result (hot cup of tea) because that result might be different for different users.
Here’s a great, fantastic JTBD statement: “Increase my ability to socialize with my friends during Corona virus.” It combines the direction of improvement (increase) + the metric (my ability) + the object of control (to socialize) + contextual modifiers (with friends during Corona). It’s also not assumptive. A bad JTBD statement like, “Video conference with friends” is an end result, a feature for a product, but it wouldn’t help inform a product roadmap or get at the true goal of a user.
In using the JTBD framework for our workforce survey, our goal was to identify user goals and motivations. We did this by assessing the importance of each “job” statement and the satisfaction in being able to perform each job well. Our movers and drivers would rank on a scale of 1-10 how important this goal was to them and how satisfied in the moment they were in being able to achieve this goal.
Low satisfaction + high importance = an opportunity. We had 32 JTBD statements and 138 responses. When mapping out responses, we were looking for that sweet spot, bottom right corner, where low satisfaction and high importance met.
We could then present recommendations for the team on what to focus on in future product initiatives—where our workforce is most underserved and least underserved. We asked the team for hypotheses based on why these might be important to our workforce yet low in satisfaction.
Through a group brainstorm, we were able to label the “most underserved” category as typically items that are outside of our mover’s and driver’s control. Meaning, we use auto-assignment for jobs, so our movers and drivers don’t have much control over the type of job they’re assigned to. This could potentially put them into a job that’s too short and seemingly not worth their time.
Tax filing was a surprising finding. We haven’t made it easy for our workforce, especially our movers, to file for taxes. This is something Uber and Lyft do well—they estimate the amount for their contract workers. While not on the product roadmap, this gave us the idea to pursue the further study of adding tax filing to the platform.
The least “underserved” category was then labelled as items within their control. Our workforce is able to clock in/out of jobs etc. By providing these labels, the team could then focus on adding items to our roadmap which provide more controls for our workforce.
We were then able to segment the data by role—> lead, bellhop, driver, carrier, owner-operator. We also segmented by NPS—> promotor, detractor, neutral. Third, we segmented by tenure—> fewer than 6 months, 6-1 year, 1-2 years, 2+ years. Last, we segmented by location—> region, state, city, and large metro area. We analyzed these results next to our general population results, and we were able to come up with even more recommendations.
For example, not surprisingly, our leads are more attached to non-monetary rewards “swag” than less-tenured movers. This would suggest that they have more pride in the company and could be more motivated by swag.
They also care a great deal about notifications. Are we bombarding them with notifications? Probably.
A few things I’ve learned from this survey methodology:
It’s better than interviews for initial discovery purposes. Often interviews focus too much on features. This gets at user goals in a quantitative way that I’ve never explored before. My pivot table game is still not strong, however.
Define the survey carefully. In the future, I would either lower the amount of questions (20 max) or increase the incentive to get more responses. I also would’ve loved to randomize the outcome statements. For some reason, this wasn’t available on Typeform.
In summary, a JTBD approach gave us fuel for our product roadmap. It didn’t, however, tell us “how” to give our workforce more control. To identify the right solution, that would require more in-depth interviews and comparative prototypes.