New Jobs and Jobs to Be Done

This week marks 4 months of working with FullStory.

And, next month will mark my 3 year anniversary as a FullStory customer.

Lately, I've been trying to get a better understanding of the trial experience for new FullStory users. In doing so, I've been thinking back to my first impressions of the FullStory app and how it made me better at my job.

My Experience as a FullStory Customer

The first time I saw a demo of FullStory, it wasn't a demo at all. I sat in an office at Atlanta Tech Village, hunkered around a laptop with Rigor's CTO and one of FullStory's co-founders. The presentation was a slidedeck with some simple UI mocks and an embedded video. The conversation went something likeā€¦

"Imagine if you could watch a video playback of how a user interacted with your app."

"I need this. I need this yesterday."

See, prior to having FullStory, working tech support was a bit like feeling your way through a dark room. Someone could email or chat in with a totally valid question and no relevant details:

"Why is this broken?"

"Could you tell me more about what seems broken?"

"The graph looks broken."

"Hmm. That sounds odd. Could you tell me more about what browser version you're using?"

"How do I find my browser version?"

This type of conversation could go on-and-on, back-and-forth with a customer, until eventually we'd agree to schedule a web meeting with a screenshare so that the user and I could look at the issue together. Sometimes this meant walking the user through how to install the screenshare software. Once up-and-running, if we could replicate the issue together then I would record a video, create a ticket, and pass the issue to engineering. In a best case scenario, engineering might be able to find something in the logs and move forward with a fix. But, often the case would go cold. Ticket status: could not replicate.

Some previous support tools could give me some basic context like, "Last visited URL" or "Browser type" but nothing gave me the complete context of a user's experience until FullStory.

Installing FullStory was like flipping on a light. Suddenly I could clearly see how people interacted with our SaaS app.

With FullStory integrated in my help desk, I:

  • Saved hours of time in avoided screenshare meetings, and
  • Saved hours of engineering time that would have been spent trying to emulate and replicate bugs

You can imagine the simple formula for ROI might look like:

((x support hours saved * hourly rate of support agent) + (y hours saved * hourly rate of engineer)
= $$$) - FullStory price

But, the invaluable thing about FullStory playback was how close it allowed me to be to my customer's experience. Being able to clearly see user interactions leading up to support requests amplified the understanding and empathy that I could bring to every case.

User Stories and Job Stories

Based on my positive experience with FullStory, I might make an educated guess that all people with a similar profile to me could have a similar, positive experience. I might use personas to imagine other people with profiles like mine. That persona might look like this:

Supporter Profile

And, the user stories for that persona could look like:

  • "As Suzy Supporter, I want to have context around new cases so that I can answer questions more accurately," or

  • "As Suzy Supporter, I want to replicate bugs so that I can escalate them to be fixed," or

  • "As Suzy Supporter, I want to understand the customer experience so that I can help make it better."

All of those user stories are true. But, they don't all point to FullStory as the solution. Analytics, usage logs, or usability research might all help enable similar outcomes.

Jobs to be Done

If you're a fan of Clay Christensen's Jobs to be Done, then you might remember the story about how the milkshake wasn't competing with other milkshakes; it was competing with bananas and bagels.

For me, FullStory wasn't competing with other similar tools; it was competing with usage logs and usability research.

Only, I didn't have the technical access I needed to get at good usage logs. And, I didn't have the time or bandwidth to conduct thorough user research.

Therefore, in my mind, FullStory had no competition. It provided the context and clarity that I needed to do my job better in a way that nothing else in my toolkit could.

Even More Jobs to be Done

In the last 3 years since I first "hired FullStory" to do the job of keeping me close to my customers, the app has evolved to include an exciting array of new functionality. Today, powered by lightning-fast Google-like OmniSearch, FullStory can do jobs that I never would have considered. As someone operating in the marketing job family at FullStory, some of my new Job Stories look like this:

  • When I'm hosting a customers-only happy hour in a different city, I want to find a list of the most active users by city so that I can invite them.

usersinCity

  • When I've sent an email announcement for a new feature, I want to see how many people engaged with that feature from the email announcement so that I can report on the success of our announcement campaign.

announcement

  • When I launch a new landing page, I want to understand the most-clicked element so that I can make changes to increase conversions.

most clicked

Today, FullStory helps me get fast answers to questions about customers and how they engage with content.

"To the future!"

Looking back on the last few months, I'm feeling incredibly grateful for the opportunity and for my co-workers who keep teaching me new things every day. I can't wait to see what the future of FullStory holds. We have a lot of new jobs to do.