Informed by 100+ user interviews, I led 8 internal workshops to reconnect the team to our mission of helping chronic disease patients and to reincorporate user needs into the product development process. The end results included company-level training for new hires and documentation for enterprise partners.
Mango Health is a digital therapeutics company with the mission to help people better manage their chronic conditions. This mission was a large reason why I – and many others – joined the team at an early stage.
I started as a Community Manager in 2014, when we were a team of 8 people. (The company was beginning to hire more heavily, after having raised a $5.25 million Series A round of funding from Kleiner Perkins Caufield Byers.) Over time, I became the primary advocate for our users, moving into a role more focused on user experience strategy.
Fast forward to 2 years later, and the digital health investing climate had changed. The company was in the midst of raising a Series B round of funding, and as a result, was shifting strategy to focus on monetization via partner needs rather than those of patients. There was also an exodus of employees in the summer of 2016 – including the first employee – and morale was low. Thus, our main challenges were:
1. How might we reconnect the team to our mission?
2. How might we reincorporate user needs into our product development process?
process: How might we reconnect the team to our mission?
Compelling user stories.
Throughout my 3+ years at Mango Health, I had the privilege of interviewing over 100 users. I began interviewing people as mostly a form of content generation – a way to generate “user testimonials” to share with partners and our community. However, interviewing became my favorite part of my job, and ultimately why I moved into user experience: hearing our chronic disease stories reminded me of why our mission was so important, and their gratitude for our work became the reason why I came to work every day.
While these stories were shared both internally and externally, I knew that many team members – stretched thin, as most startup employees are – didn’t necessarily make time to read them. As the team member with the most interactions with end users, I hypothesized that creating the chance for team members to connect with these stories would help them reconnect to our mission.
The “Jobs To Be Done” framework.
I was enthused to discover the Jobs To Be Done framework at an industry event in late 2016. Developed by Clayton Christensen and Bob Moesta, Jobs To Be Done conceives of products and services as doing different “jobs” for people by meeting their functional and emotional needs. The framework was increasingly gaining traction among the UX community, and I felt it was a metaphor that could be easily understood by our team.
During my interviews, I had been struck by the diversity among the different types of users – from a 60-year-old poet living with multiple sclerosis to a 20-year-old sales clerk living with undetectable HIV. I felt strongly that the demographic and lifestyle attributes we were using to segment users at the time didn’t accurately capture this diversity, but that Jobs To Be Done did. It also framed our work in a way that encouraged greater empathy.
Despite having a fairly shallow knowledge of the framework myself, my manager encouraged me to introduce Jobs To Be Done to the rest of the team. So I did over a lunchtime presentation, drawing much of the material from a workshop I had attended at Udemy.
After reviewing a case study, we ventured to do some synthesis with our own user profiles. I handed out a selection of interview transcripts from 8 diverse users, and small groups identified spectra of differences, placing users on each. I was surprised by the range of responses, though admittedly the participants included a wide spectrum of perspectives: iOS, Android, and backend engineers, as well as people from product, design, and operations teams.
To wrap up, each group presented their spectra, and we came back together to identify repeated themes. We prioritized the top two team-identified affinities (“just diagnosed” vs. “long-time patient”, “proactive” vs. “reactive”) as axes to demarcate our four different jobs.
PROCESs: How might we incorporate user needs into our product development process?
Ongoing empathy workshops.
Following the initial Jobs To Be Done presentation, I was pleased to discover that there was much follow-up interest across various departments. So I continued to schedule additional workshops, weekly or bi-weekly.
We started first with a "writing derby", where we took turns writing from each job's point of view within 5-minute blocks, then meticulously editing until we could all agree on one statement for each job. In follow-up workshops, we further immersed ourselves in each job by considering their context, demand drivers, needs, and what they considered to be “fireable” offenses (or why they might stop using our product).
My goal had been to help people understand the nuances of each user’s mentality, but I often found myself mediating heated debates – many dragged on for far longer than I expected, becoming an opportunity for team members to air out already existing tensions. Case in point: it took us an hour to collectively write just 4 sentences! After a few hour-long workshops of aligning on each mindset, however, we did at last end up establishing a consensus.
We next considered how we might best service both functional and emotional needs to "get the job done" for each mindset. While generating potential new features, we also considered which might satisfy needs of the business, as these areas could be of strategic priority.
To synthesize our ideas, we created an affinity map and found that some potential features accommodated more than one job. For instance, all jobs had functional needs of recording medical moments, tracking appointments, and providing resources. These also tied in with emotional needs to feel a sense of relief and confidence in disease management. Our workshops concluded with one last session of sketching these features we identified as top priority.
Though the features we sketched didn't make it immediately onto the product roadmap, the Jobs To Be Done framework itself – lovingly but laboriously created with consensus – became embedded in company-level documentation, such as brand guidelines, UX writing style guide, etc.
These documents have been handed off to various enterprise partners, including Express Scripts, a Fortune 100 company that became a Series B investor shortly after this process. The initial Jobs To Be Done presentation is now also a part of the onboarding schedule for new hires, and user research is better incorporated within the product development process – all resulting in a stronger company culture of valuing human-centered design.
I was surprised most by the project's impact: I had planned on just an hour-long lunchtime discussion, but it ended up extending over a few months. This meant that I often felt like the improvising instructor who learns curriculum right before teaching her students – I had only been to the one facilitation workshop at Udemy, so I frequently found myself learning just enough myself before leading each workshop.
I’m glad I took the risk, however. I learned the necessity of negotiating among different perspectives to reach consensus, and the need to be adaptable to truly see change come to fruition. Most of all, I’m proud that my commitment to the cause enabled people at varying levels of the organization to feel connected to our users, let it shape their decisions, and ultimately remind them that they were doing meaningful work.