I'm a big fan of personas. They help with cross-functional alignment. They provide a focused lens for the customer or developer you are building for, whether it is someone like you or someone who is quite possibly the opposite of you.
A lot has changed in 2020, at times almost daily. Sitting squarely in the live video streaming space I've been hit with a slew of changes, including one I recognized quite early on in COVID-19 times - our user and dev persona changed quite abruptly when more folks globally started working from home and consuming more video updates including live streaming video from their city, state, county, country's government offices.
While there have been a number of articles and blogs written about burn out, I've seen surprisingly few about addressing or acknowledging this potential persona change across any market or industry. For me, simply acknowledging this change has helped my mental health and wellbeing tremendously.
Let's talk a little bit about how our developer personas at Wowza changed.
Sure, I've had developers reach out describing a desperately urgent situation. It's Thursday, management wants a working proof of concept on Monday for a specific meeting. How can they get up and running quickly?
But by April 2020 it looked more like this - It's Thursday, management wants a working end-to-end live video streaming solution on Monday for a global business update meeting and our company has never done anything like this before. And instead of a single developer or company reaching out with this scenario, it is a constant stream. (Is that a pun? Oops.)
Instead of working with a handful of developers on how to implement a solution with your product over the course of a few weeks, you are now struggling with every request hitting DevRel defined as "urgent". Sprinting a marathon.
Knowing the video landscape is challenging for beginners, we had to make some decisions like writing tutorials and blogs specific to Zoom workflows, educating devs on RTMP/RTMPS outputs from products like Zoom to do similar workflows, and drawing clear lines where products don't have that capability (Instagram Live).
Notice how at no point I mentioned Wowza products in that last paragraph. That's because we were having to create new entry points into a Wowza workflow for these urgent personas. They didn't have time to learn about cameras and encoders. They needed a stream source and a way to distribute, so we showed them exactly how to do this even if the majority of the education was around non-Wowza products.
This one may be less to do with COVID and more to do with the availability of products like YouTube Live, Instagram Live, Facebook Live, etc. where you press a button and you can "go live" straight from a phone or webcam seemingly without an encoder or configuring a distribution architecture. That is all done for you by the service you choose.
As you can imagine, this changed some of the perceptions people had when interacting with live streaming software. "Why do I need an encoder, can't I just do this from my phone?" or "Why do I have to specify a protocol?" showed folks challenged in understanding the live streaming workflow and how to make it work for them.
Then enter Zoom, like I mentioned above. "Can I live stream with Zoom?" or "How do I integrate with Zoom?" quickly dominated most conversations as a way to capture a conversation or presentation and then effectively pipe it out and distribute it with technology like Wowza's product. But the average Zoom user could be well acquainted with Zoom and barely acquainted with live video streaming, much less server administration.
Bridging those gaps required more hands-on tutorial and guidance, completely skipping the live streaming fundamentals and even the server administration skills. We routed folks to our cloud offering, showed them exactly what configuration items they needed to hit. No customization needed, they were up and running with a few more clicks but more flexible streaming distribution than purely running on a specific social media platform.
Wowza Streaming Engine has long been our most dev centric product, customizable with Java modules. While we have web developers interacting with our products through the playback experience in the browser, we are moving away from maintaining our own player.
With a focused shift to WebRTC, that changed. We wanted to give more folks an opportunity to work with WebRTC by improving the developer experience, but most of those improvements were targeted at Java developers not web developers. This created some tension among WebRTC experts and web developers expecting an improved developer experience for their persona, but were frustrated to find example code instead of a library or an SDK. "I shouldn't have to reverse engineer your code" was the favorite comment of many web developers, and we heard this.
Moving forward, we plan on cleaning up the developer experience for web developers by creating a client-side experience with a library or an SDK for modern web dev. Acknowledging this persona shift changed the conversations from "we failed to give developers what they want" to "we enabled one developer persona and indirectly challenged another developer persona" leaving us opportunities to scope out future work.
Remember "developer" is not a granular enough persona. And even if it was, it wouldn't stay constant forever. People change. Needs change. Economies change. What worked for your product and customers earlier this year, may not be whats working for them now, COVID-19 or otherwise.
Are you taking time to iterate on your personas? How often? Did you see a change this year as a response to COVID, lockdowns, remote work, and other measures?