Thank you so much, Chris.
And thank you, Sahid.
Thank you both for inviting me to speak.
And thanks to all of you for taking a few minutes to listen.
I think this talk is going to be a little bit
different from the ones we've heard so far,
but I hope this provides an interesting perspective.
As Chris mentioned, I work at Atlassian,
and I work on the HipChat product.
I'm the product manager there, and I've been with that team
for about three months.
HipChat, if you are not familiar with it,
is a chat tool built for your team at work.
Another way to think about it is it's
like IRC, except everybody at your work is willing to use it,
instead of just the devs.
But it's fantastic at bringing your whole community
into one place.
You can have persistent chat rooms for teams, projects,
deploys, bugs, anything you could think of.
And of course, you can chat one-on-one with anybody
on your team.
You can share files, images, links, and HipChat records
everything and makes it searchable and easily findable
later.
HipChat runs on pretty much everything.
Of course, we started on the web,
but we also have Native Clients for Windows, Mac, and Linux;
and you get it on iOS and Android.
So pretty much anywhere you are at any time,
you can be in contact with your team using HipChat.
We found-- and this was certainly the case with us
before we discovered HipChat-- that most people at work
are using some sort of consumer tool
to communicate with their colleagues.
I found that I did this all the time.
So we decided to build a better solution.
HipChat is built for business, because your whole team
is already there.
There are tens of thousands of teams around the world who
are using it to collaborate today.
It's the first thing they sign into in the morning.
They leave it open on their desktop all day long.
They converse in it with their colleagues until they go home,
and even after.
And it is the heartbeat of those teams.
This was certainly the case for us,
but we found that there was a problem.
Any time we found ourselves moving the conversation outside
of HipChat, we got frustrated.
It happened over and over again.
So as conversations got longer, someone would inevitably say,
"well hey, let's just talk about this
rather than typing for an hour."
Then we proceeded to the negotiation phase.
So do you want to use a real phone?
Or how about Skype?
What about a Hangout over here?
We could just go to the conference room
and use a VC system?
Oh wait, OK, what room are you in?
What's your login on that system?
I invited you, have you seen my invitation?
I don't see you logged in, let me restart.
So inevitably, it would take 10 minutes
to actually get this stuff done.
And by the time you actually connected with the person
that you wanted to talk to, you'd
forgotten what you wanted to talk about in the first place.
So that's why we decided to build HipChat Video.
You can now move a conversation from text chat to video chat
with a single click inside HipChat.
You can do video calls, screen sharing, and audio calls
all right within the application.
And so far, our customers have loved it.
So that's really what I'm here to talk about,
is how we built HipChat Video.
But here's the tricky bit, we really
didn't build very much of it, actually.
We ended up using a video provider to power
all of HipChat Video, and all we did
was integrate it into the application.
We decided that running a video platform
was not our core competency, not where
we wanted to spend all of our energy and our effort.
We wanted to build a great experience, and a great chat
tool, and a great collaboration tool, of which video
was a feature.
And we weren't convinced that we could
do it better than the many great companies that are starting up
right now, devoted to that very problem.
We wanted to take advantage of what they had done.
So we set out on a journey about a year ago
to choose a provider to work with,
and to integrate that feature into our application.
I'm going to talk a little bit about what we thought about
as we chose somebody, what we have discovered as we rolled it
out, and I'm going to leave you with a few of the lessons we
learned.
To start with, the most important thing, and one
of the daunting things that caused
us to want to work with a provider to begin with
was platform support.
Because we have to work on all those platforms, native apps,
all the browsers including IE, including Safari,
we knew that vanilla WebRTC was not going to be enough.
So we found somebody who could provide us
a library and the plug-in for the non-native support
browsers, and they would extract away all that difference.
We could program to one API, no matter
which browser we were using, and it worked great.
They use WebRTC everywhere they can,
they install a plug-in where necessary,
and then I think they have some fallback methods
for the very old versions of IE.
In the same way, we weren't just building for the web,
we had five other platforms.
Luckily, we found a provider that
provided a library that supported Mac, Windows,
Linux, and iOS and Android all natively.
So we had an SDK for each of those.
They extracted away a lot of pain
that we would have had to go through
if we were trying to do this entirely on our own.
That API is actually the second thing
that we've thought really long and hard about.
We actually spent a lot of time experimenting
with multiple providers to make sure
that they had an API that was complete,
that was well documented, that supported what we wanted to do,
and that was well supported.
And it was actually amazing how many people
failed this simple test.
The features that we cared about,
that was obviously another major consideration.
We've started now with one-to-one video chat,
but we know that we want to go much further.
We want to move to group next, and broadcast in the future,
and so we made sure that we found somebody
who was heading in that same direction,
and provided a lot of those features.
We looked at how they handle multi-party, how widely they
could scale, what technology they use behind it,
and there have been some great explanations
today about the architectures that support that.
We also looked at things like how they collected analytics,
and could we have them?
Could we actually see how things were
performing inside our application?
And quality measures as well.
Fourth, we cared a lot about user experience.
We were trying to solve a problem where
there was a lot of sort of UX friction.
And so we wanted to make sure that we
could make a smooth and painless an experience
as possible to make it feel like 100 percent
native part of the app.
So it was interesting, because there
were a bunch of providers-- maybe not a bunch,
but there are some providers-- that we
looked at that had a standalone UX.
You couldn't really modify very much.
Sometimes there was branding that you couldn't get rid of.
Sometimes it would launch a new process.
We found one that we could integrate wholly into the app,
and as far as our customers are concerned,
there is no difference between HipChat and HipChat Video.
So not every provider gives you the latitude
that you might want to build the user interface that
fits best in your application.
And lastly, we were looking for a company
whose primary business model was providing video
as a service to us and others.
We were happy to pay for this.
We just wanted to make sure that our incentives were aligned
with theirs as a company, and that we
were going to go down this road together,
because you are making a long-term commitment.
And you want the team to be responsive,
and fortunately the folks we worked with
proved to be very responsive.
So how did it go?
It worked out fantastically well from our perspective.
Once we had selected a provider, we
had a prototype up and running in a matter of weeks,
and it took several months after that
to go from prototype to shipping, But I guarantee you,
it would have taken possibly an inordinate magnitude longer
to actually build support for all five platforms,
for all the backend, for multi-party support.
That was all stuff that we just got
to take advantage of someone else's great work.
And when we launched, we supported all those platforms.
All the browsers, all the native apps,
and all the mobile apps as well.
And that was a fantastic thing, because of course
video as a feature in your app, it's
sort of a network effects kind of thing.
It's more valuable the more people I can call.
So if we had a limit and say, well, it
works in the Mac app and the Windows app, but not in iOS
yet, then you're automatically sort
of kneecapping your feature to begin with.
So launching on all platforms simultaneously
was really important to us, and with the partner
we were able to do it.
So we launched HipChat Video three months ago,
as I mentioned, and user response
has been really, really good.
So just a few of the reactions that we've
seen in that first week, and since.
People are really valuing the ability to stay within the app,
to use video in the context that they already are.
We've had over 150,000 video calls placed
in three months, 2.5 million minutes of conversations.
I didn't really know what to expect
when we launched this thing.
I didn't have an idea of the scale.
But when I looked this number up, it blew my mind.
That is a lot of people talking to each other
about a lot of really important things.
The average call is about 15 minutes long,
and there are plenty of calls that are an hour or more.
So clearly, people are taking advantage of this for meetings
at work, which is sort of how we were using it as well,
so that makes sense.
In HipChat, we are really doubling down
on this idea of making great meetings.
We think that having a tool like this, especially
for distributed teams, can make meetings more efficient, less
painful, and just more useful by bringing all your communication
channels into one context.
So that's what we're thinking about.
So what did we learn?
Or what have we learned so far in the year
or so that we thought about selecting, and then
building, and then releasing this feature inside our chat
application?
Well first, we figured out that video is actually
really hard in the wild.
And we were insulated from some of it
because we got to work with somebody,
but still there was all sorts of user error
that we weren't expecting.
I mean, we were all web developers,
and all of a sudden you're now dealing with hardware.
It's not complicated hardware, but it's still hardware,
and it's not something that I was
used to ever having to do as a web developer.
But you've got to worry about cameras,
you've got to worry about drivers,
you've got to worry about the microphone,
you've got to worry about other applications who
have stolen focus.
And these are things that, no matter what happens,
the user is going to blame your application.
So we had to work really hard to try and smooth that experience
out.
And of course, with video, especially
with peer-to-peer video like WebRTC,
you're at the mercy of the network.
And again, the user doesn't care what the network looks like,
they just want the thing to work.
And if it doesn't work, it's your fault.
So that led us to a second lesson,
which was we had to monitor everything.
So we want a constantly updating sense
of how the application is performing out in the field.
And so we started looking at things like calls attempted,
called completed, calls dropped, looking at those ratios.
We looked for problem signs, like repeated short calls
between the same two people, or lots of drops,
or short calls that were legitimately hung up.
But if somebody's only on there for five seconds,
it's probably because they can't hear
or they can't see or something like that.
We monitored network quality and audio quality and video quality
during the call, and see how that
changes over time and with load.
And then lastly, we also made sure
that we asked the users how things were going.
So this is a pretty standard UI, but as I'm
sure you've seen with many other tools,
when the call ends we say, "how was it?
How was the quality?
Please give us your one to five rating.
If there's a problem, you can leave some notes."
And we track and record that over time
as well to make sure that we're staying
at a high level of quality.
And fortunately, things have been pretty good so far.
But thirdly, the first two lessons
led to this third one, which is, it's
really important to help users help themselves.
So because the user is going to blame your tool no matter
what goes wrong, it's best to give them
as many ways out of a problem as possible.
So we built in things into the application like a Test Sound
button to make sure that the speakers were turned on,
or their headset was plugged in right or working correctly.
Indicators for your mic, for the camera
display so you can actually see what the camera is seeing
to make sure it's actually working
the way you think it's working.
And then lastly, we made sure that there
was really detailed logging that a user can turn on and access,
and give to us if necessary.
And that's helped our support guys a whole lot.
So I'll leave you with three key takeaways
that we pulled out of this process.
The first is the choice of Building versus Buying.
And what we asked ourselves was, was video the core
of our application?
Was it the most important thing we were going to build?
And we decided that it was a feature,
but it was not the core.
And secondly, we were not in a position
that we could invest to do it differently,
or better than the whole ecosystem of you
guys out there who were building these services already.
So we found a great partner to work with.
Secondly, before you choose, make
sure you look hard at the SDK and the API
before you make a commitment.
You're going to be using that API for a long time,
make sure it's something you want to program against.
And lastly, remember that the real world is messy.
So make it as easy as possible for your users to self
diagnose, to give you information,
to help you help them.
So that's how we built HipChat Video.
I really appreciate you guys listening,
and I hope you'll go check it out.
Thank you.
[APPLAUSE]