A WebRTC JTBD (Job to be Done) Weekend

September 5, 2014

WebRTC is all about Friction and Barriers. This is its “job to be done”.

A year ago, I’ve written about the job to be done of WebRTC over at UCStrategies.

Dave Michels contemplated recently what a WebRTC vendor really is – expect a post from him soon. I had an interesting text chat with him the other day about this upcoming post. It got me thinking again about WebRTC and what it means to be a WebRTC vendor.

I’d like to attempt tackling that, but instead of doing it in a single post, I am going to do it over the coming weekend. Feel free to go through the motions with me or just catch up on it next week.

What is WebRTC’s Job to be Done?

Every product and service should have a JTBD (a Job to be Done) – Something it sets out to solve. It should be at the core of that product. While WebRTC is a technology, it is one that was introduced to close existing gaps. It was meant to add missing capabilities to web browsers, enabling them to compete better with operating systems in terms of the types of applications they can run.

Things have shifted since then. Both for WebRTC and for the browser world. Browsers are now focused on catching up with native development on mobile. It is quite common to hear Google browser developers talk about 60fps and great performance when talking about browsers – something unfathomable a mere couple of years ago. WebRTC, on the other hand, is being considered as the best option to go mobile with communications.

So what is the job to be done of WebRTC?

  1. Reduce friction for users
  2. Reduce barrier of entry for vendors

I noticed it last week when working on a slide I had in my deck – it was one I’ve created over 2 years ago to explain what WebRTC is. The only thing I changed in it is the removal of the animation (for an online webinar) and the titles added to the groups:

WebRTC's Job to be Done

See the titles? Two years ago, I had it all figured out, but couldn’t put my finger on what it meant. Placing JTBD on it makes it easy – WebRTC’s job to be done is reducing friction to end users and reducing the barrier of entry for vendors.

While at it, I should probably change the title of this slide to say it clearly – this is WebRTC’s job to be done.

During the weekend, I’ll explore these two and elaborate on them further.

You may also like

Two years of WebRTC Insights

Two years of WebRTC Insights

Your email address will not be published. Required fields are marked

  1. Tsahi,

    One of the biggest “jobs to be done” in any organization is to facilitate “click-for-assistance” options in mobile customer service apps. As you probably know, I have written extensively on that subject because I see it as an important benefit of UC, as compared to the “collaboration” benefits for internal users or business partners.

    1. Art,

      While this is true, I am trying not to look at it from the organization’s perspective, but rather from WebRTC’s perspective. What is it here to solve? Click-to-call is one of the places where it can be used, but limiting it to that domain means missing a lot of the capabilities of WebRTC.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}