It’s about WebRTC Job to be Done. At the end of the day, this is what defines what WebRTC usage means.
Last week Dave shared the post that he just published in NoJitter with me. It was about the question how to define what a WebRTC application is. It got my fingers itchy to write, so I ended up with last weekend’s mini series of posts:
- Introduction to WebRTC JTBD (Job to be Done)
- WebRTC JTBD: Reducing the barrier of entry for developers
- WebRTC JTBD: Reducing friction for end users
Now that we’ve got that settled, here’s my simple litmus test to which vendor can be considered a WebRTC vendor:
Well. Not really, but close enough.
There are two things we need to ask ourselves about said vendor or application:
- Would they even exist without WebRTC? Is their use case too minor in market size, their team to small in funding to make a dent, their business model ridiculous – if you factor out WebRTC
- Is the user experience they offer possible without WebRTC?
If they can’t exist without WebRTC, or the user experience is impossible without it – they are a WebRTC vendor in my book.
Critics complain that I am too hyped about WebRTC, saying it brings something new to the table. To me, the 2 items above indicate why WebRTC is so important – not as a standard, but as an adopted technology.
I have talked to many small vendors in this last 3-year ride that I can comfortably say that many of them wouldn’t exist at all without something like WebRTC to enable them to try out and implement their idea. On the other end of that same spectrum, there are many use cases that just won’t happen without their simple accessibility to a browser – just look at Intuitive Solutions as one of the latest examples.
To me it all boils down to the impact WebRTC made on the vendor or service.