Many different customers want many different features, causing difficulty when prioritizing the product roadmap. Our core goal is to identify product issues many users are having, but which they are not able to articulate.
In this project I use Jobs To Be Done (JTBD) to identify specific competitors to my product, identify features of those competitors, and design one feature.
The hardest part of this project was the short amount of time with each of the users. Fortunately we scheduled follow up time to clarify any questions from interviews and ensure we understood what we thought was being communicated.
I designed research plan, created scripts, interviewed primary stakeholders and subject matter experts, socialized findings, and designed features.
Prakash was an advisor, liaison to users and subject matter experts, and assisted with recruiting participants.
Andrew provided feedback on specific questions, high level project advice, and feature design oversight.
After I had a good grasp of the concepts I began scheduling interviews and putting together an interview script. The script in this project was the key differentiator from my other research projects.
Normally interviewing focuses around understanding if a tool is successful or not at helping a user at accomplishing tasks. This approach to interviewing typically places the tool at the center of the discussion.
The script for this project was different.
I focused this script on what users did when they were NOT using our tool but were still engaged in core tasks. This helped us understand the Jobs other tools were hired to fill.
We flew, rented cars, stayed in hotels, and visited client sites. I interviewed participants, analyzed the results of the interviews, and identified feature opportunities. I followed up with a few of the participants to clarify my interpretation of our conversation.
For example, one user printed alignments out on paper, and for very specific reasons. I asked her many questions about the paper, much to her surprise, as she felt printouts were a very mundane (but important) part of the work.
These experts were experts in the alignment, compensation, and had experience with many different types of users. I used a modified Business Model Canvas to identify the different User Goals, Business Goals, Tasks & Scenarios, Strategy, and Team required for JAMS work.
Once we’d discussed the high level business processes, I discussed the features with the SMEs, asking questions about how the features might (or might not) work for most users and the edge cases. Armed with additional insight I worked on fleshing out the feature opportunities and contextualizing them within the business processes.
We worked through each feature individually, discussed how they overlapped with other features and might otherwise impact the product, and arrived at rough solutions for how to tackle the designs.
From here I began exploring how to lay out specific elements on the screen and putting down rough sketches for the tool. I presented the sketches and feature explanation to the team for advice, which I incorporated into wireframes.
My users are the people who interact with JAMS on a day-to-day basis to align sales territories and compensation budgets. They are highly skilled at using JAMS for internal business processes.
2 client sites visited
8 users interviewed
4 feature recommendations
1 complete feature design
This project went really well and gave me a new appreciation for the Jobs To Be Done approach to thinking. JTBD is very useful for understanding the gaps in a product and can really be helpful. Next step? Usability testing.
If I were to do this project again I would spend time making a Mental Model or Journey Map. It was unnecessary due to close involvement of my stakeholders, but in retrospect I really wish I had made both as they would have helped keep all stakeholders on the same page when discussing various parts of a very complex journey.
And they would’ve looked cool in this portfolio piece!